https://www.opennet.dev/openforum/vsluhforumID3/138209.html Marek Ol&#353;&#225;k, разработчик видеодрайверов из компании AMD, добавил в кодовую базу Mesa изменение, переводящее драйвер RadeonSI на использование по умолчанию промежуточного представления (IR) шейдеров NIR и бэкенда компиляции шейдеров ACO, развиваемого компанией Valve в качестве альтернативы компилятору шейдеров LLVM. Бэкенд ACO нацелен на обеспечение генерации кода, насколько это возможно оптимального для шейдеров игровых приложений, а также на достижение очень высокой скорости компиляции...<br><br>Подробнее: https://www.opennet.ru/opennews/art.shtml?num=64141<br> https://www.opennet.dev/openforum/vsluhforumID3/138209.html#71 Thu, 20 Nov 2025 07:25:03 GMT &gt; У меня, как энтомолога-русоведа есть к тебе вопросик: что тебя и таких <br>&gt; как ты заставляет коверкать названия фирм? Все эти &#171;вольво&#187; вместо &#171;вальве&#187;, <br>&gt; &#171;межделмаш&#187; вместо &#171;IBM&#187; и так далее. Что тебя заставляет так делать? <br>&gt; У тебя что-то свербит в голове если ты этого не сделаешь? <br>&gt; Ты считаешь это смешным?<br><br>Во- первых, потому, что могу.<br>Во- вторых, ссылаясь на пункт "во- первых", на остальное отвечать я буду по желанию.<br> https://www.opennet.dev/openforum/vsluhforumID3/138209.html#70 Tue, 04 Nov 2025 19:17:48 GMT &gt;Повестку обновите.<br><br>Это в госуслугах.<br> https://www.opennet.dev/openforum/vsluhforumID3/138209.html#69 Tue, 04 Nov 2025 19:13:32 GMT И давно вы с НЛО встречаетесь?<br> https://www.opennet.dev/openforum/vsluhforumID3/138209.html#68 Tue, 04 Nov 2025 19:05:51 GMT &gt;продолбал все преимущества по части скорости компила<br><br>Не очень важна, важно качество. Компилится один раз, а исполняется - много раз в секунду.<br><br>&gt;Архитектура странная. Вообще вся кодогенерация - для всех таргетов - в ОДНОЙ убер-либе. Никогда не видели .so размером 100+ мегов? Посмотрите на LLVM свежих версий. Увидите! Мне кажется что этот подход имеет проблемы с масшитабированием, особенно по мере добавления таргетов и оптимизаций.<br><br>Имеет проблемы. Сам LLVM тормознуто и жруще компилится. Одна из мечт - чтобы я мог добавлять таргеты без перекомпиляции LLVM, чтобы просто моя маленькая shared-либа линковалась с LLVMовскими и грузилась компилятором как плагин.<br><br>&gt;3) Оптимизации навернули так что последние версии порой впадают в маразм. В лучшем случае они генерят раздутый и тормозной код. В хучшем глюкавят на манер старых GCC выдавая некорректный код.<br><br>У меня микробенчи показывают, что у LLVM код быстрее, чем GCCшный, иногда даже вдвое-втрое, а иногда - в десятки раз, если это GCC впал в маразм и не вектор https://www.opennet.dev/openforum/vsluhforumID3/138209.html#67 Tue, 04 Nov 2025 00:36:02 GMT &gt; Он тут не говорит что AMDVLK был закрытым, он тут говорит что <br>&gt; это была закрытая разработка + открытые исходники <br><br>Возможно его сперва не называли AMDVLK, просто поставляли в проприетари. Вот тут не помню.<br><br>В любом случае - насчет дат кое-кто прогнал. RADV релизнулся раньше AMDVLK о чем там и написано. Насколько я помню Bridgman на форониксе, чтоли, писал что там юридический отдел с clearance этого - тупит. Так ли оно? А поди проверь. С этого станется и марктеинг динамо от амд выгородить.<br><br>&gt;&gt; Я так понимаю что AMDVLK и есть по сути порт того что под винду было <br>&gt; Я всё это говорил к тому что в AMDGPU-PRO был не AMDVLK, <br>&gt; а свой полурабочий велосипед, AMDVLK работал намного качественнее чем то что <br>&gt; было в AMDGPU-PRO.<br><br>Мы о чем тут говорим? О том на чем базирована кодовая база? Или что где-то опосля AMDVLK до ума довели? Это 2 совершенно разные ипостаси. Кодовую базу мы даже сравнить чисто технически не сможем, за отсутствием сорца <br><br>&gt; И до релиза в декабре 2017го его просто не существовало п https://www.opennet.dev/openforum/vsluhforumID3/138209.html#66 Sat, 01 Nov 2025 22:02:34 GMT &gt; Для сильно забывчивых или просто подтасовывающих факты я могу и напомнить, из первых рук:<br><br>Он тут не говорит что AMDVLK был закрытым, он тут говорит что это была закрытая разработка + открытые исходники<br><br>&gt; Я так понимаю что AMDVLK и есть по сути порт того что под винду было<br><br>Я всё это говорил к тому что в AMDGPU-PRO был не AMDVLK, а свой полурабочий велосипед, AMDVLK работал намного качественнее чем то что было в AMDGPU-PRO.<br><br>И до релиза в декабре 2017го его просто не существовало под Linux, о чём airlied тоже написал<br><br>&gt; When Bas and I started radv in 2016, AMD were promising their own Linux vulkan driver, which arrived in Dec 2017.<br><br>Они не просто обещали его заопенсорсить, они обещали его вообще сделать, что они и закончили в декабре 2017 и в тот же день заопенсорсили.<br><br>Не существовало никогда блобов AMDVLK под linux<br> https://www.opennet.dev/openforum/vsluhforumID3/138209.html#65 Sat, 01 Nov 2025 20:25:13 GMT &gt; Ты с чем то путаешь, AMDVLK был открытый с первого дня релиза <br>&gt; в декабре 2017го, RADV тогда уже был релизнут <br><br>Это ты что-то путаешь. Ибо сначала IIRC AMDVLK релизился только блобами в -PRO насколько я помню. А открыть его - обещали. Кормили завтраками. Довольно долго. Кивая на то что тупит юридический отдел. В какой-то момент Airlied этот позор - надоел. И он дал всем мастеркласс.<br><br>&gt; Возможно AMDVLK и был собран из того что было закрытым под винду, <br>&gt; однако факт в том что с момента релиза под Linux он <br>&gt; уже был открыт.<br><br>Для сильно забывчивых или просто подтасовывающих факты я могу и напомнить, из первых рук:<br><br>https://airlied.blogspot.com/2025/09/radv-takes-over-from-amdvlk.html<br><br>Не, майнтайнер графической подсистемы линя - врать не будет. Там и тайминги его штуки VS amdvlk и весьма скромная и выдержанная и политкорректная ремарка про "over the wall". Я могу и менее поликторректно расписать что я думаю про типа-"опенсорс" девелоп в стиле "нате на лопате" и динамо с релизами.<br><br>&gt; AMDGPU-PRO и https://www.opennet.dev/openforum/vsluhforumID3/138209.html#64 Sat, 01 Nov 2025 00:17:15 GMT &gt; AMDGPU-PRO имел поддержку vulkan, однако ему до AMDVLK было очень далеко, корни <br>&gt; у этого скорее от винды.<br><br>AMDGPU-PRO при этом не рекламировался ни для кого кроме владельцев их профессиональных ускорителей у которых совсем другая экосистема, AMD никогда не предлагали ставить их проприетарный драйвер ради vulkan, некорректно утверждать что им была какая-то выгода от того чтобы люди переходили на AMDVLK<br> https://www.opennet.dev/openforum/vsluhforumID3/138209.html#63 Sat, 01 Nov 2025 00:13:41 GMT &gt; 1) Изначально AMDVLK был проприетарный. А Radv еще не было.<br><br>Ты с чем то путаешь, AMDVLK был открытый с первого дня релиза в декабре 2017го, RADV тогда уже был релизнут<br><br>Возможно AMDVLK и был собран из того что было закрытым под винду, однако факт в том что с момента релиза под Linux он уже был открыт.<br><br>AMDGPU-PRO имел поддержку vulkan, однако ему до AMDVLK было очень далеко, корни у этого скорее от винды.<br>