The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



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

Оглавление

Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании, opennews (??), 23-Фев-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


80. "Инженер из AMD признал, что графический стек Linux нуждается..."  +5 +/
Сообщение от n80 (?), 24-Фев-24, 03:53 
Что-то тут недоговаривают. Всю дорогу был Xv (X-Video Extension), который таки позволяет выводить YUV оверлеи в иксах без лишних преобразований, весь вопрос в том чтобы драйвер правильно заявлял таковую поддержку. Более того, там не только вывод, но и пост-обработка может быть заявлена и использоваться приложениями, см. вывод xvinfo. Т.е. проблема, скорее, не в иксах, а в дровах AMD.
Ответить | Правка | Наверх | Cообщить модератору

83. "Инженер из AMD признал, что графический стек Linux нуждается..."  +6 +/
Сообщение от name (??), 24-Фев-24, 04:00 
Оно умерло очень давно. Теперь по xvideo гуглится совсем другое.
Ответить | Правка | Наверх | Cообщить модератору

87. "Инженер из AMD признал, что графический стек Linux нуждается..."  +1 +/
Сообщение от n80 (?), 24-Фев-24, 04:10 
> Оно умерло очень давно. Теперь по xvideo гуглится совсем другое.

Судя по выводу xvinfo на машине с intel (и тому что видео у меня таки играется без особого напряга для процессора), не совсем умерло. Другое дело, что у меня direct rendering без композитора, а выше заметили что нужна в композиторе поддержка. В такой постановке уже могу поверить в наличие проблемы, но уверен что тоже какое-то решение давно есть.

Ответить | Правка | Наверх | Cообщить модератору

90. "Инженер из AMD признал, что графический стек Linux нуждается..."  +3 +/
Сообщение от name (??), 24-Фев-24, 04:15 
Ты уверен, что используешь xv, а не vaapi? Насколько древняя машинка?
Ответить | Правка | Наверх | Cообщить модератору

93. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от n80 (?), 24-Фев-24, 04:43 
> Ты уверен, что используешь xv, а не vaapi? Насколько древняя машинка?

Очень хороший вопрос, до этого был уверен, но сейчас включил отладочный вывод mpv и таки через VA-API основная работа идёт (ну т.е. по умолчанию используется vo=gpu, который уже под капотом дёргает vaapi и ещё кое-что, чтобы работали скриншоты и без мыла отрисовывался интерфейс/субтитры). А Xv хоть и работает, но только если его явно попросить и загрузка процессора в этом случае всё же чуть выше, не говоря уж про возможные проблемы с отрисовкой OSD/субтитров. Так что да, Xv действительно остался во временах вторых/третьих пней, хотя поддержка ещё есть, в принципе.

Но это я с названием ошибся (ОК, VA-API, а не Xv), а принципиальный-то момент остаётся: есть какой-никакой API для вывода YUV-оверлеев без лишних телодвижений и он даже отлично работает. Чего не хватает AMD, чтобы у них хотя бы так работало — хотелось бы понять.

Ответить | Правка | Наверх | Cообщить модератору

96. "Инженер из AMD признал, что графический стек Linux нуждается..."  +1 +/
Сообщение от name (??), 24-Фев-24, 05:00 
У тебя вывод идёт через рендер на vulkan или opengl, а они прямой хотят сделать, это разгрузит cpu и gpu. На wayland есть dmabuf, mpv его уже поддерживает, но показывает красную картинку, как раз из-за YUV.
Ответить | Правка | Наверх | Cообщить модератору

101. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от n80 (?), 24-Фев-24, 05:40 
> У тебя вывод идёт через рендер на vulkan или opengl, а они прямой хотят сделать, это разгрузит cpu и gpu.

По умолчанию через opengl, а минимальная загрузка CPU, вроде, при выводе через vaapi, хотя сложно сравнить, она даже через xv небольшая на фоне собственно декодирования сжатого видео.

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

Ответить | Правка | Наверх | Cообщить модератору

98. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от name (??), 24-Фев-24, 05:14 
vo=gpu работает, если ты не понял.
Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

99. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от n80 (?), 24-Фев-24, 05:35 
> vo=gpu работает, если ты не понял.

Я понимаю что vo=gpu работает по умолчанию, но это же обёртка поверх разных реальных API, соотв-но вопрос в том, что там на самом деле используется. Судя по тому что в логе идёт раньше, там вообще OpenGL ([vo/gpu/opengl] Choosing visual EGL config 0xa, visual ID 0x21), но есть в этом что-то странное. Если Xv и VA-API мне более-менее понятны, то вывод YUV через текстуру GL звучит диковато, хотя и понимаю что так тоже возможно.

Ответить | Правка | Наверх | Cообщить модератору

103. "Инженер из AMD признал, что графический стек Linux нуждается..."  +2 +/
Сообщение от name (??), 24-Фев-24, 05:45 
Декодирует vaapi, рендерит gl, всё понятно. В gpu-next рендерит вулкан, вроде как, проверь. Это позволяет использовать различные фильтры, шейдеры.
Ответить | Правка | Наверх | Cообщить модератору

204. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от n80 (?), 24-Фев-24, 21:14 
gpu-next через libplacebo рендерит: судя по логу, всё равно через opengl, но с добавкой GLSL. Вулкан в логе не упоминался, да и хорошо это: судя по выводу vulkaninfo, у меня на основной машине он только через llvmpipe работает, думаю, из-за старого ядра.
Ответить | Правка | Наверх | Cообщить модератору

289. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от mos87 (ok), 26-Фев-24, 07:21 
для gpu-next можно выбрать вывод vulkan

>Вулкан в логе не упоминался, да и хорошо это: судя по выводу vulkaninfo, у меня на основной машине он только через llvmpipe работает, думаю, из-за старого ядра.

кринж

Ответить | Правка | Наверх | Cообщить модератору

86. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от name (??), 24-Фев-24, 04:09 
Постобработка невозможна без копирования, кстати, а они хотят zero copy.
Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

89. "Инженер из AMD признал, что графический стек Linux нуждается..."  –1 +/
Сообщение от n80 (?), 24-Фев-24, 04:15 
> Постобработка невозможна без копирования, кстати, а они хотят zero copy.

Смотря какая. Подкрутить яркость/контраст/насыщенность по запросу приложения-клиента GPU и сам может на лету. Что-то более сложное шейдерами делается, т.е. тоже нет смысла обратно с GPU в основную память через CPU гнать. Что-то совсем замороченное же в любом случае не будет zero copy, но это нормально же.

Ответить | Правка | Наверх | Cообщить модератору

135. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от Tron is Whistling (?), 24-Фев-24, 09:36 
Какая именно постобработка? Постобработка даже при copyback часто ведётся не в RGB.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

136. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от Tron is Whistling (?), 24-Фев-24, 09:38 
Плюс современные GPU могут часть постобработки (цвета, скейлинг, деинтерлейс) сделать на GPU + можно шейдер накрутить. В принципе да, зачем это назад гонять через RGB - совершенно непонятно.
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

137. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от Tron is Whistling (?), 24-Фев-24, 09:39 
Даже слияние с субтитрами в D3D11 уже делается на GPU...
Ответить | Правка | К родителю #86 | Наверх | Cообщить модератору

221. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от Аноним (-), 24-Фев-24, 22:52 
> Что-то тут недоговаривают. Всю дорогу был Xv (X-Video Extension), который таки позволяет
> выводить YUV оверлеи в иксах без лишних преобразований, весь вопрос в
> том чтобы драйвер правильно заявлял таковую поддержку.

Что Xv что Xvideo - страшенные костыли, с зиллионами родовых травм. Это настолько кривые и проблемные субстанции что на них в общем то почти все плееры забили. Если выбор встает так, проще сплевывать кадры как текстуры GL или Vulkan оказывается, ибо так это и то многократно лучше работает.

> см. вывод xvinfo. Т.е. проблема, скорее, не в иксах, а в дровах AMD.

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

И если горе эксперты еще не заметили: КАК В ТО ГАМНО ВООБШЕ ИНТЕРФЕЙСИТЬ ХАРДВАРНЫЙ ДЕКОДЕР В ТЕХ КОНЦЕПЦИЯХ?! Там это не предусмотрено. И вон тот shortcut не получится. Вот хоть как.

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

255. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от n80 (?), 25-Фев-24, 13:48 
Один момент: Xv и XVideo — одно и то же. А вторая вымирающая альтернатива называется VA-API и в рамках её концепции таки удобно использовать аппаратный декодер, для того Intel это и сделал изначально. Другое дело, что это сложно использовать для чего-либо кроме просмотра видосов, т.е. не самый универсальный API. Но работает же. Но сделают лучше — я только за.
Ответить | Правка | Наверх | Cообщить модератору

282. "Инженер из AMD признал, что графический стек Linux нуждается..."  +1 +/
Сообщение от Аноним (-), 26-Фев-24, 04:57 
> Один момент: Xv и XVideo — одно и то же.

Да и х с ним. На практике это работает - как кусок тормозного глючного гуано. Так что выводить через GL или Vulkan в обход иксов меньше оверхеда, глюков и тормозов. В тех случаях иксы тоже контент экрана могут и не видеть, это же не через них.

...но вон тот фокус, когда выхлоп декодера в yuv-surface железки спихивается без особого участия софта в процессе не получится ни так ни сяк. Для этого надо сетапнуть железо специфичным образом и - проинформировать софт в системе что такой сетап имеет место быть. Софт должен понимать, что рендер на экран - не то что он там себе думал, а вот такое вот теперь.

> А вторая вымирающая альтернатива называется VA-API и в рамках её концепции таки удобно
> использовать аппаратный декодер, для того Intel это и сделал изначально.

Оно вроде никуда не вымирает, в отличие от той отшибленой байды из девяностых. Плееры поддерживают, равно как и драйверы. Там же и VDPAU если мы об этом. А вон то по моему уже половина плееров дропнуло, или где-то на грани.

> Другое дело, что это сложно использовать для чего-либо кроме просмотра видосов,

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

> т.е. не самый универсальный API. Но работает же. Но сделают лучше —
> я только за.

Ну вон там господа хотят "short circuit" уметь делать, с вон такой структурой пайплайна. Как это вяленду представить я догадываюсь, а как иксам - ну, если кто в курсе, пусть и покажет. Иначе будет вяленд-онли фичой.

Ответить | Правка | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру