Обновление бета-драйвера NVIDIA с переработанной поддержкой Vulkan

EXT_video_encode_h264

Интересно. Но тревожно за жирноту самого вулкана. Как бы не лопнул от всех этих расширений..

Эт свободный, или нет ешо?

Кто-нибудь пробовал в деле, если да, то каковы впечатления?

ПрямоИкс тоже каждый год новой хренью обрастает и ничего. Хотя казалось бы - низкий уровень обещали, всё это должны сами разрабы педалить

OpenGL же не лопнул.

Непохоже. По крайней мере по ссылке исходников не нашел.

https://github.com/KhronosGroup/Vulkan-Docs/pull/1816

https://printedsurface.ink/

Значит ещё не созрели.

Потроллили и не замёржили. Но будет приколько, если вулкан встанет в один ряд с иксами и заимеет себе принтсервер.

ну вот еще не хватало, чтобы mesa зависела от ffmpeg.

Кстати, насчет жирноты. Я тут недавно за не помню уж какими целями ядро пересобрал себе на ноуте. Было 5.10.0 (условно, не .0, но не слишком большое число). Стало 5.10.127. Поразил размер initramfs после пересборки. Полез разбираться - тадам! i915.ko - было 5Мб, стало 140.

Так и должно быть, интересно мне?

Чо туда Интел навалил…? Для разнообразия сравните размер amdgpu.ko, тоже толстая собака. Может со сжатием чего не так настроено было? На ПоверМаке почему-то kernel + initramfs в генте всегда за 200Мб вылезало.

$ ll /boot 
итого 170M
drwxr-xr-x 1 root root   0 фев 10  2022 efi
-rw------- 1 root root 94M авг 13 10:29 initramfs-linux-fallback.img
-rw------- 1 root root 67M авг 13 10:29 initramfs-linux.img
-rw-r--r-- 1 root root 11M авг  6 12:01 vmlinuz-linux

Но у меня рязянь.

OpenGL оброс костылями как раз из-за кучи расширений. Причём расширения вендорные, т.е. работают не на всех видеокартах. Это смерть.

$ ls -alh /boot/initrd.img-5.10.*
-rw-r--r-- 1 root root 44M апр 23 14:30 /boot/initrd.img-5.10.0-11-amd64
-rw-r--r-- 1 root root 44M апр 23 13:17 /boot/initrd.img-5.10.0-11-amd64.old-dkms
-rw-r--r-- 1 root root 27M фев 10  2022 /boot/initrd.img-5.10.0-9-amd64
-rw-r--r-- 1 root root 96M сен 13 16:43 /boot/initrd.img-5.10.127

Это со сжатием, понятное дело. А вот на сколько модуль тянет:

$ find /lib/modules -name i915.ko | xargs ls -alh
-rw-r--r-- 1 root root 5,2M янв 18  2022 /lib/modules/5.10.0-11-amd64/kernel/drivers/gpu/drm/i915/i915.ko
-rw-r--r-- 1 root root 5,2M сен 30  2021 /lib/modules/5.10.0-9-amd64/kernel/drivers/gpu/drm/i915/i915.ko
-rw-r--r-- 1 root root 140M сен 13 15:40 /lib/modules/5.10.127/kernel/drivers/gpu/drm/i915/i915.ko

Хз что они туда запихали. Подрос всего лишь в жалкие ~30 разочков.

Вроде дрова на карточки пилили в российском офисе интела. Наших уволили, набрали индусов вот и результат. Чем не версия.

Кому он, проприетарный-то, нужен?)

А 3Д Игори гонять?

На опенсорсных амудях)

Всё может быть. Еще не удивлюсь если там встроили трейлеры последних боливудских фильмов… в виде пасхалочки ))

было 5Мб, стало 140.

Скорее всего, собрал с отладочной информацией.

Ну так если нету амудей, а есть невидия🤷

Продать невидию виндузятникам, купить амуди для линукса)

Я над этим думаю.

