Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Драйвер RadeonSI переведён по умолчанию на бэкенд компиляции шейдеров ACO"	+/–
Сообщение от opennews (??), 30-Окт-25, 08:22
Marek Olšák, разработчик видеодрайверов из компании AMD, добавил в кодовую базу Mesa изменение, переводящее драйвер RadeonSI на использование по умолчанию промежуточного представления (IR) шейдеров  NIR и бэкенда компиляции шейдеров ACO, развиваемого компанией Valve в качестве альтернативы компилятору шейдеров LLVM. Бэкенд ACO нацелен на обеспечение генерации кода, насколько это возможно оптимального для шейдеров игровых приложений, а также на достижение очень высокой скорости компиляции... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64141
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 30-Окт-25, 08:22	+/–
Отличия в работе с amdgpu есть, в плане OpenGL? Как раз имеется пограничный APU с поддержкой как radeonsi, так и amdgpu. Проверял на Linux и Windows, так на первом OpenGL выдаёт заметно меньше кадров в секунду, нежели он же, не говоря уже об DirectX, во втором. Проверял на UT99.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #2, #3, #5, #21, #25

2. Сообщение от kravich (ok), 30-Окт-25, 09:25	+9 +/–
>UT99 Ты же понимаешь, что эта игра ни разу не может быть сколько нибудь репрезентативным бенчмарком для относительно современной видеокарты в 2025 году?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #7

3. Сообщение от Аноним (3), 30-Окт-25, 09:33	+/–
> Отличия в работе с amdgpu есть, в плане OpenGL? новость про месу, упомянутый radeonsi драйвер тоже из месы и без ядерного драйвера он не работает
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

4. Сообщение от Аноним (57), 30-Окт-25, 09:36	+3 +/–
Ничего не понятно.
Ответить | Правка | Наверх | Cообщить модератору

5. Сообщение от name (??), 30-Окт-25, 09:48	+/–
Так ты не можешь без amdgpu использовать vulkan и dxvk.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #28

6. Сообщение от aname (?), 30-Окт-25, 10:01	+10 +/–
Вольво двигает прогресс в Линукс-дистрах. Уважаемо.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #26

7. Сообщение от Аноним (7), 30-Окт-25, 10:32	+/–
Если быть точным, я имею ввиду APU E1-2100 с HD 8210, это уже в 2013 было слабо. К тому же, использовался нативный UT99.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #10

8. Сообщение от Аноним (8), 30-Окт-25, 10:33	+3 +/–
Ещё и грузовики делает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #11

10. Сообщение от Bob (??), 30-Окт-25, 11:35	+/–
Большинство плюшек только для +- актуального железа. Местами даже архитектура Polaris уже в пролёте.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #20, #24

11. Сообщение от Chel (?), 30-Окт-25, 11:42	+7 +/–
И плавленый сыр!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

12. Сообщение от Аноним (12), 30-Окт-25, 12:39	–4 +/–
Вместо того, чтобы улучшить оптимизатор в LLVM, они новый компилятор делают. Это тупиковый путь, LLVM такой неэффективный потому, что жирный. Когда вальвовский компилятор всосёт столько же бэкендов (а если он взлетит, то неминуемо всосёт), сколько LLVM - он скатится ниже уровня LLVM (то есть упадёт на взлёте). Поэтому не LLVM резать надо, а улучшать LLVM, чтобы он мог ещё кучу бэкендов всосать, а быть эффективным. А отдельные незалежные компиляторы - это просто выброшенный на ветер труд.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #13, #14, #17, #23, #29, #52

13. Сообщение от Оно ним (?), 30-Окт-25, 12:42	+6 +/–
А зачем вальвовскому компилятору всасывать столько бэкендов, если он сконцентрирован только на шейдерах?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #15

14. Сообщение от Аноним (12), 30-Окт-25, 12:42	+2 +/–
Жирный - имеется в виду, что когда нужно чтобы один и тот же код эффективно генерил эффективный код, то пространство решений очень сильно сужается, и приемлимые решения имеют более низкую энтропию по сравнению с решениями, которые эффективно ворочают только часть бэкендов. А получить низкую энтропию очень дорого. А Вальв по сути сказали "не нужен он копилятор с такой низкой энтропией, мы из говна и палок свой сделаем", и сделали. Только он не для всего, в отличие от LLVM.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

15. Сообщение от Аноним (15), 30-Окт-25, 12:51	+1 +/–
А что архитектур видеокарт и акселераторов для машоба мало? Тут каждый год по несколько выходит.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #18

16. Сообщение от Анонизм (?), 30-Окт-25, 12:52	–1 +/–
И зачем оно?! Очередной костыль.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #35

17. Сообщение от Я (??), 30-Окт-25, 13:58	+/–
вся суть программирования в том что если есть возможность сделать консервный нож максимально эффективно открывающий нужную банку то его надо сделать. а вот будет ли вам всегда хватать возможностей поддерживать этот нож в актуальном задачам состоянии вопрос другой
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12

18. Сообщение от Аноним (18), 30-Окт-25, 14:26	+1 +/–
Да 2.5 всего, как бы.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #15

19. Сообщение от Аноним (18), 30-Окт-25, 14:28	+1 +/–
Надеюсь, что сам компилятор ACO собирается гораздо быстрее, чем LLVM.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #22

20. Сообщение от 123 (??), 30-Окт-25, 14:52	+/–
Polaris уже 9 лет стукнуло, GCN 4. Вот GCN 5 Vega еще будут держать, за счет igpu в зоопарке ноутбучного железа apu ryzen.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #32

21. Сообщение от НяшМяш (ok), 30-Окт-25, 15:16	+/–
Интересно, когда уже кекспертам добавят в методичку пункт про разницу между ядерным драйвером и месой?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #36, #57

22. Сообщение от НяшМяш (ok), 30-Окт-25, 15:25	–1 +/–
Вся меса в конфигурации по-умолчанию (только х64 сборка) на моём 5950Х собирается за... 55 секунд. Что там за вопрос про LLVM был?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #19 Ответы: #27, #30

23. Сообщение от Xo (?), 30-Окт-25, 17:30	+/–
С чего это ACO новый? Повестку обновите.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #70

