Некоторое время назад разработчик Вадим Гирлин (Vadim Girlin) представил (http://lists.freedesktop.org/archives/mesa-dev/2013-February...) собственню ветку MESA, в котором включен оптимизированный кодогенератор шейдеров для GPU, поддерживаемых драйвером R600g. Представленный код генерирует шейдеры, которые значительно более оптимизированы, чем шейдеры, генерируемые текущей версией кодогенераторов в драйвере R600g (как своего собственного, так и на основе LLVM).
В частности, разработчик продемонстрировал существенное увеличение FPS в тесте Unigine Heaven с использованием собственного кодогенератора, что значительно превосходит результат, демонстирируемый неоптимизированным штатным вариантом кодогенератора, а также кодогенератором на основе LLVM.
В результате в списке рассылки возникла полемика. Разработчики из компании AMD полагают, что у штатного кодогенератора, встроенного в драйвер R600g, нет перспектив и он будет постепенно заменен на кодогенератор, основанный на LLVM по мере его готовности. Аргументами за такое решение служит потенциальное упрощение разработки (теоретически достаточно разрабатывать только backend, осуществляющий генерацию нативного потока команд GPU), упрощение реализации OpenCL и т.п.
С другой стороны, разработчик Vadim Girlin отметил что реализация тех же самых оптимизаций в LLVM является сложной и нетривиальной задачей, так что он не смог бы реализовать свои оптимизации в LLVM с теми же затратами усилий. Кроме того, он констатировал, что за довольно существенное время разработки бэкэнда на основе LLVM не было достигнуто практически никаких видимых для пользователей результатов, что по его мнению ставит под вопрос целесообразность такого подхода.
В результате возникло некое противоречие: с одной стороны все разработчики согласны, что оптимизации дают весьма заметный эффект в нагрузках, активно использующих шейдеры. С другой стороны, разработчики считают LLVM более перспективным, чем собственный кодогенератор в долгосрочной перспективе.
Тем не менее, разработчику Vadim Girlin судя по всему удалось найти компромиссное решение, которое устроит обе стороны, участвовавшие в полемике. Недавно разработчик представил (ttp://www.phoronix.com/scan.php?page=news_item&px=MTM1NTU) свой новый вариант оптимизатора. В данном случае разработчик постарался максимально отвязать оптимизатор от остальных частей драйвера. Суть идеи в том, что оптимизатор подключается через некоторые точки в драйвере и получает от него уже готовый код GPU, над которым и выполняет оптимизации.
Такой подход позволяет оптимизатору успешно сосуществовать как с собственным кодогенератором, так и с кодогенератором на основе LLVM. Более того, оптимизатор показал заметное улучшение производительности как с классическим кодогенератором, так и с LLVM. В результате выигрыш наблюдается в практически всех нагрузках, использующих шейдеры или вычисления на GPU, вплоть до майнинга биткоинов с использованием открытых драйверов.
Данная инициатива вызвала одобрительную оценку большинства разработчиков, которые теперь не видят препятствий для включения оптимизатора в состав драйвера R600G. Вероятно, потребуется доработка и переделка, однако в целом такой подход вызвал одобрение большинства разработчиков драйвера.URL: http://www.phoronix.com/scan.php?page=news_item&px=MTM1NTU
Новость: http://www.opennet.me/opennews/art.shtml?num=36794
вадим молодец. давайте поздравим его.
>давайте поздравим его.Удивите его - шлите деньги. //линка у меня нет
а когда выйдет mesa 9.2 или 10?
в августе или сентябре
> будет постепенно заменен на кодогенератор, основанный на LLVM по мере его готовности. Аргументами за такое решение служит потенциальное упрощение разработки (теоретически достаточно разрабатывать только backend, осуществляющий генерацию нативного потока команд GPU), упрощение реализации OpenCL и т.п.
> С другой стороны, разработчик Vadim Girlin отметил что реализация тех же самых оптимизаций в LLVM является сложной и нетривиальной задачей, так что он не смог бы реализовать свои оптимизации в LLVM с теми же затратами усилийТы где, писатель? Какие аргументы на этот раз?
Что, божественность "ну такого правильного" LLVM была сильно преувеличена?
Ну так упоминали же - он для VLIW не проектировался и толком с ними работать не умеет. Впрочем, рассказы какой он замечательный меня тоже утомили.
Впервые читаю:
> С другой стороны, разработчик Vadim Girlin отметил что реализация тех же самых оптимизаций в LLVM является сложной и нетривиальной задачей, так что он не смог бы реализовать свои оптимизации в LLVM с теми же затратами усилий.Так кто-то уже работает над LLVM next really parallel generation?
> Что, божественность "ну такого правильного" LLVM была сильно преувеличена?Никто о божественности не говорит. Архитектура его чертовски красива.
Но я предпочту то решение, производительность которого выше...
> Архитектура его чертовски красива.Амдшники уже вкусили "красоты" этого чуда природы. Продолбавшись с ним чуть ли не два года без каких либо user-visible результатов на выходе. "Красиво было на бумаге, да забыли про овраги".
> Но я предпочту то решение, производительность которого выше...
Ну вот пока производительность LLVM что-то не вызывает бурного оптимизма. Особенно в плане соотношений долботни к результативности этой долботни.
> Что, божественность "ну такого правильного" LLVM была сильно преувеличена?А ты почитай список рассылки. Узнаешь много нового относительно того сколько амдшники долбались для того чтобы вообще выжать из него технически-валидный поток VLIW команд и какие феерические костыли в LLVM для всего этого потребовались. Логично что им при этом было не до оптимизации и FPSов. По поводу чего их вполне справедливо пожурили за галимое соотношение затрат усилий vs выхлоп от всего этого.
это просто сказка, r600-sb в хевене догнал винду
784 vs 789 в винде.
пруфы - http://www.gearsongallium.com/?p=752
А fglrx?
нужно слишком много чего откатывать, не думаю что он заметно лучше каталиста на винде.