Я, кстати, когда собирал DirectXShaderCompiler, подумал про одну штуку, а вот написать про нее - не написал.

Я почему-то всегда считал, что clang/llvm - это "второй среди равных" компиляторов. Так как я с clang практически с самого его рождения, то привык считать, что он всегда находится в догоняющих, по отношению к gcc, позициях.

Поэтому, когда я затеял собирать #ix clang'ом, то думал, что я в "меньшинстве". Возможно, оно так и было, в 19 году.

Но так-то, если подумать, то сейчас clang - главный компилятор С++, потому что:

* В любом tooling его библиотеки. Собственно, dxsc тоже.
* *BSD собираются clang
* macos/ios собирается clang - а это, на минуточку, один из самых популярных сторов приложений!
* С недавних (ну, как недавних, так-то уже дофига времени прошло) пор android (даже ядро для него!) собирается кленгом, и, полагаю, нативные приложения (которые без jvm) в сторах - тоже.
* Непустое количество дистрибутивов Linux, собираемых clang. И не только мой #stal/IX, а та же Open Mandriva.
* Самые популярные программы на любом компьютере (браузеры) собираются clang (chrome, webkit, и все производные). Vscode? Electron?

Удел gcc сейчас - это серверные дистрибутивы в датацентрах, и, так-то, это довольно узкая область, да хотя бы по числу инсталляций! Но и в них без llvm никуда, потому что llvm широко используется во всякого рода компиляторах шейдеров (#mesa).

Ну и получается, что случайное приложение, которое ты используешь, собрано clang, а не gcc.

Такие дела.

https://www.phoronix.com/news/RadeonSI-ACO-Complete #aco

Совершенно классная новость - коллеги из #mesa добавили в драйвер opengl radeonsi возможность использовать компилятор шейдеров ACO, из vulkan драйвера radv.

Я напомню, что одной из причин моих мучений с #zink как раз была необходимость собирать (и влинковывать во все программы, которым нужно 3D ускорение) толстые запчасти из LLVM.

Теперь zink становится для меня существенно менее релевантным, хотя я и продолжаю считать, что в long term opengl драйверы должны исчезнуть, как класс, остаться должны только vulkan драйверы, ну и zink, как generic opengl поверх. В этом контексте можно упомянуть https://www.phoronix.com/news/Mesa-23.3-rc1-Released - open source vulkan для NVidia цветет, пахнет, и развивается, что тоже очень хорошо.

https://registry.khronos.org/EGL/extensions/ANDROID/EGL_ANDROID_blob_cache.txt

А вот, кстати, кеширование шейдеров здорового человека. Нормальный протокол для регистрации своего key/value хранилища, можно хоть memcached прикрутить.

Вот бы в #mesa его начали использовать консистентно, а я бы прикрутил mamcached, или там redis? С активацией через dbus, чтобы не висело постоянно.

Мечты, мечты...

Так, я нашел время обновиться на #mesa v. 24, перейти на использование ACO вместо LLVM, для компиляции шейдеров, и даже замерил экономию в размере получающихся программ:

llvm:

pg# ls -la .../bin/imhex
157265936 Jan 1 2000 imhex

aco:

pg# ls -la .../bin/imhex
88756648 Jan 1 2000 imhex

Очень и очень немало, почти 70 мегабайт разницы, вот столько весит используемый оптимизатор из LLVM.

#mesa #opengl #valve #zink #NVK

https://www.phoronix.com/news/NVK-Explicit-Sync-Valve

Надо сказать, что Valve системно поднимает графический стек Linux из руин, в которых он пребывал последние лет 20. Все #хорошее в графике Linux делают корпорации!

Надо сказать, что однажды в Linux было очень неплохое 2D ускорение, но, по мере усложнения аппаратной начинки, все это катилось в глюкавое и ненадежное говно, в которое вендоры иногда щедро подливали своих бинарных блобов, которые нормально работали примерно только на машинках их разработчиков, то есть, почти нигде.

Вроде, есть Intel, есть AMD, которые выкатили oss драйвера, а теперь вот и Nvidia, но починкой всего стека системно занимается именно Valve.

Не думаю, что они делают это для благотворительности, и у них есть понятный коммерческий интерес, но, в целом, их вклад сложно переоценить.

https://www.supergoodcode.com/My-Wayland-Your-Wayland-Our-Wayland/

И пост от одного из разрабов Wayland, который предложил папку experimental, он же, по совместительству работает в #Valve, над #zink, #mesa.

Пишет, "давайте жить дружно", ага.

Бесят, бесят меня эти "мейнтейнеры", которых нужно нанять за большие деньги, только чтобы сделать нужный коммит в нужное место.

А просто так принести точно такой же коммит с улицы - "не, оно нам не надо, не вписывается в идеологию".

Напомню историю.

#valve завела свою репку, куда начала класть свои протоколы для #wayland.

Вот коммит с поддержкой одного из этих протоколов в #mesa - https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/31329/#note_2580654 (называется он fifo).

И, ВНЕЗАПНО, выходит новый wayland - https://www.opennet.ru/opennews/art.shtml?num=62038, где:

"fifo - реализует FIFO-механизм (первым пришёл - первым ушёл) обработки очереди обновления содержимого отображаемой поверхности. С практической стороны протокол позволяет при выводе использовать ожидание завершения вертикальной развёртки (vblank) вместо использования callback-вызовов при каждой готовности отобразить новый кадр, что решает проблему с высокой нагрузкой на GPU при использовании VSync"

Что очень забавно, этот новый протокол попал в wayland, минуя все необходимые стадии рассмотрения - https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/main/staging/fifo

Угу, 22 часа назад положили сразу в staging, минуя unstable, и выпустили свежий релиз.

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/256#note_2606688 - вот тот самый MR с обсуждением, где, как обычно, это все мурыжили год, но, ВНЕЗАПНО, неделю назад, пришли все, кто имеет там право голоса, и проголосовали "ЗА".

Совпадение?

Сомнительно это нам.

Будни #bootstrap, #mesa, #opengl

В https://t.iss.one/itpgchannel/1350 писал про то, как ловко я обошелся с плагинной системой Mesa.

Все шло хорошо, пока разработчики mesa не решили перестать жить во грехе (это когда они делали вид, что отдельные их драйвера - это #plugins, которые как бы не зависят от ядра, и могут быть загружены в runtime), и начали жить как все нормальные люди.

В релизе 24.2.X, они, тихо и незаметно (ну или я не нашел в changelog), стали линковаться с libgallium.so, вместо того, чтобы загружать ее, как драйвер.

Кажется, я должен был быть очень доволен, всратых плагинов стало меньше?

С одной стороны, да, а с другой - я уже привык к тому, что сборка mesa в два этапа (отдельно ядро, и отдельно драйвера) позволяет мне делать зависимость от драйверов только у конечных программ, а не у всего кода, которому зачем-то нужно скомпилироваться с заголовками от opengl, но в runtime opengl не используется. Ну и cache hit так при сборке больше.

Поэтому я взял да и плагинифицировал эту часть mesa взад.

Собственно, это было очень просто, ядро mesa зависит от от libgallium.so всего по одной функции - https://github.com/pg83/ix/commit/04c0c3c9d6392089f2ea452d70c354cf22ae1c0f#diff-028186b4b1abb1353b6639ea94857e1aa9c5a91debd070b864799052bb502644R5 Раньше она загружалась через dlopen, а сейчас связывается во время линковки.

Ну так я и запилил stub, который вызывает dlopen (который, напомню, у меня не настоящий dlopen, а статически слинкованная фабрика - https://t.iss.one/itpgchannel/1230), чтобы все работало "как раньше", и чтобы можно было связать драйвер с приложением только в момент линковки этого приложения!

В 24.3.X основной код и libgallium.so проникли друг в друга еще больше, и разделить loader и driver больше не получается. Что самое интересное, несмотря на это, mesa продолжает подгружать какие-то запчасти через dlopen #plugins. Надеюсь, они понимают, что делают, потому что, со стороны, это выглядит как перекладывание из пустого в порожнее.

Поэтому я сегодня грустный панда, #mesa стала пересобираться существенно чаще.

Задумался про то, чтобы запилить кастомный opengl loader, по типу https://github.com/anholt/libepoxy, или https://github.com/NVIDIA/libglvnd, только попроще, чтобы продолжать собирать код с таким вот loader, и делать зависимость на конкретную реализацию только в конечных приложениях.

Каждый уважающий себя программист должен запилить opengl loader.

Вот, я запилил!

Недавно один там коллега в одном там рабочем PR притащил ссылку на https://github.com/yugr/Implib.so (а коллега пилил статический загрузчик для CUDA, если это вдруг важно).

Приблуда умеет для заранее подготовленной .so запилить import lib (эта штука хорошо известна в windows, потому что там принято так загружать .dll, и почти не известна в мире unix).

По сути, для набора функций из заданной .dll/.so генерируется набор заглушек, которые лениво загружают набор указателей на функции из заданной .so, и передают управление по этому указателю.

Единственной сложностью было то, что приблуда получает на вход .so, а у меня список функций, но я это изящно обошел тем, что сгенерил фейковую .so, которая содержит все нужные функции, а на нее уже натравил эту тулзу - https://github.com/pg83/ix/blob/main/pkgs/die/dl/implib.sh#L24-L33

Фасад у этого довольно приятный - просто цель с именем импортируемой либы, и списком импортируемых функций - https://github.com/pg83/ix/blob/main/pkgs/lib/opengl/loader/egl/ix.sh

Ну и так 4 раза, для всех релевантных библиотек из поставки OpenGL #mesa.

Вторая часть - заголовки.

Их я взял из https://github.com/NVIDIA/libglvnd - они там лежат в готовом виде, нужно просто скопировать, без мороки со сборкой.

Полностью #herobora выглядит так - https://github.com/pg83/ix/blob/main/pkgs/lib/opengl/loader/ix.sh (это я тут хвастаюсь, как умею собирать их из своих "стандартных" кубиков).

Забавно, но оно просто взялось, и заработало, даже неожиданно.

Ну, по модулю того, что mutter требует нестандартный opengl заголовок из #mesa, ну да и хрен с ним.

#future #zink продолжает вытеснять остальные opengl драйвера - https://www.opennet.ru/opennews/art.shtml?num=62860, как я и предсказал нескольк лет назад (https://t.iss.one/itpgchannel/648 https://t.iss.one/itpgchannel/126)!

"Компания Сollabora сообщила о принятии в кодовую базу проекта Mesa изменения, заменяющего OpenGL-драйвер, применяемый по умолчанию для GPU NVIDIA, начиная с микроархитектуры Turing. В следующем выпуске Mesa 25.1 вместо OpenGL-драйвера Nouveau (nvc0) для подобных GPU будет применяться разработанный в Сollabora OpenGL-драйвер Zink в связке с Vulkan-драйвером #NVK. По сравнению с Nouveau драйвер Zink демонстрирует более высокую производительность во многих тестах и не подвержен проблемам, проявляющихся в Nouveau при работе на новых GPU NVIDIA"

Правда, я вот сейчас активно пытаюсь выкинуть #mesa вообще, и попробовать построить альтернативный стек, типа #AMDVLK + #ANGLE. Зачем?

* интересно

* меня окончательно расстроило качество кода в #mesa, и чем его у меня будет меньше работать, тем спокойнее я буду спать. В конце-концов, Google не просто так запилил #ANGLE, и не просто так его начали использовать в WebKit.

Меня тут прямо расстроили:

"Связка #AMDVLK+ANGLE используется на последних смартфонах Samsung Galaxy S с процессорами Exynos+RDNA"

Вот хочешь изобрести #herobora, а, оказывается, уже кто-то сделал, и даже использует в проде!

#AMDVLK #mesa #ANGLE

После того, как я понял, что, в принципе, AMDVLK умеет жить без X, потому что он так живет на Android, я таки осилил его собрать, и даже позапускать какие-то приложения.

В целом, все работает, и у меня теперь ажно 3 различных реализации vulkan - https://github.com/pg83/ix/blob/main/pkgs/lib/vulkan/drivers/ix.sh#L3-L12

Собрать было не очень сложно, сложно было скачать, потому что они распилили кодовую базу на 7 частей, и склеивают их довольно странным образом, мне пришлось все это переработать, потому что CI в сеть не должен ходить, а их скрипты ходят.

https://github.com/pg83/ix/blob/main/pkgs/lib/amd/vlk/ix.sh#L58-L100

Из неприятного - произвольный бинарь с AMDVLK становится мегабайт на 50 толще, потому что они, зачем-то, хотят очень приличный кусок от LLVM, и не только сам LLVM (его много кто хочет, для шейдеров), а еще и запчасти от clang.

https://www.opennet.ru/opennews/art.shtml?num=63121

"Начиная с #Mesa 25.1 Vulkan-драйвер #NVK будет задействован по умолчанию для GPU NVIDIA Maxwell, Pascal и Volta. В Mesa 25.2 поддержка OpenGL для указанных GPU будет переключена по умолчанию с драйвера Nouveau на #Zink в связке с Vulkan-драйвером NVK. Zink предоставляет реализацию OpenGL 4.6 поверх Vulkan, позволяющую получить аппаратно ускоренный OpenGL на устройствах, поддерживающих API Vulkan. Производительность Zink близка к производительности родных реализаций OpenGL"

Большой день для графики в Linux - полностью свободный, и, главное, хорошо работающий, 3D стек для NVidia!

PS: пока все идет по моему прогнозу от 21 года - https://t.iss.one/itpgchannel/126, что opengl исчезнет в пользу zink/angle, поверх vulkan.

Я, когда читал код #mesa, у меня обычно из глаз шла кровь.

Вдруг, внезапно, за столько лет ее чтения, я понял, почему:

https://docs.mesa3d.org/codingstyle.html

"Basic formatting guidelines
* 3-space indentation, no tabs"

Это какой-то зашкаливающий уровень пиздеца, что просто нет слов.

Продолжаем тему "почему дистростроители не любят Rust"

https://gitlab.archlinux.org/archlinux/packaging/packages/mesa/-/blob/main/PKGBUILD?ref_type=heads#L103-144

Вот так, например, приходится приседать в Arch, чтобы доставить до сраной #meson сборки #mesa (которая, сама по себе, сошла с ума, и решила запилить сборку Rust без cargo, и его механизмов вендоринга) зависимости для компилятора шейдеров #NVK (драйвер для Nvidia vulkan).

Особенно автору всего этого добра доставляет копипастить версии руками, ага.

Мне еще это только предстоит, а я уже ненавижу этот процесс тихой ненавистью.

Давненько не рассказывал про #ANGLE.

Это смешно, но у меня, до сих пор, не получилось скачать его исходник.

Первая проблема, с которой я столкнулся - часть submodules c https://github.com/google/angle ведет на приватные, запароленные, гуглорепы.

Ладно, как-то я это обошел, точечно вырезав эти submodules.

Но вот то, что у меня произошло прямо сейчас:

Cloning into 'third_party/dawn/third_party/angle'...

Ну вы поняли, да?

Angle хочет в своем third_party Dawn, а Dawn в своем third_party хочет Angle.

Никто такого не ожидал, но они смогли - рекурсивно сослаться на себя же, в цепочке загрузки submodules. Этот процесс, очевидно, не имеет шансов сойтись.

В этот момент я заплакал (честно), и отложил это говно, на неопределенный срок.

За прошедшие сутки я успел:

* Почнить дедлок, про это будет отдельный пост.

* Попробовать собрать #ANGLE из более свежего хрома, с наскоку не вышло.

* Собрал более свежий #ANGLE из поставки WebKit, он там завендорен, с cmake сборкой. После этого оказалось, что там отключен рендер через Vulkan, ну и смысла в этом нет.

* Попробовал собрать "руками", разобравшись в структуре проекта (по мотивам скрипта из WebKit, который переделывает GN -> cmake), но это оказалось слишком сложным.

В итоге, придумал, как счекатутить ANGLE с github, убрав цикл по submodules, и собрал свежую версию родной GN сборкой.

де #vendor пришлось знатно - https://github.com/pg83/ix/blob/main/pkgs/lib/angle/ix.sh#L113-L123

В целом, сейчас конструкция кажется довольно надежной, и мой гештальт от 21 года (https://t.iss.one/itpgchannel/129), наконец-то, закрыт.

Сцуко, только я собрал 3D стек на основе #ANGLE + #AMDVLK, как выходит прекрасная новость от AMD:

https://www.amd.com/en/resources/support-articles/release-notes/RN-AMDGPU-UNIFIED-LINUX-25-10-1.html

"Consistent with AMD’s commitment to Open Source software, we will be making the following changes to the composition of the Radeon Software for Linux releases, starting with 25.20:
The Mesa Vulkan driver will be officially supported, along with Mesa OpenGL and Multimedia support. The AMD proprietary OpenGL and Vulkan drivers will no longer be included in the release.
AMF will no longer be included in the release. AMF users are advised to transition to VA-API / Mesa Multimedia. Some examples of ffmpeg use cases with VA-API / Mesa Multimedia are shown below:"

Что тут написано?

1) AMD больше не поддерживает свой проприетарный драйвер. Напомню историю - у AMD было два драйвера, open source, и проприетарный, который от open source отличался только другим компилятором шейдеров. В целом, дело хорошее, хотя я вот бы предпочел, если бы они открыли свой компилятор.

2) Самая мякотка - теперь они официально поддерживают user space часть драйвера от #mesa, вместе со своим kernel driver AMDGPU (типа, раньше Mesa работала на честном слове).

3) И, что хуже всего, пишут, что за аппаратным декодированием видео не надо ходить в #AMDVLK, а надо ходить в #Mesa.

Меня это расстраивает, так как тенденция обозначена явно - драйверу #AMDVLK уделяется меньше внимания, а для части фич он вообще не пригоден.

Боюсь, как бы его не прикрыли.