24. Сообщение от Аноним (-), 30-Окт-25, 18:04	+2 +/–
> Большинство плюшек только для +- актуального железа. Сабжевое изменение - для RadeonSI в целом. И как намекает название - это аж начиная с Southern Islands. Т.е. - GCN1.0 и все что новее этого. Более того. Насчет большинства плюшек господа не правы. В Valve кажется серьезно нацелились ранние GCN по дефолту на AMDGPU перевести. Они основательно допилили AMDGPU устраняя недостатки модуля AMDGPU vs Radeon для GCN 1.0/1.1 так что ВНЕЗАПНО скоро можно их кажется будет цеплять AMDGPU вместо Radeon как "default" а не "experimental". Они даже запилили в AMD'шной DC аналоговые выходы GCN 1.x и некоторых чуть более поздних с DVI-I выходом. И теперь GCN 1.x @ AMDGPU смогут выводить графон через DC (некая суб-библа в ядре для ADM'шных коннекторов видео и работы с дисплеями).
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10 Ответы: #44

25. Сообщение от Sunderland93 (ok), 30-Окт-25, 18:18	+/–
amdgpu драйвер ядра, radeonsi - драйвер Mesa
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1

26. Сообщение от В афиге (?), 30-Окт-25, 18:42	–1 +/–
У меня, как энтомолога-русоведа есть к тебе вопросик: что тебя и таких как ты заставляет коверкать названия фирм? Все эти «вольво» вместо «вальве», «межделмаш» вместо «IBM» и так далее. Что тебя заставляет так делать? У тебя что-то свербит в голове если ты этого не сделаешь? Ты считаешь это смешным?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #31, #33

27. Сообщение от Аноним (18), 30-Окт-25, 19:39	+/–
А сам Шланг за сколько собирается?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

28. Сообщение от Аноним (-), 30-Окт-25, 20:36	+/–
> Так ты не можешь без amdgpu использовать vulkan и dxvk. AMDGPU нынче цепляет что угодно от GCN 1.x и новее. И на всем этом соответсвенно есть Vulkan. Кто-то даже для Radeon 6000 (VLIW) запилили экспериментальное нечто - Terakan.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #5 Ответы: #39

29. Сообщение от Аноним (-), 30-Окт-25, 20:46	+/–
> Вместо того, чтобы улучшить оптимизатор в LLVM, они новый компилятор делают. Этой блевотной корпоративной блоатвари ничто не поможет. Оно под эгидой догнать и перегнать GCC - стало жирным тормозным уродом, огроменным, жрущим сотни памяти, тормозным как черти что, с убер-огромной либой, одной на все - и более 9000 слоев оптимизаций - которые стали часто играть с этим монстром дурную шутку, похабя код. Девелопать LLVM это вообще сильно отдельная боль, из-за невъ....ного размера либы и времен компила и линка оной под стать. Не говоря о том что билдсистема этого корпоративного урода это совершенно отдельный шитпарад кластерфака софтварной инженерии с какими там питонами-электронами и скачкой половины интернета. Так что пока вы добавите в этого монстра оптимизаций, на горе рассвистится рак. После дождика в четверг високосного года. > Это тупиковый путь, LLVM такой неэффективный потому, что жирный. Когда вальвовский > компилятор всосёт столько же бэкендов Он делает 1 штуку - и делает ее хорошо. Генерит шейдеры. > (а если он взлетит, то неминуемо всосёт), Я думаю что всосет - не он, а LLVM, вместе с фанами. Впрочем - уже. Как минимум - фичи. > сколько LLVM - он скатится ниже уровня LLVM (то есть упадёт на взлёте). "Когда убьют - тогда и приходите" :) > Поэтому не LLVM резать надо, а улучшать LLVM, чтобы он мог ещё кучу бэкендов всосать, Видимо Valve посчитал что проще - написать с ноля чем с тем ужасом связываться. А LLVM можно использовать на хэллоуин - айтишников пугать! Абсолютно уродский проект, хучшая иллюстрация на тему того во что корпы + оверинженерия могут слить софт.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #38

30. Сообщение от Аноним (-), 30-Окт-25, 20:50	+/–
> Что там за вопрос про LLVM был? Да вот видишь ли какой нюансик - для оптимизаций LLVM кодогенератора надо пересобирать LLVM и его обвес. И тут оказывается что это нифига не быстро - а билдсистема этой дряни еще и отборный корпоративный кластерфак. Корпы типа гугла имеют проклятие: превращают билдсистему в адовое месиво.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #22

31. Сообщение от Аноним (31), 30-Окт-25, 21:26	–1 +/–
Купи себе немножечко чувства юмора, и сразу все станет понятно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

32. Сообщение от Аноним (-), 30-Окт-25, 21:26	+5 +/–
> Polaris уже 9 лет стукнуло, GCN 4. Вот GCN 5 Vega еще > будут держать, за счет igpu в зоопарке ноутбучного железа apu ryzen. А чего вам не хватает то? Там вулкан - одинаковый на всю толпу чуть не до GCN 1.x ажно. Валв между прочим решил кажется всерьех допинать AMDGPU до работы с GCN 1.x по дефолту. В ядре 6.19 будет - работа DC (внутренняя либа в ядре для работы с display controller) работающий с GCN 1.x и даже - аналоговыми выходами. И кстати для некоторых более поздних тоже. Чего DC изначально отродясь не умел. Пока Valve не пришел и не запилил сие. В итоге GCN 1.x будут вероятно юзать всю ту же инфру что и остальные AMDGPU по дефолту. Вулканы, генераторы шейдеров и проч там опять же такие же как и на всех остальных AMDGPU. Так что вот на что AMDшные юзеря точно не могут жаловаться так это на то что их прокатили с старыми видяхами. Нифига, поддержка просто топчик. Лучше чем у остальных. В GCN 1.x вулкан даже на коробке не обещали, только mantle. А он там между прочим такой же как и на всех остальных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

33. Сообщение от Аноним (33), 30-Окт-25, 21:57	+1 +/–
> У меня, как энтомолога-русоведа есть к тебе вопросик: что тебя и таких > как ты заставляет коверкать названия фирм? Все эти «вольво» вместо «вальве», > «межделмаш» вместо «IBM» и так далее. International Business Machines Meждународные Деловые  Машины Меж    Дел    Маш Не благодари
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26 Ответы: #34

