The OpenNET Project / Index page

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



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

Оглавление

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

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


226. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от Аноним (-), 24-Фев-24, 23:09 
> Имеется ввиду контроллер матрицы LCD в мониторе, а передача сырых данных по
> видеокабелю в цифровом виде, или видеоадаптер в его оконечной части?

Блок GPU в общем случае. Современные железки умеют держать под framebuffer более 1 слоя (hardware surface), слеплять их между собой при выводе, конвертируя формат пикселей, если надо, внутрях, и вот это уже - в провод.

Это не амд придумало, на мобильных девайсах такое уже сто лет. Ведроид в surface flinger этим сто лет пользоваться умеет. Технически при этом UI рисуется в HW surface в RGB формате, а результат видеодекодирования валится в HW surface с форматом YUV.

А амд тоже так захотелось, в том числе и на нормальном лине. Почему нет, собссно?! Или лагучая энергожоркая графика через ж@#у - наше все?!

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

256. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от pic (?), 25-Фев-24, 14:26 
>[оверквотинг удален]
> 1 слоя (hardware surface), слеплять их между собой при выводе, конвертируя
> формат пикселей, если надо, внутрях, и вот это уже - в
> провод.
> Это не амд придумало, на мобильных девайсах такое уже сто лет. Ведроид
> в surface flinger этим сто лет пользоваться умеет. Технически при этом
> UI рисуется в HW surface в RGB формате, а результат видеодекодирования
> валится в HW surface с форматом YUV.
> А амд тоже так захотелось, в том числе и на нормальном лине.
> Почему нет, собссно?! Или лагучая энергожоркая графика через ж@#у - наше
> все?!

Т.е. с тех пор ничего не поменялось, RGB у камер не прёт, идёт как у старых ПЗС, яркостной и два цветоразностных сигнала для сужения широкой частотной полосы. И уже потом на оконечном каскаде как у кинескопа на плате электронной пушки, уже 3 управляющих расшифрованных по 3-м основным сигналам цвета. Проблема в дешевых видеоматрицах камер?


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

283. "Инженер из AMD признал, что графический стек Linux нуждается..."  +/
Сообщение от Аноним (-), 26-Фев-24, 05:13 
> Т.е. с тех пор ничего не поменялось, RGB у камер не прёт,

При чем тут камеры? Там про декодирование видео - а оно чаще всего в YUV представлении. В основном потому что R, G и B каналы обладают ломовой избыточностью (общая структура у всех трех одинакова). Поскольку видеофайлы здоровые by design, этот вариант представления, позволяющий заметно убавить ворочаемые данные там в почете. И на выходе декодера большая часть видиков даст - ну вот это.

Стыковка этого с другой RGB картинкой софтварными методами ессно потребует конверсию формата и прочие прелести. Нифига не быстрые и дешевые по энергии. А тут у железа просто разные "planes" (surfaces, framebuffers) есть. Более сложная структура фреймбуфера, несколько слоев. Железки при отправке в провод - умеют делать нечто типа простого хардварного композитинга, слепив эти surface'ы и в этом процессе конвертировав формат пикселей в тот какой надо вон тому монитору. Там все равно были возможны разные варианты и уметь конвертить требовалось и без вон того. Скажем в HDMI поток на монитор может быть как RGB так и YUV, и видяха ессно умеет конвертить на случай если формат фуфера VS монитор не совпадает.

> идёт как у старых ПЗС, яркостной и два цветоразностных сигнала для
> сужения широкой частотной полосы.

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

> 3-м основным сигналам цвета. Проблема в дешевых видеоматрицах камер?

Там вообще другой формат данных нынче нативно - байер. Где в одной линии есть красный и зеленый, а в следующей зеленый и синий. И это как бы сказать "не совсем RGB". У него зеленого в 2 раза больше чем синего и красного. Но именно его вывешивают не особо часто, это в основном для фот практикуется, так называемых RAW. В силу экзотичности формата с ним умеет работать лишь некоторый специализированый софт. Для видео это как-то не прижилось. И там даже нежатый сигнал уже после дебайера и конверсии - в YUV или реже RGB. Но этот поток чаще всего видит только некий хардварный энкодер, особенно в мобильных девайсах, с крутой камерой. Ибо вы опупеете с такого потока и его кодирования в реалтайме энным кодеком.

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

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

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




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

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