Если хочется амуду без бэкдоров, бери RX590 - это последняя, которая без PSP (да-да, они эту хрень уже не только в процы но и в видеокарты стали ставить)

И эти люди треплются о свободе.

RX590 - это последняя, которая без PSP

…

и эту хрень уже не только в процы но и в видеокарты стали ставить

Можно пруфов на оба утверждения? Что имеется в виду и где почитать?

PSP

С SAMU не путаете?

Да уж, шаг к тотальному контролю. Как тут обвинять параноиков в газировании луж, тут сам параноиком станешь.

Честно говоря я сам не знал про эту штуку. Но тут упомянули, я по Гугл л и охренел.

• Что в Vega добавили «AMD Secure Processor» (aka PSP), вы можете почитать здесь.
• Polaris - последняя архитектура без PSP - в этом можно убедиться, например полазив по файлам драйверов на freedesktop: для Vega там есть какие-то файлы, относящиеся к PSP, а у Polaris в этом плане всё чисто (правда сейчас пруфов сравнения не будет, я и в прошлый раз долго ковырялся в исходниках для выяснения этого).
• А то, что именно RX590 - последняя без PSP: по крайней мере, RX590 это самый мощный Polaris, а Polaris - последняя архитектура без PSP (см. выше). Возможно, здесь я не совсем прав: вроде бы были Polaris'ы чуть новее - модели RX6** - но они худосочные по сравнению с RX590 (там неполный модельный ряд, вроде бы до RX640 максимум), и потому не интересуют.
• SAMU и тот Secure Processor (aka PSP) - это разные вещи: SAMU служит для DRM вроде бы, но - в отличие от PSP - наличие SAMU никак не ограничивает свободу пользователя устанавливать модифицированные прошивки AtomBIOS на свою видеокарту, и теоретически может быть возможен даже опенсорсный AtomBIOS (см. проект OpenAtom, который пытались осуществить для AMD'шной видеокарты стоящей в ноуте G505S с опенсорсным БИОСом coreboot, но немного не довели до конца). А с PSP такая свобода невозможна, не говоря о проблемах с безопасностью (которые неизбежно есть у любой проприетарщины, т.к. security-through-obscurity не работает и побуждает к некачественному коду) и прочих недостатках.

Да, поэтому разумистам, ценящим свободу и безопасность, только и остаётся что подбирать самое крутое свободолюбивое железо без всяких там бэкдоров вроде Intel ME и AMD PSP (про проприетарщиков NVidia даже говорить не хочется). Про видеокарты я уже высказался - наш выбор AMD RX590, желательно модель с повышенной частотой памяти вроде Sapphire Nitro+ 11289-07-20G . Матплаты следует выбирать с без-PSP'шным AMD (т.к. он мощнее чем без-ME'шный Intel) и поддерживающиеся опенсорсным БИОСом coreboot:

• ноут Lenovo G505S с четырёхъядерным A10-5750M и 16GB RAM ;
• десктоп ASUS A88XM-E с четырёхъядерным A10-6700/A10-6800K ;
• минидесктоп ASUS AM1I-A с Athlon 5370 (жаль он без IOMMU) ;
• сервер ASUS KGPE-D16 с двумя шестнадцатиядерными оптеронами и 192GB RAM .

Всё подробности по этому железу, их статусе свободы, сборке и прошивке опенсорсного БИОСа coreboot - можно найти поиском по моим сообщениям на этом форуме.

Лучший WiFi-модуль, работающий на 100% опенсорсе без закрытых бинарников - AR9462 из семейства Atheros ath9k, тут уж извините, но он хотя бы 5GHz поддерживает. А лучший WiFi-роутер для швабодки - Netgear WNDR3800 после установки прошивки LibreCMC (форк OpenWRT для роутеров, способных работать на 100% опенсорсе).

Всё это добро можно найти б/у в хорошем состоянии и проапгрейдить по максимуму. Как видите, путь к свободе немного тернист и требует некоторых жертв, но вполне осуществим.