34. Сообщение от В афиге (?), 30-Окт-25, 22:19	–2 +/–
И они так не называются Фирма называется IBM, фирма называется Valve и так далее А если тебя называть кретином, то это будет так же смешно? Ну то есть это будет соответствовать действительности, но будет ли тебе так же смешно?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #37

35. Сообщение от Аноним (35), 30-Окт-25, 22:35	+/–
> И зачем оно?! Очередной костыль. Этот "костыль" улучшает абсолютно все мыслимые параметры генерации шейдеров - и жор памяти при компиле, и скорость компила, и размер бинаря шейдера, и скорость его работы. Ну так, как говорят ченжлоги - "много мелких улучшений". Хотя, скостить время компила шейдера в 8 раз - не так уж и мелко пожалуй.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #16

36. Сообщение от кексперт (?), 30-Окт-25, 23:46	+/–
А вот кстати правильная идея. Есть вообще толковые гайды по тому как устроены видео-дрова в линукс? А то реально голова кругом -- под каждого вендора куча либ, что-то устарело, что-то только пилится, что за что отвечает...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #40

37. Сообщение от Аноним (33), 31-Окт-25, 00:19	+1 +/–
> И они так не называются > Фирма называется IBM, https://www.ibm.com/investor/att/pdf/IBM_Annual_Report_2022.pdf > The financial section of the International Business Machines Corporation (IBM or the company) Кекспертиза во все поля. > А если тебя называть кретином, то это будет так же смешно? Ну > то есть это будет соответствовать действительности, но будет ли тебе так же смешно? "Свербит" тут походу только у тебя. И совсем не в голове ...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34 Ответы: #53

38. Сообщение от Буратино (?), 31-Окт-25, 00:32	+/–
Расскажи подробней чем так плох LLVM. У меня на работе макохипстота всё хочет "элэлвээму", а я как отбитый ретроград заставляю сидеть на "старом добром надёжном проверенном гэцэцэ" Правильно делаю или не очень?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #29 Ответы: #41

39. Сообщение от aaa (??), 31-Окт-25, 01:03	+/–
не запилили, а пилит. Там один Виталий Кузьмин этим занимается, несмотря на то, что Марек Ольшак его отговаривал. https://gitlab.freedesktop.org/Triang3l/mesa/-/commits/Terak...
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28 Ответы: #55

40. Сообщение от Аноним (-), 31-Окт-25, 01:07	+1 +/–
> А вот кстати правильная идея. Есть вообще толковые гайды по тому как > устроены видео-дрова в линукс? > А то реально голова кругом -- под каждого вендора куча либ, что-то > устарело, что-то только пилится, что за что отвечает... В самом базовом виде: DRM/KMS/GBM <-> libdrm+plugin <-> various clients                              _client 1 (e.g. Xorg + DDX)   Kernel    <- drm libs  -> /_client 2 (e.g. OpenGL@MESA)                             \_client 3 (e.g. Vulkan, ... ) Т.е. на нижнем уровне модули ядра, рулят видеорежимами (KMS) и базовыми аспектами рендера и работой с GPU (DRM) и управлением памятью GPU (GBM). Это ядерная часть драйвера. У амд это AMDGPU и Radeon (модули ядра). Юзермод как правило не дергает это напрямую сисколами и вместо этого интерфейсится через libdrm (+ ее плагин для энного GPU) для упрощения жизни. Это некий intermediate layer, не очень интересный чаще всего. А дальше - к этому разные клиенты цепляются. Например MESA как реализация GL/Vulkan/чего там. Ессно ее версия достаточно важна в плане фич и багов. У Xorg есть еще понятие DDX драйвера но он уже сюжетно не важен ибо то что делают Xorg настолько не ложится на современные GPU что гонять их с DDX типа "generic KMS" бывает даже быстрее чем "более специфичным для энного GPU". Поэтому версиями DDX компонентов можно не сильно париться, мало на что влияет. У нвидии может быть чуть иначе, но в целом их прожали и общая структура стека - такая же. Т.е. их ядерный модуль реализует свой вариант KMS/DRM/GBM и работы с ним - но поверх этого как клиент цепляется свой проприетарный юзермод. Нвидия в конце концов замучалась сама DRM/KMS пилять и открыла модули. Но они не в майнлайне и юзерям полегчало не сильно. У амд так можно зацепить проприетарный драйвер - с поправкой что тот работает сразу поверх модуля AMDGPU из майнлайна, проприетарный только юзермод.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #36 Ответы: #42, #43

41. Сообщение от Аноним (-), 31-Окт-25, 01:47	+/–
> Расскажи подробней чем так плох LLVM. > У меня на работе макохипстота всё хочет "элэлвээму", а я как отбитый > ретроград заставляю сидеть на "старом добром надёжном проверенном гэцэцэ" На самом деле честный ответ - "зависит от конкретики". У LLVM есть некоторые интересные фичи, в крутоте и инновациях типа C++2* всяких или продвинутой диагностике там рубка 50/50 примерно. По кодогенерации они были более-менее похожи по качеству, но в новых версиях LLVM начинает впадать в маразм и порой делать дичь, на манер старых GCC. Просто LLVM по мере наворачиваний оптимизаций и проч в потугах догнаьт и перегнать gcc.. 1) продолбал все преимущества по части скорости компила. И стал жирным неповоролтливым монстром. Куча продвинутых оптимизаций - это не бесплатно. 2) Архитектура странная. Вообще вся кодогенерация - для всех таргетов - в ОДНОЙ убер-либе. Никогда не видели .so размером 100+ мегов? Посмотрите на LLVM свежих версий. Увидите! Мне кажется что этот подход имеет проблемы с масшитабированием, особенно по мере добавления таргетов и оптимизаций. 3) Оптимизации навернули так что последние версии порой впадают в маразм. В лучшем случае они генерят раздутый и тормозной код. В хучшем глюкавят на манер старых GCC выдавая некорректный код. 4) Если приспичило наисвежайший gcc под не очень попсовый таргет, отстроить себе тулчейн довольно просто и ненапряжно. Повторить такой номер с LLVM и Clang - сильно более другия история по объему траха, build deps и времени на это приключение. > Правильно делаю или не очень? В таком глобальном аспекте - сильно зависит от конкретики. Но никаких особых золотых гор от замены GCC на clang вы в обшем случае не получите. Там есть пару фич которых в GCC нет, но - очень нишевых. Типа какого-нибудь инструментирования CFI для ядра. Но если вы этим не занимаетесь то и нахрен оно вам тогда. Т.е. на мой вкус для того чтобы дергаться надо иметь измеримый бенефит с этого. У gcc тоже в новых версиях фичи бывают, опять же. А как показал пример GPU, для GPU вообще получается - дичь. И амд уже огребали неудобные вопросы какого дьявола за столько времени впаха над LLVM настолько похабные результаты. Valve вообще это надоело - и они сделали другой компилер шейдеров. Без того счастья. И когда разница в 8 раз по времени компила и код лучше во всех смыслах - видимо, идея юзать LLVM для GPU вообще, пожалуй, была не особо удачной, коли такие соотношения. А valve что, они шкурно заинтересованы не в концепциях и замене ежа ужом - а максимизации своего профита. И фигачат так как лучше всего работает. Потому что у них SteamDeck и его хочется продать. И побольше. И игр к нему еще. Для чего быстрая качественная генерация шейдеров на AMD GPU ессно - мастхэв. Они и пашут как черти.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #38 Ответы: #68

