https://suricrasia.online/no-knowledge.html

Какая-то очень крутая тема(НЕ zero knowledge proof, это тоже красивое, но другое) - решение задачи "как бы передать кому-то строку, которая выглядит как hash, но не является хешом от каких-то известных тебе данных". Зачем это надо я ХЗ, но прикольно.

———

Продолжение темы про #Mesa и Vulkan. Я таки заставил его работать, это мне стоило 6 часов напряженной отладки. Бага причудливая. Товарищи сделали такой хак - пометили 100 экспортируемых функций как weak, но реализовали только те, что нужны. Драйвер вулкана в такой ситуации получал непустые реализации + nullptr для пустых. В случае статической линковки weak сработал не так, и в качестве реализаций взялись первые нулевые weak символы.

Vulkan, в целом, работоспособен, Sway с ним - нет. Если включить WLR_RENDERER=vulkan, то получаю черный экран, и это неудивительно, поддержка Vulkan в Sway появилась месяц назад. Если делаю MESA_LOADER_DRIVER_OVERRIDE=zink(фактически, форсирую реализацию OpenGL, которая работает поверх Vulkan), то получаю слегонца битую картинку. Неудивительно, думаю, Sway в таком интересном setup запускал только я.

Надо сказать, своей цели "собрать LLVM-free hardware accelerated stack" я достиг, бинарник Sway стал занимать 20 мегабайт.

