https://m.opennet.dev/openforum/vsluhforumID3/89771.html Некоторое время назад разработчик Вадим Гирлин (Vadim Girlin) представил (http://lists.freedesktop.org/archives/mesa-dev/2013-February/034547.html) собственню ветку MESA, в котором включен оптимизированный кодогенератор шейдеров для GPU, поддерживаемых драйвером R600g. Представленный код генерирует шейдеры, которые значительно более оптимизированы, чем шейдеры, генерируемые текущей версией кодогенераторов в драйвере R600g (как своего собственного, так и на основе LLVM).<br><br><br>В частности, разработчик продемонстрировал существенное увеличение FPS в тесте Unigine Heaven с использованием собственного кодогенератора, что значительно превосходит результат, демонстирируемый неоптимизированным штатным вариантом кодогенератора, а также кодогенератором на основе LLVM.<br><br><br>В результате в списке рассылки возникла полемика. Разработчики из компании AMD полагают, что у штатного кодогенератора, встроенного в драйвер R600g, нет перспектив и он будет постепенно заменен на кодогенератор, основанный на LLVM по мере его готовност https://m.opennet.dev/openforum/vsluhforumID3/89771.html#14 Sun, 28 Apr 2013 07:50:59 GMT нужно слишком много чего откатывать, не думаю что он заметно лучше каталиста на винде.<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#13 Sun, 28 Apr 2013 04:11:45 GMT А fglrx?<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#12 Sat, 27 Apr 2013 11:12:35 GMT это просто сказка, r600-sb в хевене догнал винду<br>784 vs 789 в винде.<br>пруфы - http://www.gearsongallium.com/?p=752<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#11 Fri, 26 Apr 2013 19:18:53 GMT &gt; Архитектура его чертовски красива.<br><br>Амдшники уже вкусили "красоты" этого чуда природы. Продолбавшись с ним чуть ли не два года без каких либо user-visible результатов на выходе. "Красиво было на бумаге, да забыли про овраги".<br><br>&gt; Но я предпочту то решение, производительность которого выше...<br><br>Ну вот пока производительность LLVM что-то не вызывает бурного оптимизма. Особенно в плане соотношений долботни к результативности этой долботни.<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#10 Fri, 26 Apr 2013 19:13:31 GMT &gt; Что, божественность "ну такого правильного" LLVM была сильно преувеличена?<br><br>А ты почитай список рассылки. Узнаешь много нового относительно того сколько амдшники долбались для того чтобы вообще выжать из него технически-валидный поток VLIW команд и какие феерические костыли в LLVM для всего этого потребовались. Логично что им при этом было не до оптимизации и FPSов. По поводу чего их вполне справедливо пожурили за галимое соотношение затрат усилий vs выхлоп от всего этого.<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#9 Fri, 26 Apr 2013 17:36:20 GMT в августе или сентябре<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#8 Fri, 26 Apr 2013 16:16:37 GMT Впервые читаю:<br>&gt; С другой стороны, разработчик Vadim Girlin отметил что реализация тех же самых оптимизаций в LLVM является сложной и нетривиальной задачей, так что он не смог бы реализовать свои оптимизации в LLVM с теми же затратами усилий.<br><br>Так кто-то уже работает над LLVM next really parallel generation?<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#7 Fri, 26 Apr 2013 14:59:18 GMT &gt; Что, божественность "ну такого правильного" LLVM была сильно преувеличена?<br><br>Никто о божественности не говорит. Архитектура его чертовски красива.<br>Но я предпочту то решение, производительность которого выше...<br> https://m.opennet.dev/openforum/vsluhforumID3/89771.html#6 Fri, 26 Apr 2013 09:46:52 GMT Ну так упоминали же - он для VLIW не проектировался и толком с ними работать не умеет. Впрочем, рассказы какой он замечательный меня тоже утомили.<br>