42. Сообщение от morphe (?), 31-Окт-25, 01:50	+/–
> с поправкой что тот работает сразу поверх модуля AMDGPU из майнлайна Поправка - они перестали поддерживать свои проприетарные и грворят всем переходить на опенсорс Проприетарные оставили существовать только ради полутора проприетарных софтин о которых никто не знает и не пользуется Ну и проприетарные дрова просто были слишком медленные в сравнении с mesaвским gallium
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #47

43. Сообщение от кексперт (?), 31-Окт-25, 02:58	+/–
Насколько я понял весь этот винегрет, за исключением модулей ядра, пытаются систематизировать в рамках freedesktop.org
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #40 Ответы: #48

44. Сообщение от Аноним (44), 31-Окт-25, 03:23	+/–
Вот только почему у них такой интузязизЪм, немножко непонятно. Им как продаванам игорь то какой интерес поднимать не тянущее из игры железо?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #24 Ответы: #46

45. Сообщение от Аноним (44), 31-Окт-25, 03:30	+2 +/–
А ведь когда-то шейдеры лежали в shaders.bin и не требовали компиляции по пол часа при каждом запуске. Вот ведь были времена...
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

46. Сообщение от Аноним (-), 31-Окт-25, 04:08	+2 +/–
> Вот только почему у них такой интузязизЪм, немножко непонятно. Вероятно хотят уменьшить себе технических проблем, улчушить продажи и расширить экосистему. Учитывая что MS им своим виндостором по сути может бизнес убить и подмял несколько игроделов в свое время - Valve рубится за свою экосистему в режиме all-out. Поэтому им совсем не лишне план как вести бизнес - совсем без MS, если тот окончательно озвереет, все заwalled-garden'ит и передушит альтернативные сторы типа Steam. > Им как продаванам игорь то какой интерес поднимать не тянущее из игры железо? У нормальных двигунов - настроек как раз таки есть и они позволяют покрутить перфоманс <-> качество в широких пределах. И все это добро какое-нибудь 1080p на урезанных настройках потянет на ура. Более того. 1) На AAA играх мир не заканчивается. Есть легионы инди и проч которым убер топ видяху не надо. 2) Игры по сей день должны жить с тем фактом что бывают APU/iGPU и проч - которые довольно хилые. Если вы на это забьете, вашими клиентами будет очень узкая каста турбозадр@#в меняющих GPU раз в год. И выбирающих из топовых AAA игр. И удачи в ведении бизнеса, посмотрим как вы против мегакорп с AAA тайтлами удержитесь, при полутора клиентах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #44

47. Сообщение от Аноним (-), 31-Окт-25, 04:20	+/–
> Поправка - они перестали поддерживать свои проприетарные и грворят всем переходить на опенсорс Это для AMDVLK верно. Потому что RADV его сделал буквально во всех номинациях. Т.е. называя вещи своими именами, Airlied который лид графического направления Linux (майнтайнер подсистемы) - обставил производителя видях прямо на их поле. Или как вы показываете всей планете что вы профи высшего класса и настоящий лид технического направления, а не погулять вышли. Что там с остальными проприетарными частями я честно гря не следил. Они opengl прориетарский тоже выбросили? И еще есть отдельный юзермод поверх amdgpu ROCm, он не совсем проприетарский и номинально открытый. Но с поддержкой GPU там - похабно по версиям, они поддерживают полторы последние модели, это moving target и в целом - этому даже CUDA с ее периодическим дропом старых видях в последних версиях мастеркласс все же - дает. Так что оно веорятно всерьез юзается только полутора гиперскейлерами под AI и проч а остальными скорее избегается за такой экспериенс. Но это тоже +1 клиент DRM/KMS/GBM через AMDGPU как таковой. > Проприетарные оставили существовать только ради полутора проприетарных софтин о которых > никто не знает и не пользуется > Ну и проприетарные дрова просто были слишком медленные в сравнении с mesaвским gallium В случае вулкана там Airlied молодец, дал всем мастеркласс как это надо делать. Вот это - технический лид каким он реально должен быть.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #42 Ответы: #50

48. Сообщение от Аноним (-), 31-Окт-25, 04:27	+/–
> Насколько я понял весь этот винегрет, за исключением модулей ядра, пытаются > систематизировать в рамках freedesktop.org Большая часть usermode частей "клиентов" с реализацией того или иного API для того или иного GPU - в случае удачного девелопа становится частью MESA которая так же пытается предоставлять реюзабельные части - дабы каждая реализация апи того или иного GPU не была вынуждена изобретать свой вел с квадратными колесами на все вообще.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #43

49. Сообщение от Аноним (-), 31-Окт-25, 04:33	+/–
> А ведь когда-то шейдеры лежали в shaders.bin и не требовали компиляции по > пол часа при каждом запуске. Вот ведь были времена... Для шейдеров и сейчас есть кеш шейдеров. Ибо гамезы стали таскать 100500 навороченых шейдеров и времена старта игорей пока они там все это скомпилят стали конкретно всех задалбывать. Особенно с LLVM. Но при первом то старте - вы все же будете их компилять. И никуда от этого не денетесь. Ибо у разных GPU разный нативный код, а IR - это не оно и его все равно надо перегонять в нативный для конкретной видяхи формат.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #45