А что, все другие, у кого закрытый биос, очень страдают в плане безопасности? (Про идеалы не говорим - отдельный вопрос.)

Спасибо, кажется стало понятнее. Просто с термином «PSP» в контексте дискретных GPU ранее не сталкивался.

SAMU и тот Secure Processor (aka PSP) - это разные вещи

Похоже, что нет.

Этот термин — «Secure Asset Management Unit» — пошёл из патента AMD на их реализацию закрытых анклавов. Оттуда же перекочевал к реверсерам PS4, в которой как раз и стоит защищённый APU от AMD. И именно в контексте APU я его и воспринимал изначально.

В контексте же дискретных GPU термин «AMD Secure Processor (ASP)» фигурирует только для Pro серии видеокарт. Для RX, врочем, с тех же самых Vega появляется упоминание «Trusted Memory Zone (TMZ)» — механизма, позволяющего шифровать и ограничивать доступ к страницам видеопамяти.

Здесь стоит задаться вопросом — одинаковы ли кристаллы Wxxxx и RX xxxx версий видеокарт. Если это так, напрашивается предположение, что TMZ реализуется через ASP.

А что касается SAMU — после ознакомления с патентом стало понятно, что это скорее первоначальное название общей концепции защищённых анклавов, охватывающее как CPU, так и GPU. Замечу, что открытая официальная информация от AMD по теме анклавов очень скудная. Буквально, приходится просеивать обрывки пресс-релизов и исходники открытых драйверов.

…служит для DRM вроде бы, но … никак не ограничивает свободу пользователя
устанавливать модифицированные прошивки AtomBIOS на свою видеокарту…
А с PSP такая свобода невозможна…

Этот вопрос для меня всё ещё остаётся открытым.

Поначалу ходили разговоры о возможности отключения PSP для CPU, а TMZ, даже уже будучи интегрированным в ядро требовал явного включения.

Однако, начало 2022 ознаменовалось скандалом с AMD PSB и появляется всё больше намеков на превращение AMD в такую же закрытую платформу для DRM, под эгидой Google и Microsoft.

EXT_video_decode_h264

Что наконец появилось кроссплатформенное API аппаратного декодинга видео?

Спасибо, буду Гуглить. Апгрейдить комп думаю в декабре, посмотрю что будет к тому времени.

SAMU и тот Secure Processor (aka PSP) - это разные вещи

Похоже, что нет

Позвольте с вами не согласиться)

1. Известно, что компонент SAMU был внедрён в составе модуля UVD3 - который появился задолго до Polaris: например, этот UVD3 с SAMU уже был внутри встроенной видеокарты AMD'шных процессоров архитектуры Trinity в ~2011 году, когда PSP и в процессорах ещё не стояло.
2. Если полазить по исходникам: хоть и в явном виде нигде не написано что «у Polaris нет PSP, а у Vega уже есть», это можно понять из файлов вроде этого: в функции psp_init_sriov_microcode на ~320 строке есть кейсы для «vega10» «navi12» «sienna_cichlid» «aldebaran», а для Polaris ничего не написано ;-)
3. Этот PSP иногда глючит, и по поиску в гугле "drm" "PSP" "failed" (drm здесь - Direct Rendering Manager, а не то что вы могли бы подумать) - вы найдёте массу сообщений вида

   [drm:psp_hw_start [amdgpu]] *ERROR* PSP create ring failed!
   [drm:psp_hw_init [amdgpu]] *ERROR* PSP firmware loading failed
   

   из логов ядра жалующихся пользователей. Но все эти баг-репорты - будут для более свежих видеокарт Vega/Navi/etc., и я уверен что вы не найдёте ни одного баг репорта с глюками PSP для видеокарт архитектуры Polaris. И не потому что раньше PSP был суперстабильный, а просто потому что PSP нет в видеокартах Polaris включая RX590.

