Компания AMD опубликовала выпуск набора драйверов AMD Radeon 25.10.1 для Linux (Radeon Software for Linux), работающего поверх модуля AMDGPU, развиваемого в основном составе ядра Linux. Выпуск примечателен реализацией официальной поддержки открытых драйверов RADV и RadeonSI для графических API Vulkan и OpenGL, поставляемых проектом Mesa. Ранее предлагаемые пропритетарные драйверы для Vulkan и OpenGL исключены из набора...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63329
и как производительность пострадала?
Чего ей страдать, она же меньше была, не? Закрытые драйвера вообще существовали из-за странной позиции разрабов Mesa, которые принципиально не хотели в compat профиле макс версию показывать и требовали явного задействования core профиля. Это полностью соответствует бумажному стандарту, но противоречит практическому положению дел с большинством драйверов (других) и софта (все плевали на стандарт и делали как удобнее). В итоге некоторый проф софт просто не запускался (т.к. не запрашивал профиль как положено), хоть и должен был работать. Это не устраивало всякий крупняк и дрова делали для него. Недавно (относительно) позиция Mesa резко смягчилась и второй драйвер стал не нужен.
> (относительно) позиция Mesa резко смягчилась и второй драйвер стал не нужен.И пруф этого всего вы конечно покажете? КМК скорее там дело в том что OpenGL стремительно утрачивает свою актуальность как API, являясь в основном затычкой для легаси софта.
А Vulkan - в MESA вообще RADV так по жизни бессовестно делал AMDVLK :). И вот тут лолично что амд не поняло зачем самим столько програмить свою полупроприетарь, когда за них написали более крутой и 100% открытый драйвер.
Мне главное, чтобы был PIC код всех этих OpenGL, Vulkan, VAAPI, mesa, ... который даёт возможность собрать PIE бинарь для работы в ASLR ядрах OS.
> Мне главное, чтобы был PIC код всех этих OpenGL, Vulkan, VAAPI, mesa, ... который
> даёт возможность собрать PIE бинарь для работы в ASLR ядрах OS.Они обычно как .so собираются вообще.
это ведь не невидия, где с каждым апдейтом минус пол гига памяти
> это ведь не невидия, где с каждым апдейтом минус пол гига памятиИ еще пачку глюков, где на замен 1 починеного - 2 новых приходит. А вы можете выбирать из проржавевшей новы, недоделаного нуво, глюкавой и проблемной проприетари. Офигенный производитель, видите?!
AMDVLK капут,я правильно понял? Он же вроде открытый был.
Да, был открытый, radv лучше.
Единственно в чём amdvlk был быстрее, это в рейтрейсинге на поддерживаемых видеокартах. Теперь ждём вклад amd в radv на этот счёт.
Из состава также исключён фреймворк AMF (Advanced Media Framework), предлагающий аппаратно ускоренные кодировщики и декодировщики видео. Вместо AMF для ускорения кодирования и декодирования видео предложено использовать программный интерфейс VA-API (Video Acceleration API) в связке с Mesa.
мои аплодисменты. вместо апаратного на программный 👌
где лайк поставить? (сарказм)
Лайк поставь своей учительнице, которая не научила тебя читать.
Программный _интерфейс_, а не кодировщик.
А VA-API это video accelerated api, что как бы намекает.
Кеды на аватарке, при этом не знает, что такое vaapi. Кекспертность на опеннете во плоти.
AMF и VA-API это, грубо говоря, программные обвязки, дёргающие аппаратные возможности. Т.е. одну реализацию (специфическую) заменили на другую (стандартную для Linux).Но, в принципе, я бы не стал аппаратное кодирование использовать вообще. Качество при этом получается хуже, чем у NVIDIA (NVENC), а при сравнении с программным кодировщиком так вообще разница небо и земля.
NVENC это тоже аппаратное кодирование и оно такое же корявое
А, ну конечно проще купить отдельный компуктер, чтобы показать как Вася играет в игры или нагружать проц по полной, но тогда непонятно будет какое же потребление в играх. Вот ведь злые кодировальщики - декодирования то нет совсем. Это в 4К вместо 16 ватт процессор должен был бы потреблять 160? Отличное решение для стримов - и дома тепло. А то сижу тут парюсь с 16 ваттами на видеокарте в пассивном режиме для 86 кадров в 1080 и страдаю. Надо же как все быть! А все должны страдать, потому что иначе Вася обидится и будет чувствовать себя не комфортно. А нам ведь всем очень важно мнение Васи. Как мы без него раньше жили неясно.
VAAPI даёт аппаратное кодирование/декодирование видео на GPU в Linux без нагрузки CPU!В Apple и M$ вывод картинки на дисплей происходит напрямую с декодировщика, без загрузки CPU.
В Linux декорированное изображение передается в masa для сжатия, растяжения, прочей обработки и mesa отрисовывает видео в нужном окошке на дисплее. Да, при этом нагружается CPU.
В Linux с X11 начиная с KDE-3 можно на двух десктопах, запустить два фильма, повернуть рабочие столы в 3D, чтобы грань куба была посредине экрана и смотреть два фильма одновременно.
https://mpv.io/manual/stable/#video-output-drivers-dmabuf-wa...
А да, прибавляется по-моему около 200 милливольт на встройке интеловской при декодировании и чуть больше в 4К. Это конечно офигеть как важно иметь разницу когда 12900К потребляет 3,5 ватта. Можно напрягшись его как-то заставить потреблять менее 2 ватт в режиме десктопа, но это нужно вручную делать. Как там потребление всей системы в Шындошс и Макакос? Я уже видел выхлопы про то какой ужас - линукс копирует данные в память перед отправкой. Вот ведь хитроподлая встройка! Ну я получается страдаю просто по-дикому. Как же хорошо все сделано в ШМОС! Так, так это они у меня украли кнопку "завидовать!". Я разочарован. Пойду страдать в линуксе дальше. Жизнь боль, да.
да на миливольты пофиг, а вот задержки от копирования уже важны.
Ну так нвидия уже пыталась доказать нужность встройки, старательно напирая на то что при таком типе подключения инпут лаг сильно снижается. Даже АМД с даже интелом парились с драйверами, чтобы встройка еще и работала в паре с их видеокартами, но теперь интел вроде бы последние кто бросил этим заниматься. Потому что люди старательно лагают и не хотят ничего менять, даже в лучшую сторону. Ситуация аналогичная тому как люди хотят гитары как в 60-х делали с отлетающими бошками у грифов, потому что гриф из той породы красного дерева не выдерживал тычков. Так что тут сплошная биполярка и даже производители забили пытаться просвящать хотя бы элиту айтишную, хотя эти то парни должны знать как компьютер работает, особенно про видеокарты такое грех не знать и не использовать себе во благо.
Потрясающе, когда-нибудь меза станет настолько крутой, что заменит блобы на телефонах. Уже частично заменяет, в эмуляторах используют turnip.
Телефоны на процессорах Qualcomm надо брать и использовать mesa с freedreno.
Уже есть, но драйвера модема нет.
Причем тут драйвер модема? Adreno использует линуксовый DRI интерфейс, благодаря чему можно без рута пользоваться месовскими дровами на телефоне.
Нет, просто в mesa научились использовать kgsl и использовать turnip с проприетарным драйвером. Но это только вулкан
Читал, что есть проблемы с фридрено на андроиде. На андроид 16, когда перейдут на вулкан, возможно turnip покажет себя.
Пришёл ИИ. Хард скиллы теперь нужны гораздо меньше. Нужны софт скилы.Ну и код открывать - а это логично.
Софт скиллы при устройстве на работу были нужны всегда.Лично я считаю, что это глупости все, не нужны программистам все эти ваши социальные взаимодействия, наше дело код писать, а не бесконечные созвоны устраивать.
Этот феномен скорей чисто в социальной плоскости.
По мере усложнения любой кодовой базы, весь менеджмент все меньше понимает что происходит и обрастает попытками контроля ситуации (или иллюзиями этого контроля)
Как будто код не писался в векторе обозначенным менеджментом. Вы сервисмены много о себе вообразили,над вами дяди сидят болтая ногами.
Главный софт-скилл при устройстве на работу - быть прогибастом.
Разработка софта — это в первую очередь социальная дисциплина, и только потом уже техническая. Код пишется чтобы другому человеку передать идеи, а не сделать компьютеру удобненько. Асоциальные только хэллоу ворлды хорошо писать умеют. Для всего остального приходится с другими людьми общаться, а уж в коммерческой разработке так и вовсе необходимо.
>наше дело код писать, а не бесконечные созвоны устраивать.Типичные пузыри джуна =) бОльшая часть любой работы - это социальные взаимодействия. Ну если ты не дворник, конечно. Это один из результатов промышленной революции, читайте историю того дела, которым занимаетесь! А уж для программиста это жизненно важно, ибо специализации узкие, заказчиков много, надо четко координировать действия.
это как недавний скандал в интоле, когда оказалось, что одним из ключевых показателей эффективности, влияющим на зп и премии руководства, была численность штата отдела. Чем больше - тем лучше
И вот там - да. Мусор вроде всяких софт-скиллов
Это ведь означает, что АМД подключится к разработке RADV? А то пока какая-то дикость получалась, что самый популярный игровой драйвер для видеокарт разрабатывался не производителем этих карт, а никак не связанной с ней другой компанией.
Почему никак не связанной, этот radv потом на стимдеках использовался.
> Почему никак не связанной, этот radv потом на стимдеках использовался.Я про разработку драйвера. То, что этот драйвер используется для красного железа, это само собой разумеющееся.
Как они продали бы стимдеки без протона и хорошего драйвера, разумеется, им больше всех нужно было это всё.
Дрова всё также намертво приколочены к ядру и линукс-специфичным API?
А как вы себе представляете драйвер, который в ядре и который не использует ядерное API?
Т.е. слегка прошлые и будущие версии ядра в пролёте, не говоря уже о BSD/Solaris?
На RHEL используется бекпорт из ядра 6.10
Непонятная непонятность. То ли дело у зеленых подход. Есть прекрасный проприетарный блоб который тащит и есть все остальное. Просто и понятно.
> официальной поддержки открытых драйверов RADV и RadeonSI для графических API Vulkan и OpenGL
> для аппаратного ускорения кодирования и декодирования видео предложено использовать программный интерфейс VA-API (Video Acceleration API) в связке с MesaОтлично! Вопрос с графическими драйверами и кодированием/декодированием видео на видеокартах AMD решен.
Как дела с вычислениями на GPU от AMD? Собираются ли они поддерживать OpenCL? Как насчёт поддержки OpenCL в mesa, clover, (rusticl), RadeonSI?
https://wiki.archlinux.org/title/GPGPU
Объединились бы уже AMD с Intel и дописали clover(rusticl) для нормальной поддержки OpenCL в mesa.В mesa с OpenCL все печально: https://mesamatrix.net/
clover уже исключили в 25.2 в пользу rusticl
Видел, что clover на C выкинули с mesa. Это было бы целесообразно если бы rusticl поддерживал в mesa хотя бы OpenCL-1.0. А а так rust только добавит проблем и сложностей. Теперь надо OpenCL на двух языках писать.
Если они выкинули оттуда свою реализацию opengl (вроде этотбыло ещё лет 5 назад) и amdvlk, то что осталось там?
из их реализации opengl что-то перешло в radeon и radeonsi, а некоторые не защищенные лицензиями и патентами оптимизации из amdvlk перешли в radv
Я не держатель АМД и нифига не понял. То есть, для поддержки аппаратного декодирования нужен проприетарный драйвер? Или что?
Оооо, амд. Значит спросить можно. Как думаете rocm рабочий варик на арче? С rx6600 ахаххаха