> Но без лoжной скромности скажу, что r600-sb для vliw оптимизирует не хуже,
> чем все их проприетарныe компиляторы, Что забавнее, это отдельный бэкэнд и у его автора есть неслабые предъявы к LLVM и его усложненности. И это в целом можно понять. С другой стороны делать полновесный компилер си/си++ при наличии готового LLVM и минимуме ресурсов амдшникам не улыбалось.
В результате появился некий логичный компромисс - как я понимаю, sb прикручен опосля и ему вообще все-равно, местечковый бэкэнд генерил шейдеры или LLVM.
> управлении текстурами
Если уж мы о птичках, в ядре 3.19 что-то делали с TTM, как раз по части ускорения операций с текстурами. Ждем когда фороникс раздуплится забенчить :).
> и прочим.
Судя по провалам синтетических тестов типа triangles - что-то где-то здорово недооптимизировано, но мешает жить только местами. В менее синтетических ситуациях оно наверное и будет давать разницу не в 3 раза как в синтетике, а 20-30%.
> А для radeonsi пока никто такого же чуда не сотвoрил, так что придется подождать.
Для начала, там не VLIW и поэтому компилеру должно быть менее душно работать с таким набором команд и без костылей. Собственно, амдшники 2 года долбались с LLVM чтобы он вообще смог хотя-бы технически корректный код для VLIW выдавать. Мега-супер-архитектура LLVM чего-то не в курсе существования VLIW и амдшники там адски костылировали, донавешивая какой-то отдельный проход, который уже потом перегруппирует инструкции так чтобы поток команд хотя-бы технически валиден был (VLIW в этом плане придирчивы по части взаимозависимостей). А по хорошему VLIW надо оптимизацию на этапе генерации потока команд, с учетом взаимозависимостей. На что LLVM (да и остальные реально существующие компилеры) заточены чуть менее чем никак (это фирменная проблема VLIW что реально существующие компилеры не в курсе таких заморочек). Ну вот sb это хоть немного откостылировал. Это по идее менее оптимально чем когда компилер явно aware про закидоны VLIW, но лучше чем никак.
А в случае GCN амдшники задолбались и предсказуемо воткнули перед пачкой ALU и прочая собственные блоки планировщиков, так что у компилера стало заметно меньше проблем. Кстати говоря, в поздних 3.5/git'овых 3.6 LLVM для GCN'ов ощутимо подтяули. И это тоже одна из причин почему SI стал быстрее. А для начала хотя-бы перестали валиться тяжелые графические движки и прочее. Ранние LLVM имели какие-то проблемы с аллокацией регистров и если нагрузка большая - LLVM мог умереть, не сумев выкроить регистры. По поводу чего валился Xonotic на настройках Ultra, ряд opencl задач и еще некоторые игры.