И самое главное: в отличие от PSP, который по всей видимости появился в видеокартах начиная с Vega/Navi, этот SAMU никак не ограничивает свободу пользователя - например, не препятствует запуску изменённых AtomBIOS (нет никаких проверок подписей и т.д.) и даже запуску опенсорсного AtomBIOS'а - (к сожалению незавершённый) проект OpenAtom для встроенной видеокарты процессора A10-5750M архитектуры Richland (наследница Trinity, где в iGPU появился SAMU) , стоящего в ноуте G505S с опенсорсным БИОСом coreboot.

Получается, SAMU и PSP всё же разные вещи; возможно, этот SAMU в итоге перенесли в состав PSP либо переложили его функции на PSP - что и вызвало путаницу. В любом случае, наличие SAMU в видеопроцессоре ничем не угрожает свободе и безопасности пользователя, и видеокарты вплоть до Polaris включительно - вроде RX590 - вполне подходят для спокойного использования.

Проверил. Не, дебаг не включен.

Как именно проверял?

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

Исключительно поглядыванием в .config - там всё что за дебаг отвечает не выставленно. Ну и в меню menuconfig глянул (на случай, если дебаг делается при значениях по умолчанию) - тоже всё по нулям.

Черт, а ведь ты прав…
Надо было просто file i915.ko сказать, он сразу и показал что with debug_info. Теперь буду поискать, где это отрубается, помимо конфига ядра.

Если собираешь ядра для Debian или основанных на нём, используй make bindeb-pkg. Эта цель собирает отдельно пакет со стрипнутыми бинарниками, отдельно пакет с заголовками и отдельно пакет с отладочной информацией.

Ё-маё…
Лет 10 сижу на Дебиане, но до сих пор удивляет их упоротость, возникающая местами. Вот, собирал обычно ядра естественным способом, а оказывается они и для удаления этих гланд нашли свой ректальный инструмент :D

Не, я ща глянул в конфиг ядра и решил пересобрать с DEBUG_INFO=n. Погляжу что получится, но потом может и «рекомендованным» способом воспользуюсь.

У тебя классический случай синдрома «мой юзкейс — единственно правильный».

Во-первых, deb-pkg, bindeb-pkg и прочие похожие — цели в ванильном Kbuild. Они уже есть в сборочных скриптах ядра, для этого не нужно накладывать какие-либо скрипты от Debian. Происхождение дистрибутива я упомянул исключительно из утилитарных причин. В Arch или RHEL будет неудобно устанавливать deb-пакеты, которые генерируются целью deb-pkg.

Во-вторых, собирать изначально с отладочными символами, а потом отрезать их — самый простой и «прямой» способ получить отладочные символы для отладки сбоев пост-фактум. Вот глюканёт что-то в ядре, выплюнет оно распечатку стека. Чтобы приблизительно определить место в коде, нужна отладочная информация. И что делать, если её не было? Придётся собирать ядро уже с ней и ждать, что глюк снова воспроизведётся. Сработает, если ошибка воспроизводится легко, но только вот большинство ошибок стреляют редко.

Так что нет, не соглашусь с тобой. Вариант со отделением отладочной информации в отдельный пакет и есть самый адекватный.

У тебя классический случай синдрома «мой юзкейс — единственно правильный».

Так и есть. Когда много лет пользуешься определенными методами и они, в целом, сбоев не дают, то привыкаешь к тому что они «единственно православные». Что касается целей в Kbuild, то конечно я их видел, временами уточняя нужное мне из вывода справки, но… мало ли вокруг нас инфы, которая чаще всего излишняя в конкретный момент?

Так, я сначала пересобрал всё привычным способом, всё собралось как надо. Но для порядка пересобрал «как надо». При случае ребутнусь, но на вид всё выглядит неплохо

пересобрал «как надо»

Видимо, я неправильно выразился. Подход с отделением отладочной информации не является единственно правильным. Но он и не является удалением гланд через сомнительные отверстия, потому что он адекватен решаемой задаче. Просто задача другая.

Я все верно понял. Естественно, правильных путем может быть больше одного. Под «как надо» в данном случае подразумевается тот путь, который в документации на дистр прописан, как базовый.