Инженер из AMD признал, что графический стек Linux нуждается в совершенствовании

Не должно вообще выходить за пределы видюхи. Гонишь на неё поток со словами «вот по этим координатам отрисуй, параметры вот такие».

А потом «почему я с браузера на другое окно переключился, а у меня видео поверх нового окна продолжает играться» или «а почему я окошко плеера таскаю, а у меня видео то с запозданием, то с опережением рамки окна бегает».

Дураков на лорчике на 100 лет вперёд напасено.

Я тоже в этой переписке почитал. Не правильно поняли Алекса. Беда не в графическом стеке а в железе АМД в сравнении с интелом. У АМД есть декодер - но декодированное видео надо масштабировать и вывести на экран. Ну это какбы понятно.

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

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

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

У АМД декодер есть - а дальше все отрабатывается через шейдеры радеона

Я выше кидал картинку - уже 9 лет как, начиная с Carrizo, оно работает так же.

https://www.notebookcheck.com/fileadmin/_processed_/csm_carrizo_uvd_low_power...

у интела есть отдельный хардверный движок который как раз и делает вот это масштабирование и корпирование энергоэффективно

Сильно сомневаюсь, что он используется, что в Linux, что в Windows. По крайней мере, в Firefox. Но при этом ТС заявлял, что в Firefox на Linux на Intel у него всё хорошо.

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

Это тоже очень спорное утверждение. В Windows декодированные кадры из DXVA2 перекидываются в текстуры (через DXGI вроде), а текстуры уже потом рисуются через 3d-движок через DirectX. Так что там в целом то же самое.

Сильно сомневаюсь, что он используется, что в Linux, что в Windows

Судя по энергопотреблению используется. Сам измерял - Tigerlake интеловский декодирует в firefox ватт за 8-10 f 7840U за 12-15.

Скорее всего использование этого движка зашито в те самые бинарные модули intel-media-driver который опенсорсен лишь частично. AMD обещает поддержку своего аналога в ядре и MESA - и скорее всего это будет выражаться в том что декодер станет выдавать желаемое видео в том разрешении в котором это требуется - ну под размер прямоугольника с видосом в firefox или в буфер полного экрана независимо от разерешения исходника. Но как и все бинарные вещи - мы можем только догадываться исходя из здравого смысла и инженерной эрудиции.

Это тоже очень спорное утверждение. В Windows декодированные кадры

Ну по факту венда декодирует менее затратно. Как они это сделали - можно только гадать. Так что в целом тоже самое - но как говорил Вовочка в анекдоте есть нюанс.

Судя по энергопотреблению используется.

У Intel’а заявлено, что использование SFC по назначению позволяет снизить энергопотребление до значений меньше одного Ватта. В указанные тобой 8-10 Ватт легко укладывается масштабирование на 3d-движке. Это с учётом того, что 8-10 Ватт это вообще на всю систему, а не только на CPU+GPU.

станет выдавать желаемое видео в том разрешении в котором это требуется - ну под размер прямоугольника с видосом в firefox или в буфер полного экрана независимо от разерешения исходника

После чего Firefox его загонит в текстуру, как это обычно делает, и отмасштабирует 3d-движком.

В указанные тобой 8-10 Ватт легко укладывается масштабирование на 3d-движке.

Ну у АМД то это же почему-то укладывается в 15. При том что интел 11gen 10нм техмпроцесс, а у AMD 7840U 4нм. На самом деле оно вполне укладывается в то что интел обещает - AMD если верит замерам в багрепорте от серьезных дядек берет овехед на декодирование 3-5 ватт. В firefox помимо декодирования улетает куча энергии на всякое говно поэтому там мерили просто - вот firefox играет ютуб, а вот ютуб на паузе.

После чего Firefox его загонит в текстуру, как это обычно делает, и отмасштабирует 3d-движком.

Вроде как они уже сделали zero-copy когда декодер рисует непосредственно в кусок буфера.

И тут начинается адский ужор.

Только потому что дебильные драйвера выводят карточку на PL2 если не PL1

Причём это дебилизм, потому что 3Д ускорение задействовано всегда на современных композиторах. Карточка не спит.

Но какой-то кривой костыль сейчас при включении декодирования видео повышает PL карте когда это не надо вообще.

Вопрос, зачем это делается... Раньше все буферы были в видеокарте.

ХЗ, может из-за зоопарка архитектур видеокарт, а может из-за того что для процессора код писать сильно проще и дешевле.