50. Сообщение от morphe (?), 31-Окт-25, 05:28	+/–
> В случае вулкана там Airlied молодец, дал всем мастеркласс как это надо делать AMDVLK был не то чтобы плохим, если с графикой работаешь то полезно было с ним сверяться как с альтернативной реализацией vulkan. Отставание там было не настолько большим, но у RADV было преимущество в том что часть MESA, и больше следует реализациям стандартов, а не самим стандартам. > Что там с остальными проприетарными частями я честно гря не следил. Они opengl прориетарский тоже выбросили Да, потому что он хуже gallium > И еще есть отдельный юзермод поверх amdgpu ROCm, он не совсем проприетарский и номинально открытый Если ты про OpenCL то это как раз тот про который я сказал что остался для пары проприетарных софтин, с него тоже советуют переходить на rusticl там где он поддерживается
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #47 Ответы: #51

51. Сообщение от Аноним (51), 31-Окт-25, 06:06	+/–
> AMDVLK был не то чтобы плохим, Просто... 1) Он слишком дофига был проприетарным и амд тупило на эту тему. Вплоть до момента получения мастеркласса от airlied'а. 2) Из-за таких соотношений весь девелоп ушел в radv. 3) Airlied как maintainer графония может помочь себе с другой стороны и знает что лучше всего работает в DRM/KMS. Знает ли это произвольный наймит из амд - вопрос номер два. Поэтому оно буквально с самого начала даже без особых оптимизаций плотно село AMDVLK на пятки. Дав понять что оно тут надолго и всерьез. А потом еще и ALL набежал пилить. Вот, Valve например опенсорсныые форматы - зашли. Они и пиляют то что удобно в этих форматах делать, под свои нужды. А поскольку они нормальные игроделы - это и почти всем остальным в том же виде и надо! :D > если с графикой работаешь то полезно > было с ним сверяться как с альтернативной реализацией vulkan. Просто нет смысла гробить ресурсы в бесполезную гонку. Даже у мегакорп девелоперские ресурсы - ограниченный актив. Тем более когда сильные конкуренты есть. Теперь лидировать будет airlied а контрибутить амд, и решения будут - его, а не тупарского манагемента амд. Это лучше. Ибо избавляет причастных от marketing BS типа поддержки последних микроверсий вулкана только для последних видях и чего там. Учитвая что вулкан версионируют мелко это могло бы превратить все в треш как куда/rocm. Но к счастью так не будет. > что часть MESA, и больше следует реализациям стандартов, а не самим > стандартам. У него преимущество в том что Airlied про в своем направлении и свое хозяйство знает лучше всех остальных. И умеет работать в опенсорсных форматах like a boss. Я проверл. Это самые крутые процессы девелопа софта на этом глобусе. Airlied знает как пускать их во благо себе и всем. АМД сам по себе - только с пинками таких как Airlied. > Да, потому что он хуже gallium У него в целом как-то довольно много оверхеда. А половина пойнта вулкана - дешевые draw calls. > Если ты про OpenCL то это как раз тот про который я > сказал что остался для пары проприетарных софтин, с него тоже советуют > переходить на rusticl там где он поддерживается Честно говоря, имхо, что тот BS, что этот. Поэтому сейчас прямо эпидемия переписки счета - на вулкан. Дофига программ вулкан юзают для явно счетных и GPGPU операций. Вот прсото для понимания, за последнюю неделю или 2 я вижу... 1) Blender собирается сделать ускорение через вулкан в очередной версии. 2) ffmpeg запилил декод ProRes через шейдеры вулкана. И даже откровенно счетные программы начинают предпочитать вулкан. Потому что то что с opencl творится - это позор какой-то. Что SUCm поддерживающий полторы последние видяхи в последних версиях и более нифига, что это тормозной глюкало "зато на расте" дропнувшее поддержку части видях при типа-декларациях типа-эквивалентности и превосходства. Пусть они с таким "превосходством" бамбук курят!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #60

52. Сообщение от Adb (?), 31-Окт-25, 10:37	+/–
Можешь не беспокоится, сделать не просто llvm , а производительный llvm это такой же шанс в мире как встретить НЛО в реальном времени.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #12 Ответы: #69

53. Сообщение от vvm13 (ok), 31-Окт-25, 10:46	+1 +/–
IBM = МежДелМаш - относительно смешно, хотя так себе; это более-менее перевод названия Valve = Вольво - совсем не смешно, откровенно тупо (в духе такого же тупого drivers = дрова); ни перевода, ни даже нормальной созвучности.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

55. Сообщение от Аноним (-), 31-Окт-25, 11:16	+/–
> не запилили, а пилит. Там один Виталий Кузьмин этим занимается, несмотря на > то, что Марек Ольшак его отговаривал. > https://gitlab.freedesktop.org/Triang3l/mesa/-/commits/Terak... Ну, в общем то, учитывая перфоманс этих штук и объемы VRAM - это скорее поприкалываться чем нечто реально практичное. Но как где-то было написано, в IT нет большего наслаждения чем превозмочь себя и раздвинуть границы возможного. Идея запилить вулкан на GPU на который его даже теоретически не сватали - по своему забавна в общем то.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #39

56. Сообщение от Аноним (56), 31-Окт-25, 11:23	+/–
> в качестве альтернативы компилятору шейдеров LLVM ... ACO даёт возможность повысить скорость компиляции шейдеров, снизить потребление памяти, сократить размер бинарного представления шейдеров и генерировать более оптимизированный код. Вся суть LLVM: тормознутый жрущий жирный тупой компилятор. Как и все продукты на нём.
Ответить | Правка | Наверх | Cообщить модератору

57. Сообщение от Аноним (57), 31-Окт-25, 11:37	–1 +/–
А что там добавлять? То, что в ядре - драйвер, то, что в mesa - юзерспейс библиотека. Драйвер создаёт файл в /dev, а в UNIX (и Linux), устройство это файл, да и вообще "всё это файл". Поэтому все, кто вам втирают что-то про "драйверы mesa", бессовестно Bpут. В Linux напрямую с драйвером видеокарты работает только одна программа, X-windows, это всё сильно упрощает, потому что на всякие низкоуровневые API можно не смотреть и просто пользоваться X-windows , и графика будет на любом экране и любом устройстве. Поверх Х сервера можно рисовать с помощью X Toolkit (xtk), -lXt, openmotif, -lXm, athena, xaw3d, много всего.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21 Ответы: #62

60. Сообщение от morphe (?), 31-Окт-25, 14:36	+/–
> Просто... > 1) Он слишком дофига был проприетарным и амд тупило на эту тему. > Вплоть до момента получения мастеркласса от airlied'а. Он изначально был открытым, он просто не переиспользовал mesaвскою инфраструктуру vulkan, это была самостоятельная реализация. Кроме того она помогла RADV оптимизировать, таки это вторая из двух открытых ркализаций вулкана под amdgpu. Речь не про гонку тут. Ни в коем случае не принижаю заслуги разработчиков mesa, но смешивать AMDVLK с грязью не позволю) > И даже откровенно счетные программы начинают предпочитать вулкан. Потому что то что > с opencl творится - это позор какой-то. Что SUCm поддерживающий полторы > последние видяхи в последних версиях и более нифига, что это тормозной > глюкало "зато на расте" дропнувшее поддержку части видях при типа-декларациях типа-эквивалентности > и превосходства. Посмотри какие видяхи они дропнули, современные процессоры быстрее тех видях. Старый просто некому поддерживать, а в новый поддержку старья просто не завезли, не надо тут про "выкинули" И поддержка там всё же лучше чем у ROCm, который умеет буквально самую последнюю и неофициально предпоследнюю. Но да, за vulkan compute будущее.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51 Ответы: #61

61. Сообщение от Аноним (-), 01-Ноя-25, 02:38	+/–
> Он изначально был открытым, он просто не переиспользовал mesaвскою инфраструктуру vulkan, Вообще-то это немного не так было. 1) Изначально AMDVLK был проприетарный. А Radv еще не было. 2) AMD формально пообещало открыть сорцы. 3) Обещать не значит жениться. Время шло, резину тянули, сорцы не откры Кивая на юридический отдел и что там еще. 4) В какой-то момент Airlied это все задолбало и он решил что попробует дать мастеркласс на тему как это должно быть на самом деле. 5) Он и еще 1 кекс на пару написали RADV. 6) И только когда тот показал что он надолго и всерьез, амд что-то там расчехлился по части открытия сорцов. Только оно уже ТОГДА никому не надо было. И энтузиазма ни у кого уже не вызвало. А не надо это все - потому что уже есть Airlied & Co и с ними работать куда приятнее того BS с юридческим отделом и постоянным динамо. Прикиньте? Мораль сей басни такова: добрым словом и пистолетом - можно добиться больше чем добрым словом. > это была самостоятельная реализация. Кроме того она помогла RADV оптимизировать, таки > это вторая из двух открытых ркализаций вулкана под amdgpu. Эта реализация была - напрочь пропреитарная пока Airlied не написал RADV и не прищемил амд кой-что в бенчах. Небольшая зарисовка на тему доброго слова и пистолета. И ессно никто потом не собирался комитить в это AMDVLK, нахрен надо когда Airlied есть. > mesa, но смешивать AMDVLK с грязью не позволю) Мне не требуется ваше позволение: я историю видел от и до. Своими глазами. Сюрприз. Так что это я вам не позволю - даунплеить заслугу оного перед сообществом. Если бы не он, есть шанс что AMD до сих пор бы кормил нас завтраками про открытие сорца, когда-нибудь, а пока вот вам полтора блоба с маркетинговым BS - и хватит с вас. А подобрели они с открытием сорца - после релиза RADV и того факта что он 1) Более менее feature complete 2) Начал по перфомансу делать AMDVLK, в т.ч. в AAA гамесах. 3) Valve заценил формат и навалился - в открытые дрова. В виде RADV ессно. А в AMDVLK вообще никто кроме амд всерьез не комитил AFAIK. Кому нахрен упало - убивать полгода на тормоза юридических отделов и прочие отмазки и маркетинговое динамо? Так что если амд что-то не нравится в таком восприятии этой истории - пусть с своим маркетинговым, юридическим или каким там отделом и теми кто саботировал релиз сорца и разбираются. А я не подписывался из чужих проблем - свои делать. Особенно вот так. > Посмотри какие видяхи они дропнули, современные процессоры быстрее тех видях. В конечном итоге - с моей стороны нет спроса на разработчиков, апи и проч которые девелопаются по этим принципам. Просто для понимания - у нормальных игроделов допустим двигло масштабируется в очень широких пределах. И можно поиграть даже на немолодой интеграшке. Но можно конечно ублажать и узкую горстку тех кто меняет железо раз в 1-2 года. Это либо считанные топовые гиперскейлеры с AI, либо узкая каста геймеров. Но эти поляны уже заняты, поделены, и меня и вас там - не ждут. И вы не победите на этом поле. А коли так - зачем мне топить за интересы конркурентов и обдирал? Я лучше за свои интересы буду. Т.е. максимально широкий охват железок апями и движками, минимизация моих затрат, оптимизиация профитов, ... И в этом смысле с моей стороны - доверия Airlied, RADV, компаниям типа Valve, и господам вокруг - больше чем хайпожорам которые умеют втирать мне очки и ставить меня и остальных на бабки. У них полися более удобные и дружественные ко мне чем у тех господ. И я буду взамен топить по их интерес. А вон те - должны умереть. И их апю я буду обходить - как чуму. > Старый просто некому поддерживать, а в новый поддержку старья просто не завезли, не > надо тут про "выкинули" Почему-то такие проблемы только у хайпожоров рассказывающих про якобы-эквивалентность фич и любителей маркетингового BS. Вот только делать из этого свои проблемы мне ни разу не с руки. Ни по линии девелопа и выбора апей, ни по линии использования, ни по линии завязки на такие апстримы с такими полисями в хоть каком качестве. > И поддержка там всё же лучше чем у ROCm, который умеет буквально > самую последнюю и неофициально предпоследнюю. На мой вкус оба - not good enough for me. Просто как апя, ее доступность по железу, качество реализации и вообще. Копаться в таком мусорном баке? Ну вы там сами этим и займитесь например. Зачем мне такое апи - хрен его там знает. При таких реализациях это - увы - полный фэйспалм. За счет этого мир захватила проприетарная куда. У которой фэйспалм и то не настолько суровый. > Но да, за vulkan compute будущее. Во всяком случае - я вижу как-то сильно больше девов по части полисей ЭТИХ апстримов и апей. А когда кто-то дроапет хардвар он таки демонстрирует недружественность апстрима и режет часть аудитории девам.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #60 Ответы: #63

62. Сообщение от Аноним (-), 01-Ноя-25, 02:46	+1 +/–
> В Linux напрямую с драйвером видеокарты работает только одна программа, X-windows, Эти сведения немного протухли. Я поздравляю вас с разморозкой вашей криокамеры но с 2000 года за четверть века - многое изменилось. И теперь этот наш графический стек устроен совершенно иначе. Во первых, напрямую с видеокартой работает теперь - ядро, как это и должно было быть с самого начала. Во вторых, иксы теперь не центр вселенной а "один из клиентов DRM/KMS". Такие же как всякие вулканы-GLи и проч. В третьих, у нас так то Wayland уже вообще появился. Это не Xorg. Но тоже клиент DRM/KMS. В четвертых, можно вот так по приколу на системе бех Xorg в консоли (KMSной) пнуть glmark2 какой - и посмотреть на хардварно ускоренное 3D - вот прям совсем без Xorg в системе. Круто, да? :) > это всё сильно упрощает, потому что на всякие низкоуровневые API можно не > смотреть и просто пользоваться X-windows , и графика будет на любом > экране и любом устройстве. Никто уже не юзает API W-windows. Юзают API тулкитов. > Поверх Х сервера можно рисовать с помощью X Toolkit (xtk), -lXt, openmotif, > -lXm, athena, xaw3d, много всего. И все это такое страшное что почти все программы рендерят битмапу нормальным тулкитом, от и до. И отдают Xorg (или вэйланду) - готовый битмап. Чтобы с этими ужастиками не связываться. Одна из причин по которой Xorg загибается. Как плевалка битмапа он крайне тормозной, оверинженернутый и проблемный.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #57

63. Сообщение от morphe (?), 01-Ноя-25, 03:13	+/–
> 1) Изначально AMDVLK был проприетарный. А Radv еще не было. Ты с чем то путаешь, AMDVLK был открытый с первого дня релиза в декабре 2017го, RADV тогда уже был релизнут Возможно AMDVLK и был собран из того что было закрытым под винду, однако факт в том что с момента релиза под Linux он уже был открыт. AMDGPU-PRO имел поддержку vulkan, однако ему до AMDVLK было очень далеко, корни у этого скорее от винды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #61 Ответы: #64, #65

64. Сообщение от morphe (?), 01-Ноя-25, 03:17	+/–
> AMDGPU-PRO имел поддержку vulkan, однако ему до AMDVLK было очень далеко, корни > у этого скорее от винды. AMDGPU-PRO при этом не рекламировался ни для кого кроме владельцев их профессиональных ускорителей у которых совсем другая экосистема, AMD никогда не предлагали ставить их проприетарный драйвер ради vulkan, некорректно утверждать что им была какая-то выгода от того чтобы люди переходили на AMDVLK
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63

65. Сообщение от Аноним (-), 01-Ноя-25, 23:25	+/–
> Ты с чем то путаешь, AMDVLK был открытый с первого дня релиза > в декабре 2017го, RADV тогда уже был релизнут Это ты что-то путаешь. Ибо сначала IIRC AMDVLK релизился только блобами в -PRO насколько я помню. А открыть его - обещали. Кормили завтраками. Довольно долго. Кивая на то что тупит юридический отдел. В какой-то момент Airlied этот позор - надоел. И он дал всем мастеркласс. > Возможно AMDVLK и был собран из того что было закрытым под винду, > однако факт в том что с момента релиза под Linux он > уже был открыт. Для сильно забывчивых или просто подтасовывающих факты я могу и напомнить, из первых рук: https://airlied.blogspot.com/2025/09/radv-takes-over-from-am... Не, майнтайнер графической подсистемы линя - врать не будет. Там и тайминги его штуки VS amdvlk и весьма скромная и выдержанная и политкорректная ремарка про "over the wall". Я могу и менее поликторректно расписать что я думаю про типа-"опенсорс" девелоп в стиле "нате на лопате" и динамо с релизами. > AMDGPU-PRO имел поддержку vulkan, однако ему до AMDVLK было очень далеко, корни > у этого скорее от винды. Я так понимаю что AMDVLK и есть по сути порт того что под винду было. Т.е. это видимо и были - близкие родственники. И сначала амд всех динамило рассказами что будет-будет, открытый, но юридический отдел тормозит, bla-bla-bla. Airlied показал как это делать правильно. И после этого да, юридисческий отдел конечно тормозить перестал. Только вот поздняк, господа.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #63 Ответы: #66

66. Сообщение от morphe (?), 02-Ноя-25, 01:02	+/–
> Для сильно забывчивых или просто подтасовывающих факты я могу и напомнить, из первых рук: Он тут не говорит что AMDVLK был закрытым, он тут говорит что это была закрытая разработка + открытые исходники > Я так понимаю что AMDVLK и есть по сути порт того что под винду было Я всё это говорил к тому что в AMDGPU-PRO был не AMDVLK, а свой полурабочий велосипед, AMDVLK работал намного качественнее чем то что было в AMDGPU-PRO. И до релиза в декабре 2017го его просто не существовало под Linux, о чём airlied тоже написал > When Bas and I started radv in 2016, AMD were promising their own Linux vulkan driver, which arrived in Dec 2017. Они не просто обещали его заопенсорсить, они обещали его вообще сделать, что они и закончили в декабре 2017 и в тот же день заопенсорсили. Не существовало никогда блобов AMDVLK под linux
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #65 Ответы: #67