Немного в сторону - прикольно осознавать, что подобную инсталляцию(musl + static build + clang + #zink + vulkan + sway) на этой планете, скорее всего, соорудил только 1 человек, хотя это тот еще неуловимый Джо.

Узнал прекрасное - в Linux есть 3 драйвера для AMD(Mesa, #AMDVLK, AMDVLK + proprietary code). https://www.linux.org.ru/forum/talks/16466478 Попробовал завести AMDVLK, но он требует X.

Valve топит за Mesa, потому что LLVM генерит медленные шейдеры.

https://chromium.googlesource.com/angle/angle/

#ANGLE

Я, давеча, писал про #zink - это OpenGL, реализованный поверх Vulkan(у меня сейчас на нем крутится Sway). Вот это похожая штука, только от Гугла. Я люблю код от Гугла, он у меня не вызывает неприятных эмоций(кроме ограничения на длину строки, но это лечится clang-format). Поэтому надо попробовать! Вырисовывается такой Mesa-free stack - ANGLE + #AMDVLK, или дрова от #Mesa для Vulkan + ANGLE.

———
Меня раздражают фанатики Rust.

Вернее, нет. Меня раздражают фанатики, фанатики Rust в том числе, никаких исключений.

Фанатики Rust хотят, чтобы все было через Rust, никаких исключений. Поэтому они, например, оборачивают C-код в свои crate. Например, libgit2 в Rust - это обернутый C libgit2. При этом, так как это же, все таки, фанатики, они хотят делать вид, что никакого C там нет, поэтому эмбеддят исходники libgit2 прямо в свой crate. А чо, удобно, не нужно возиться с пакетным менеджером, все сделает cargo. Проблемы maintainer никого не волнуют, конечно.

Так как я не люблю фанатизм ни в каком виде, то я такую деятельность не одобряю. К счастью, есть GPL(враг моего врага - мой друг!), поэтому обернуть libiconv таким образом нельзя. Поэтому я очень радуюсь, как у меня обламывается cargo, и просит libiconv из системы.

Ну, и, к счастью, есть проекты, до которых Rust вряд ли когда-нить доберется, типа Qemu. Желание писать на верхнеуровневых безопасных языках чаще всего антикореллирует с желанием копаться в хардверных мануалах, это хуже чем C.

"К счастью", "радуюсь" - потому что я против фанатизма, а вот эти конкретные факты этому конкретно фанатизму мешают. Забавно, что эти факты сами по себе мне тоже не очень ОК, GPL я не люблю, и в Qemu не помешало бы немного C++/Rust.

Это НЕ анти-Rust пост, я уверен, что однажды Rust и его поклонники переживут эти детские болезни, и не будут бояться(а то, вдруг, кто-то ткнет пальцем, и скажет, что чей-та у вас эта либа не на Rust!) использовать код из системы(и из системного пакетного менеджера).

https://www.phoronix.com/scan.php?page=article&item=apple-m1-compilers&num=1

После запуска Linux на M1 стало возможным проверить codegen от gcc для Apple M1. Под darwin оно уже давно сломано от слова совсем.

Я, если честно, сильно удивлен результату, gcc, в среднем, генерит все еще более лучший код для aarch64, несмотря на то, что clang - родной компилятор для M1.

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

———
Много ссылок про Wayland, без особого порядка и смысла, просто накопилось, хочу сбросить dump, чтобы перестать про них помнить.

https://www.reddit.com/r/linux/comments/u3m7s0/chromium_is_developing_support_for_using_qt_on/i4rg0jr/

Интересная ветка дискуссии про поддержку QT в Chrome, перетекло на дефекты Wayland, и на то, как сумасшедшие разработчики, захватившие власть в Wayland, не дают нормально работать людям.

Например, https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/132. Ну простая же задача, сделать поддержку картинки-в-картинке? Это такое оверлейное окно поверх всего остального.

"There's a merge request for adding PIP support to wayland-protocols, but as a surprise to absolutely nobody, it's stalled because some upstream developer thinks it shouldn't be done like specified, because it goes against the wayland philosophy. So, that's going to take optimistically 3 more years, for a really minor feature, to be officially supported with Wayland."

Ну так эти капризные мудаки, которым непонятно кто дал этот жалкий кусочек власти, начинают обсуждать космические корабли, бороздящие просторы Большого театра - "а можно input туда, или нет", "а может, разрешить туда только видеопоток", etc.

Кстати, fun fact - 50gb chrome source vs kernel 1gb source. Никогда не задумывались, насколько chrome огромен?

https://gitlab.freedesktop.org/mesa/mesa/-/issues/6249 - интересное обсуждение в Mesa отличие построенного пайплайна в RADV(4 буфера в swapchain vs. 2 буфера в #AMDVLK).

https://www.opennet.ru/opennews/art.shtml?num=57038 - SDL отменяет "wayland по умолчанию". Одна из причин - #libdecor не всегда корректно подхватывает плагины для отрисовки декораций. Про леденящий пиздец под названием libdecor я уже однажды рассказывал, поэтому, думаю, мое злорадство тут вполне понятно и уместно. У меня, конечно, в силу статической линковки все всегда работает как надо.

Про libdecor еще добавлю:

* Как бы нормальный разработчик сделал fallback в случае отсутствия необходимого плагина? Ну, понятно, был бы или плагин, который всегда устанавливается в систему, или плагин, который принудительно линкуется в основное приложение.

Чувак сделал и то, и то - ему, наверное, за строки кода деньги платят.

https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/libdecor-fallback.c - линкуется принудительно
https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/plugins/dummy/libdecor-dummy.c - ставится по умолчанию всегда

Но и это еще не все! В поставку входит еще 1 плагин, который тоже ставится всегда, и делает что-то полезное!

https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/plugins/cairo/libdecor-cairo.c

То есть, вместо того, чтобы просто по умолчанию всегда линковать эту реализацию с cairo, чувак 3 раза сделал одно и то же. Пиздец.

Ну и могу рассказать, как я элегантно из всего этого соорудил библиотеку с вкомпиленным внутрь плагином:

* В первый раз собираем libdecor, оставляем от нее только плагин, и в нем переименовываем и делаем global символ, который libdecor будет звать в виде fallback https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/decor/cairo/mix.sh#L16 , https://gitlab.gnome.org/jadahl/libdecor/-/blob/master/src/libdecor.c#L1657

* Во второй раз собираем libdecor, но обнуляем в ней символ libdecor_fallback_plugin_new, чтобы он взялся из плагина от первой сборки. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/decor/mix.sh#L9

Будни #bootstrap

Вот есть такой https://github.com/microsoft/DirectXShaderCompiler

Он мне, сам по себе, не нужен (хотя стараниями Valve теперь DirectX есть и под Linux), но он нужен для сборки #AMDVLK (мне все хочется пощупать альтернативную #mesa-е реализацию).

В целом, он собрался без особых проблем, за исключением получения version info из git при сборке. Вообще, получить свою версию из .git чекаута хотят многие проекты, и бОльшая часть из них косячат.

Вот, и этот проект смешно накосячил.

https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/version/gen_version.py - скрипт, пытающийся получить version.

Обратим внимание на https://github.com/microsoft/DirectXShaderCompiler/blob/main/utils/version/gen_version.py#L39-L42, тут сразу несколько ошибок:

* самая очевидная - нельзя так ловить все ошибки, потому что можно проглотить ошибку в ситуации, когда глотать ее нельзя (например, .git есть, но он как-то испорчен)

* чуть менее очевидная - этот скрипт ведет себя неожиданно, когда команды git нет в PATH. Потому что subprocess в этом случае кидает FileNotFoundError (поубивал бы за это, если честно), а не CalledProcessError.

* парсинг информации от git не обернут вот в такой fail safe try/catch. То есть, ошибку от git игнорируем, а невозможность распарсить кривой результат - не игнорируем.

Ну, то есть, коллеги не смогли правильно закодить то, что они на самом деле хотели - вернуть какое-то дефолтное значение, если получить реальную информацию не получилось.

Поэтому мне пришлось запилить специальный fakegit для этого проекта, который всегда выходит с ошибкой:

https://github.com/pg83/ix/blob/main/pkgs/bin/dxsc/ix.sh#L25

Потому что мой стандартный fakegit не сработал, по причинам, изложенным выше.

Мораль? Мораль, наверное, такая - код по обработки ошибок гикто не тестирует, потому что это сложно, и он способен сам давать наведенные ошибки, когда начинает срабатывать!

#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.

Собрать сам #AMDVLK было не очень сложно, но вот с одной из его запчастей пришлось попотеть.

Запчасть называется https://github.com/microsoft/DirectXShaderCompiler, зачем она нужна для amdvlk - непонятно, но отключить ее нельзя.

Собрать ее (в первый раз) было довольно просто, но вот она начала падать, во время запуска в процессе сборки amdvlk.

Причем, в лучших традициях, с загадочным сообщением типа "shit happen, error 100500".

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

Ладно, оттрассировал это дело через gdb, нашел место, где она возникала.

И тут у меня волосы начали шевелиться по всему телу, потому что такого я не ожидал, даже от Microsoft.

Коллеги вынесли всю функциональность компилятора в libcompiler.so, а все тулзы - тонкие обертки над этой библиотекой.

Вроде, пока звучит норм, так много кто делает, для экономии места, например, LLVM. Мне такой способ, очевидно, не нравится, я предпочитаю busybox-style бинари.

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

Для сборки этого в один статический бинарь пришлось соорудить очередного кадавра, но, в итоге, все заработало.

Давненько не рассказывал про #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 уделяется меньше внимания, а для части фич он вообще не пригоден.

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