67. Сообщение от Аноним (-), 04-Ноя-25, 03:36	+/–
> Он тут не говорит что AMDVLK был закрытым, он тут говорит что > это была закрытая разработка + открытые исходники Возможно его сперва не называли AMDVLK, просто поставляли в проприетари. Вот тут не помню. В любом случае - насчет дат кое-кто прогнал. RADV релизнулся раньше AMDVLK о чем там и написано. Насколько я помню Bridgman на форониксе, чтоли, писал что там юридический отдел с clearance этого - тупит. Так ли оно? А поди проверь. С этого станется и марктеинг динамо от амд выгородить. >> Я так понимаю что AMDVLK и есть по сути порт того что под винду было > Я всё это говорил к тому что в AMDGPU-PRO был не AMDVLK, > а свой полурабочий велосипед, AMDVLK работал намного качественнее чем то что > было в AMDGPU-PRO. Мы о чем тут говорим? О том на чем базирована кодовая база? Или что где-то опосля AMDVLK до ума довели? Это 2 совершенно разные ипостаси. Кодовую базу мы даже сравнить чисто технически не сможем, за отсутствием сорца > И до релиза в декабре 2017го его просто не существовало под Linux, > о чём airlied тоже написал А еще он написал что его RADV под линух появился - раньше. Так что по большому счету - "помер Аким - и фиг с ним". А какой пойнт в драйвере который... 1) В лине надо качать отдельно. 2) Девелопаемый over the wall. 3) Более тормозной. Девелоп такой шляпы - не имеет никакого технического смысла. Это просадка ресурсов корпы на хз что. Они вместо этого могут допустим RADV девелопать. >> When Bas and I started radv in 2016, AMD were promising their own Linux vulkan driver, which arrived in Dec 2017. > Они не просто обещали его заопенсорсить, они обещали его вообще сделать, что > они и закончили в декабре 2017 и в тот же день заопенсорсили. Ага, несомненно, за 1 день сделали кодовую базу и вывалили ее over the wall. Сами то в этот BS верите? > Не существовало никогда блобов AMDVLK под linux Зато как я понимаю существовал - предшественник оного, и юридический отдел нехило отдинамил всех до того как это стало можно как AMDVLK на публику отрелизить. Называя вещи своими именами, что интел, что амд - софт девелопать вообще не умеют толком. А опенсорс over the wall это вообще бессмысленно и беспощадно.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66

68. Сообщение от Аноним (70), 04-Ноя-25, 22:05	+/–
>продолбал все преимущества по части скорости компила Не очень важна, важно качество. Компилится один раз, а исполняется - много раз в секунду. >Архитектура странная. Вообще вся кодогенерация - для всех таргетов - в ОДНОЙ убер-либе. Никогда не видели .so размером 100+ мегов? Посмотрите на LLVM свежих версий. Увидите! Мне кажется что этот подход имеет проблемы с масшитабированием, особенно по мере добавления таргетов и оптимизаций. Имеет проблемы. Сам LLVM тормознуто и жруще компилится. Одна из мечт - чтобы я мог добавлять таргеты без перекомпиляции LLVM, чтобы просто моя маленькая shared-либа линковалась с LLVMовскими и грузилась компилятором как плагин. >3) Оптимизации навернули так что последние версии порой впадают в маразм. В лучшем случае они генерят раздутый и тормозной код. В хучшем глюкавят на манер старых GCC выдавая некорректный код. У меня микробенчи показывают, что у LLVM код быстрее, чем GCCшный, иногда даже вдвое-втрое, а иногда - в десятки раз, если это GCC впал в маразм и не векторизовал то, что шланг векторизовал. При этом clang очень нетерпим к UB. Я вот иногда в старые игрушки играю ... и в этих старых игрушках, где с декомпилированным кодом, где с коряво написанным кодом времён доса ... идут странные сигсегвы, потому что инлайнинг и удаление ветвей, где UB - это bread and butter всех компиляторов. Вот clang это делает очень агрессивно, и хрен там разберёшь, в чём дело, особенно если это через посредничество кучи делается, а ты с кодом не знаком. А ещё clang очень не любит некоторые UB до такой степени, что их прям в открытую не позволяет, будет ошибка компиляции, приходится сидеть и руками ковыряться в говне, иногда даже рефакторя несколько функций и классов, когда планируешь прям взять, скомпилить и начать играть. Но таков опенсорс, и приведение  этого говна в порядок - это только малая часть, как я могу отблагодарить сопровождающих и оригинальных авторов за то, что они опубликовали проект в опенсорс и поддерживают его. >4) Если приспичило наисвежайший gcc под не очень попсовый таргет, отстроить себе тулчейн довольно просто и ненапряжно. Повторить такой номер с LLVM и Clang - сильно более другия история по объему траха, build deps и времени на это приключение. Сильно сомневаюсь. Все компиляторы внутри - это такой ужас, в который лучше вообще не лезть. Если ты можешь gcc под себя переделать, то ты можешь и в LLVM таргет добавить. Ненужной инфы в голову придётся больше закачать, но зато результат будет сопровождаемым. Твой кастомный gcc тебе самому придётся патчить под новые версии, и это будет не сахар. Ты на это забьёшь, и окажется твой gcc мусором бесполезным, потому что если нет C++26 со всеми смузи - то не нужен твой gcc, потому что мы компилятор берём именно за то, чтобы он при нужных либах за нас нашу работу делал, а твоё старьё так не сможет. А clang - сможет, ему только стандартную либу языка портируй. То есть я беру твою стандартную либу для gcc, копирую её в папку, беру, копирую пару хедеров из новейшего системного gcc, самую чуточку правлю, и использую для c++ либу, идущую со шлангом, она к таргету не прибита. Всё, у меня новейший C++ компилятор с новейшими смузи. Да, под задрипанный эмбеддед, про который эмбеддидщики будут нудеть "пиши на си, а лучше вообще на ассемблере", а я взял и на C++26 написал, и отлично работает. Единственное что - маленький патчик пришлось прислать в LLVM и ждать месяц пока его примут. Ну и пропатчить оригинальные сишные хедеры, заменив gссные аттрибуты на clangовые. Эти хедеры я тоже патч прислал авторам стандартной библиотеки, но им пофиг, они х просто проигнорили, ибо им не нужно. Вот что наличие поддержки ISA в LLVM животворящая делает. >Но никаких особых золотых гор от замены GCC на clang вы в обшем случае не получите. Общих случаев не бывает, но что для Zen 1, что для "коры дуба" (все 64 бита) код от clangа показывает на микробенчмарках меньшее число тиков.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #41

69. Сообщение от Аноним (70), 04-Ноя-25, 22:13	+/–
И давно вы с НЛО встречаетесь?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #52

70. Сообщение от Аноним (70), 04-Ноя-25, 22:17	+/–
>Повестку обновите. Это в госуслугах.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема