Свершилось

Похоже что ты меня не тролишь))

а как же они тесты на калибраторе проводят и видят этот расширеный диапазон?

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

Иными словами, одна матрица может выдавать больший диапазон цветов и яркости, чем другая. (Всегда ваш - К.О.)

из твоего рассказа следует что ниделай лучше не будет.

Из моего рассказа следует, что HDR трасформирует трёхканальный 8-битный цвет в четырёхканальный, где четвёртым каналом является яркость. И, собственно, ‘D’ в этом ‘HDR’ - это смена яркости в зависимости от наполнения кадра.

Алсо,

И решает эта технология именно проблему ограничения 8-бит на канал.

Строго говоря, так получилось, что с появлением LCD-матриц каждая (за вычетом OLED-дисплеев) имеет программно управляемую яркость. HDR использует эту возможность программно. Как обычно, в реальном мире побеждает обратно совместимое и самое дешёвое в изготовлении инженерное решение, вместо теоретически правильного с расширением битности цвета (или изменением каналов).

а без 4к мелкие детали на шрифтах невидно чтоли?

Нет, не видно. Засечка … в сабпикселе может стать мылом.

к окулисту сходи

Похоже что ты меня не тролишь))

Он прав. Если ты не видишь мыла на своём экране, хотя оно там есть - тебе надо к окулисту.

Не, мы говорим про Диапазон яркостей каналов выше 8бит.

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

Кто сказал? Во-первых, причём тут CMYK, это субтрактивная модель, они неприменима в мониторах. Во-вторых, HDMI поддерживает 10,12 и 16 бит на канал с 2006 года, почему ты решил, что в мониторах они не поддерживается? Да, там запросто могут быть FRC, ну и что.

Если монитор не поддерживает HDR, то включение HDR не приводит ни к какому эффекту.

Если монитор не поддерживает HDR, то и включить нельзя ;-) А вот если монитор поддерживает HDR, но при этом ОС не поддерживает HDR или HDR выключен, то монитору приходится самому мапить SDR в HDR. Сделано это для совместимости со старым оборудованием. Именно в таком режиме работал Linux до сих пор. Если же HDR поддерживается и ОС и монитором, то маппинг производится уже ОС. Поэтому мы видим на скриншоте две ручки настройки этого маппинга.

А сам HDR реализован через DDC2B - отдельный канал для управления яркостью подсветки.

Опять же, кто сказал? У тебя же есть ссылки? Нам нужны пруфы, Билли :-)

Я допускаю, что есть производители, которые HDR понимают как игры с подсветкой, я про них писал в предыдущем комментарии. Но это не значит, что так и надо. И, опять же, что делать в случае OLED, где нет подсветки?

Более или менее на уровне физического сигнала её решили в Display Port.

Я ссылка на спецификацию HDMI версии 1.3, где уже решены проблемы и передачи большой разрядности от видеокарты в монитор, и передача информации о расширенном цветовом пространстве из монитора в видеокарту. 2006-й год.

И на сколько я помню, две штуки DVI использовали для подключения дисплеев высокой чёткости, поскольку предел DVI 1980x1200@60Hz, а если хочешь больше, надо два канала.

И мой поинт в том, что у тебя нет технической возможности подать на эту матрицу сигнал, использующий в полной мере её возможности. В Linux’е, во всяком случае.

Вот уже скоро три недели как можно :-)

Иными словами, ты не можешь заставить два соседних пикселя светиться разным цветом так, чтобы эта разница была видна в DCI-P3, но не была бы видна в Rec. 2020.

Rec2020 ещё шире, чем DCI-P3, естественно, что не могу. Но причём тут ограничения интерфейса, я не пойму.

А вот подать на матрицу DCI-P3 сигнал, чтобы показать цвет, неоступный в матрице sRGB — элементарно. Поскольку у матрицы DCI-P3 цвета базовых пикселей в других местах, достаточно, например, подать 0x0000003FF, чтобы получить цвет, которого нет в sRGB. Именно для этого и нужен маппинг SDR в HDR, про который я говорил выше. Простого деления 10 бит сингала на 4 недостаточно )

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

Я выше уже писал и повторю, что это не имеет значения — Linux будет поддерживать HDR в том смысле, как его понимает Microsoft, хорошо это или плохо. Потому что запускается на том же оборудовании и использует портированный софт.

И ничего тут поделать нельзя.

P.S. Я вот тут подумал, что проблемы у тов. tempuser003, с которого всё началось, как раз в том, что его матрица работает в режиме HDR и ожидает от ОС конвертации SDR в HDR, а сама не конвертирует. Windows же каким-то образом узнаёт об этом и конвертирует, даже если режим HDR не включён. Ну, либо у него режим HDR в Windows включён, а он об этом не знает. Вполне допускаю, что разработчик оборудования не предполагал на этом ноубтуке ничего кроме винды, и реализацию SDR выкинул, а зачем она.

В третьих, матрица вполне реально может излучать для 0x00FF00 зелёную волну волну чуть другой частоты

Если внимательно посмотреть на диаграмму sRGB (например, тут), то можно заметить, что опорные источники для излучения там вообще не монохроматические. Связано это с тем, что люминофор в ЭЛТ не был монохроматическим и его было очень трудно сделать таким.

Пространство DCI-P3 (например, тут) использует уже близкий к монохроматическому красный канал.

Rec.2020 (там же) уже требует чтобы все три опорных источника были монохроматческими.

Соответственно, тут речь идёт не о том, что у HDR мониторов матрица слегка излучает на другой волне, она излучает вообще совсем другое.

IPS использует светофильтры, которые уже гораздо проще сделать монохроматическими. А OLED монохроматические по определению. Поэтому сделать матрицу OLED для поддержки цветового пространства Rec.2020 проще, чем в sRGB. Другое дело, что софт пока не готов.

Я его глюк воспроизвёл у себя. Воткнул в кедах HDR и перезашел в крысу. Всё, цвета все поехали.

Ага, т.е. монитор переключился в HDR, а крыса осталась не в курсе.

Осталось выяснить, кто ему переключает монитор в HDR. И исправить. Спасибо.

Кстати, надо и в KDE баг повесить, чтобы при выходе возвращал SDR.

Он прав. Если ты не видишь мыла на своём экране, хотя оно там есть - тебе надо к окулисту.

Я не вижу мыла, потому что его у меня нет, и за зрение мое не стоит беспокоится.

Выкл/вкл монитора и перезапуск SDDM не помогли, только перезагрузка.

Я так думаю, это включается где-то в драйвере.

вообще в обзорах на готовых мониторах делают тесты, но даже если на матрице будешь как будешь в нее подавать сигнал?

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

ddc все имеют, помому даже элт.

оледы тоже под hdr не проходят. у них хорошо с контрастом, но плохо с яркостью )

Иными словами, ты не можешь заставить два соседних пикселя светиться разным цветом так, чтобы эта разница была видна в DCI-P3, но не была бы видна в Rec. 2020.

Rec2020 ещё шире, чем DCI-P3, естественно, что не могу.

Тут согласен, попутал. Но ты правильно понял мысль. ))

Но причём тут ограничения интерфейса, я не пойму.

Так я же уже объяснил - софтверный стэк от битмапа окна до сигнала на кабель работает с RBG 8-бит. Можно по отдельному API запросить работу графической подсистемы с большей разрядностью или сэмулировать на процессоре / шейдерами на GPU самостоятельно большую битность на цвет, но в финале на экран уедет труколор.

Кто сказал?

Я сказал. Разве, я не решающий авторитет по всем вопросам мироздания? ;)

Во-вторых, HDMI поддерживает …

Ты не внимательно читаешь. HDMI-то поддерживает, но вот используется то же подмножество, что есть в DVI. А в DVI «Deep Color Mode» нет. Напоминаю, мы говорим про компьютерные мониторы.

Большая, чем 8 бит на канал, битность есть в телеках, но прямо сейчас с актуальными видеокартами и драйверами под венду оно работает через пень колоду:

1.

‎07-23-2019 12:28 AM

Ryzen 5 2400G can’t do 4K@60hz YCbCr4:2:2 10/12bcp in Win10 Why does the Radeon-driver keep defaulting back to 8bcp when I try to select 10 or 12bcp in 3840x2160@60Hz / YCbCr4:2:2? 12bcp should be supprted under the HDMI 2.0 specification.

Setup:

OLED55B6V (has HDMI Ultra HD Deep Color set to ‘on’ and the HDMI-input is configured to PC) AMD Ryzen G2400G on a new Asus TUF B450M-Pro Gaming with 2.0b HDMI out Driver 19.5.2 Cable is fine (I tried a new cable supporting 8K but same result) Only in YCbCr4:2:0 am I able to set a color depth of more than 8bpc (10 and 12bpc are available).

2.

13 May 1:08PM

Hi, I’m desperate!

I have an MSI Creator 17, Intel 19 with an RTX 3080. I connected an LG OLED C2 as my primary windows monitor with an HDMI 2.1

At least 2 times a day the pc freezes and the nvidea drivers crash, the hdmi port stops sending signal and if I’m lucky the laptop continues to work otherwise the image remains blocked and I have to turn off with the power button.

The problem doesn’t happen with a regular 2k resolution PC monitor I had, and it doesn’t happen when I use the laptop with no TV connected.

На текущий момент получить больше, чем 8-бит на канал через HDMI с компьютера на телевизор - это до некоторой степени рулетка на модели телевизора, модели драйвера видеокарты и фазе луны.

Невидия официально поддерживает вывод 10/12 бит с 2019-ого года:

Updated 09/29/2021 01:11 PM

How to enable 30-bit color/10-bit per color?

When connected to a 30-bit capable monitor on Quadro GPU with driver version 430.39 and Windows 10 RS4 onwards, option would be populated for enabling 30-bit support in NVCPL. User must select desktop color depth SDR 30-bit color along with 10/12 output bpc as shown in image below:

For GeForce this support has started from NVIDA studio driver 431.70 or higher version.

Ну, и самая мякотка:

Q: What happens under the hood when I enable «SDR (30 bit color)» option on Quadro or enable 10 bpc output on GeForce?

A: Two things – by default Windows OS uses 8 bit desktop composition (DWM) for SDR output (it uses FP16 composition for HDR output), the Nvidia driver/GPU will start composing 10 bit applications windows using 10 bit (or higher) precision independently of DWM, while the rest 8 bit windows, which is the case for Windows desktop and most Windows app, will be composed by OS (DWM) using 8 bit. We will also change color output by the GPU from 8 bit to 10 or 12 bits. This allows us to pass all 1024 color levels per channels from the application to the 10+ bpc supporting display without losing the precision.

То есть, если приложение само специально запросило 10 бит на канал - его картинку пробросят «как есть». Иначе - 8 бит. Единственное такое известное приложение (мне, во всяком случае) - фотошоп.

Компьютеры сейчас пытаются научиться в вывод 10/12-бит по HDMI. Ещё раз обращаю твоё внимание - речь идёт только про вывод по кабелю. А ещё остаётся вся история с цепочкой формирования видеокадра в большей битности, и на какой оно там стадии в драйверах под венду - очень большой вопрос. В настоящий момент венда в списке доступных видеорежимов работы не показывает больше «32-bit True Color» - и это 8 бит + альфа, а не 10 бит. Даже при подключённом телеке в режиме «Deep Color». Видеорежим в венде - это не пустая формальность, именно в таком формате формируется финальный кадровый буфер в DirectX-приложениях. То есть, не позднее 10-ки - примерно во всех.

Во-первых, причём тут CMYK,

Потому что только цмык в DVI поддерживает больше чем 8 бит на канал. Забудь про него, это я для формальной точности формулировки приплёл.

И мой поинт в том, что у тебя нет технической возможности подать на эту матрицу сигнал, использующий в полной мере её возможности. В Linux’е, во всяком случае.

Вот уже скоро три недели как можно :-)

Ты даже примерно не понимаешь, о чём говоришь. Давай я тебя просто шапочно познакомлю с тем, как обстоят дела с более чем труколорным графентием в линкусе:

https://wiki.gentoo.org/wiki/30bpp

As of 2018, it is possible to run Xorg in 30bpp mode (sometimes branded as “Deep Color”) with radeon or amdgpu open drivers, and a capable monitor or two.

Prerequisites A digital connector (DVI, HDMI, DisplayPort) is needed - although VGA might work, the extra precision gets lost in the analog noise. Consult your monitor’s documentation to ensure it is 30bpp-capable first; it should be safe to attempt this in any case, but if yours lacks support expect to see “signal out of range” errors.

user $ Xorg -depth 30 -retro

user $ startx -- -depth 30

Section "Screen"
  Identifier "Screen Name"
  DefaultDepth 30
EndSection

Compatibility

While most GUI toolkits have no problem with 30bpp, individual software may have graphical issues or crash outright. Anything that uses media-libs/imlib2 or media-libs/libsdl will either crash, not display anything, or misrender. This includes quite a long list of old games, as well as tools that interact with the screen.

Если ты не прописал руками поддержку 30 бит в конфиге / строке запуска, xorg работает в своём обычном режиме - труколор. Как и весь софт под него.

Но если пропишешь, тебя ждут приключения:

1. Стим просто не запускается - Steam fails to start with 30-bit colour depth display #4399
2. В хроме от слетевших в жопу цветов до отказа запуска - 10 bit color depth is causing distorted UI in linux
   Jan 3, 2024 02:32AM
   10 bit is working on Chromium for me but not Chrome. I have Ubuntu 22.04 LTS and created an xorg.conf to get it working. For regular Chrome, I’m getting the same distorted UI.

И так далее примерно с любым приложением, которое напрямую работает с растровыми буферами.

Жаль тебя расстраивать, но твои ощущения, что «где-то там в нутрях» всё работает по много-много бит на канал (аж с 2006-ого года!) не имеют никакого отношения к текущей реальности. Последние четверть века весь компьютерный программно-аппаратный стек затачивался на работу в BGRA. Съезжать с этого наследия никто никуда не спешит.

но в финале на экран уедет труколор.

То есть, если приложение само специально запросило 10 бит на канал - его картинку пробросят «как есть». Иначе - 8 бит. Единственное такое известное приложение (мне, во всяком случае) - фотошоп.

Тут ты противоречишь сам себе, говоря, что фотошоп поддерживает, но в финале уедет труколор. Бывает :-)

А далее, все твои аргументы разбиваются об один определённый факт: браузеры под Windows проходят вот этот тест. Все браузеры, до которых я смог дотянуться, показывают букву W в красном квадрате — потому что там цвет буквы такой красный, которого нет в sRGB. Выключаешь HDR, и буквы нет.

Из эксперимента следует, что далеко не только ФШ поддерживает HDR, как минимум поддерживают браузеры. Я также попробовал игры (на примере Cyberpunk2077) и не попробовал ещё видеоплееры (но слышал, что умеют).

Так и должно быть, как мне кажется. Если приложение хочет 10bpp, оно запрашивает 10bpp и получает, а если нет - выводит в 8bpp и ОС мапит SDR в HDR. И вот этой возможности — дать одному приложению буфер в 10bpp, а другому 8bpp с мапингом — в Linux до выхода KDE Wayland HDR не было.

Но если пропишешь, тебя ждут приключения:

Именно. В иксах у тебя либо все приложения работают в HDR, либо все в SDR, иначе никак. В Wayland каждое приложение получает свой буфер и он может быть любой разрядности. Поэтому в KDE 6.0 под Wayland в режиме HDR Steam спокойно запускается и работает — я проверил. Получает свои законные 8bpp и не жужжит.

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

Последние четверть века весь компьютерный программно-аппаратный стек затачивался на работу в BGRA. Съезжать с этого наследия никто никуда не спешит.

И не надо. Legacy приложения получат свой SDR буфер и будут работать, как задумал разработчик. Новые приложения с поддержкой HDR будут работать в HDR. Красота, благодать.

P.S. И если ты говоришь, что в Windows поддержка HDR так плоха, значит, не так уж сильно Linux и отстаёт :-P

А что касается телевизоров — то там никогда и не было такой задачи, как отображение SDR и HDR контента одновременно. Матрица телевизора работает всегда в HDR, HDR источник показывается как есть, интферфейс телевизора работает в HDR, а при обнаружении SDR источника производится маппинг, причём с качественным заводским ICC профилем, а не усреднённым, как сейчас в винде.

Разумеется, такую поддержку сделать проще.

В настоящий момент венда в списке доступных видеорежимов работы не показывает больше «32-bit True Color» - и это 8 бит + альфа, а не 10 бит.

Показывает. Никаких 8бит + альфа.

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

Вообще-то нет. 30 бит в фотошопе - это экслюзив, на момент выхода фичи вообще работающий только на проф-картах:

How to enable 30 bit in Photoshop
Posted on October 3, 2018 by Jeff Stubbers

Which graphics cards offer 30-bit color in Photoshop?
However professional programs like Adobe Photoshop along with others tend to utilize OpenGL for 10-bit per channel color, and currently only workstation class Nvidia Quadro, or AMD Radeon Pro graphics cards offer 10-bit per channel color through OpenGL.

Невидия пыталась уехать на 30-битный вывод изображений ещё в 9-ом году https://www.nvidia.com/docs/io/40049/tb-04701-001_v02_new.pdf , но кроме фотошопа это никому не потребовалось.

Итого, если у тебя нет квадры, или нет DisplayPort / Dual-link DVI или нет венды - нет у тебя никаких 30-бит на выход в 2018-ом году. А мы, конечно же, говорим не о них.

, все твои аргументы разбиваются об один определённый факт: браузеры под Windows проходят вот этот тест. Все браузеры, до которых я смог дотянуться, показывают букву W в красном квадрате — потому что там цвет буквы такой красный, которого нет в sRGB. Выключаешь HDR, и буквы нет.

HDR доступен в движках где-то с 7-ого года. К примеру, его поддержку выкатили для Half-Life 2 (которая вообще вышла в 4-ом году). Никаким 10-битным цветом от видеокарты к экрану тогда даже и не пахло, а основным коннектром был DVI, по одному кабелю которого нельзя передать больше 8-и бит на RGB-канал.

Из эксперимента следует, что далеко не только ФШ поддерживает HDR, как минимум поддерживают браузеры.

У тебя порочная логика рассуждений: «раз HDR - значит 10-бит, раз поддерживает вывод в HDR - значит внутри работает в 10 бит на канал». Ты подгоняешь причину под следствие.

HDR поддерживает по своему желанию любая программа, работающая через DirectX 11.1 и позднее. Хром и его клоны таковыми являются. Более того, MS вообще портировал с ящика Auto HDR - применение HDR-вывода для любой игры на DirectX 11-12 - как бы он это сделал, если бы HDR был бы не применим к 8 бит на канал и требовал исходного кадра минимум в 10 бит? И нет, это не маппинг HDR в SDR - простой маппинг существовал уже до этой фичи - венда ведь выводила эти игры на HDR-экраны.

Вот тебе пример, где выход на видео представляет из себя 10-бит, но поддержки HDR нет - в контрольной панели невидии этот режим обозначен как SDR (30-bit color) / 10 bpc

А теперь мы пойдём на официальный сайт vesa - https://displayhdr.org/ и прочитаем там английским по белому:

DisplayHDR Performance Levels
DisplayHDR 400 First genuine entry point for HDR.
Significant step up from SDR baseline:
True 8-bit image quality – on par with top 15% of PC displays today

Как мы видим, по оценке VESA и 8-бит на канал достаточно для квалификации экрана как HDR.

Итого: между битностью на канал и HDR нет прямой корреляции.

В Wayland каждое приложение получает свой буфер

Это прекрасно, но какой формат фрейм-буфера для вывода на экран через провод? Как выглядит аналог вот этого у тебя на машине:

[    69.242] (II) AMDGPU(0): Creating default Display subsection in Screen section
        "Default Screen Section" for depth/fbbpp 24/32
[    69.242] (==) AMDGPU(0): Depth 24, (--) framebuffer bpp 32
[    69.242] (II) AMDGPU(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
[    69.242] (==) AMDGPU(0): Default visual is TrueColor
[    69.242] (II) Applying OutputClass "AMDgpu" options to /dev/dri/card0
[    69.242] (==) AMDGPU(0): RGB weight 888
[    69.242] (II) AMDGPU(0): Using 8 bits per RGB (8 bit DAC)

?

P.S.

Все браузеры, до которых я смог дотянуться, показывают букву W в красном квадрате

Господи, к чему такие страдания?

console.log("Is screen in SDR mode :", window.matchMedia("(dynamic-range: standard)").matches)
console.log("Is screen in HDR mode :", window.matchMedia("(dynamic-range: high)").matches)

К сожалению, вы этого не заметите

Okay🔥🔥🔥
*саркастически-приемлимо

Давайте мы не будем углублятся в исторические лекции, а глянем вывод drm_info, чтобы понять физические ограничения по медиа-выходам. Если ваш провод не поддерживает, например, ABGR2101010, то невозможно будет подобрать правильный Connector, чтобы совместимый его Encoder, у которого CRTC с Plane’ами, которые эти 10 битный формат поддерживают. Это по ограничениям со стороны DRM KMS API.

В моем случае:

├───Connectors
│   ├───Connector 0
│   │   ├───Object ID: 107
│   │   ├───Type: DisplayPort
│   │   ├───Status: connected
...
│   │   ├───Encoders: {0}
│   │   ├───Modes
│   │   │   ├───3840x2160@60.00 preferred driver phsync nvsync 
...
│   │   └───Properties
...
│   │       ├───"max bpc": range [8, 16] = 10
│   │       ├───"Colorspace": enum {Default, BT709_YCC, opRGB, BT2020_RGB, BT2020_YCC} = BT2020_RGB
│   │       ├───"HDR_OUTPUT_METADATA": blob = 147
│   │       ├───"vrr_capable" (immutable): range [0, 1] = 1
...
├───Encoders
│   ├───Encoder 0
│   │   ├───Object ID: 106
│   │   ├───Type: TMDS
│   │   ├───CRTCS: {0, 1, 2, 3, 4, 5}
│   │   └───Clones: {0}
...
├───CRTCs
│   ├───CRTC 0
│   │   ├───Object ID: 85
│   │   ├───Mode: 3840x2160@60.00 preferred driver phsync nvsync 
│   │   ├───Gamma size: 256
...
└───Planes
    ├───Plane 0
    │   ├───Object ID: 40
    │   ├───CRTCs: {5}
    │   ├───FB ID: 0
    │   ├───Formats:
    │   │   ├───XRGB8888 (0x34325258)
    │   │   ├───ARGB8888 (0x34325241)
    │   │   ├───RGBA8888 (0x34324152)
    │   │   ├───XRGB2101010 (0x30335258)
    │   │   ├───XBGR2101010 (0x30334258)
    │   │   ├───ARGB2101010 (0x30335241)

То есть сейчас (на 6 плазме) используется цепочка, которая использует 10-битные фреймбуферы на видеовыход.

Как мы видим, по оценке VESA и 8-бит на канал достаточно для квалификации экрана как HDR.

Как уже выше написал, можно по факту DRM форматы фреймбуфферов и глянуть.

Это прекрасно, но какой формат фрейм-буфера для вывода на экран через провод? Как выглядит аналог вот этого у тебя на машине:

К счастью (поберегите психологическое здоровье разработчиков видео подсистемы) никто не будет пилить нормальный HDR под X11 (Потому что созданием поверхностей занимается уже сам kwin, а не X сервер).

Для Vulkan приложения, скорее всего, такая цепочка: VkColorSpaceKHR на swap-chain подхватывается слоем плазмы для Vulkan’а, который обрабатывается через kde-output-device(managment)-v2 из plasma-wayland-protocols (тут же скорее всего идет маппинг), потом в GBM, libdrm и DRM.

Надеюсь понятен был ответ.

P.S: скорее всего все популярные тулкити добавят поддержку HDR, когда это дело попадет в wayland-protocols (хотя бы в unstable) (там сейчас отдельный протокол от weston, plasma и gnome) и не нужно будет UI переписывать с нуля. Но вулкановские приложения должны уже сейчас заработать (как выше писал, из-за возможности накладывать слои).

То есть сейчас (на 6 плазме) используется цепочка, которая использует 10-битные фреймбуферы на видеовыход.

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

можно по факту DRM форматы фреймбуфферов и глянуть.

Можно, но нельзя. Там полный перечень форматов для работы с графикой в GPU, включая:

/* 64 bpp RGB */
#define DRM_FORMAT_XRGB16161616	fourcc_code('X', 'R', '4', '8') /* [63:0] x:R:G:B 16:16:16:16 little endian */
#define DRM_FORMAT_XBGR16161616	fourcc_code('X', 'B', '4', '8') /* [63:0] x:B:G:R 16:16:16:16 little endian */

#define DRM_FORMAT_ARGB16161616	fourcc_code('A', 'R', '4', '8') /* [63:0] A:R:G:B 16:16:16:16 little endian */
#define DRM_FORMAT_ABGR16161616	fourcc_code('A', 'B', '4', '8') /* [63:0] A:B:G:R 16:16:16:16 little endian */

/*
 * Floating point 64bpp RGB
 * IEEE 754-2008 binary16 half-precision float
 * [15:0] sign:exponent:mantissa 1:5:10
 */
#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0] x:R:G:B 16:16:16:16 little endian */
#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0] x:B:G:R 16:16:16:16 little endian */

#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0] A:R:G:B 16:16:16:16 little endian */
#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0] A:B:G:R 16:16:16:16 little endian */

Ни один из скопированных форматов по кабелю на монитор / телевизор не передать. DRM - это не про исходящий формат с разъёма видеокарты, это про операции в видеопамяти через GPU.

Для Vulkan приложения, скорее всего

Мы тут из gimp’а пытаемся 10 бит видеосигнал на экран вывести без обрезания до 8. Не мешай нам.

Но вулкановские приложения должны уже сейчас заработать (как выше писал, из-за возможности накладывать слои).

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

commented on Nov 20, 2023 •
On Linux, HDR is only currently supported when streaming outside of a desktop environment (where Moonlight can take full control over the display hardware to configure HDR). In theory, it should be possible to support HDR using our existing EGL+GLES renderer, but I think Gamescope only supports HDR via Vulkan.

In any case, I am working on a Vulkan renderer that will support HDR on Linux from within Gamescope.

Чтобы получить HDR-совместимый выхлоп на коннекторе, надо выкинуть линуксовую оконную подсистему. Что X’овую, что wayland.

Автор полузнка яркости экрана в своём бложике уже ссылался на PoC для вяленного с поддержкой HDR как раз через vulkan layer - https://github.com/Zamundaaa/VK_hdr_layer , но протокол для поддержки этой фичи в wayland'е находится в стадии нестояния последние 4-года https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

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

это не про исходящий формат с разъёма видеокарты, это про операции в видеопамяти через GPU.

DRM и про GPU и про видеовыходы. Connector абстракция над тем, что будет выходить. Можешь глянуть в какой connector вставлен, какой bpc поддерживается, установлена ли HDR_OUTPUT_METADATA. Также в vulkaninfo появилисиь 10-и битные SurfaceFormat’ы.

Мы тут из gimp’а пытаемся 10 бит видеосигнал на экран вывести без обрезания до 8. Не мешай нам.

Уже написал, как только в wayland-protocols вольют, тогда и, скорее всего, появится.

In any case, I am working on a Vulkan renderer that will support HDR on Linux from within Gamescope.

Gamescope’у скорее всего проще всех реализовать HDR, так как там не надо управлять поверхностями в поверхности. Поэтому запилили в 2023 году. Плазме ещё год понадобился, чтобы выкатить свое решение. Ещё проще только в KEGL (реализация EGL в закрытом Rogue драйвере от Imagination). Он там вообще напрямую с DRM работает (даже без GBM, они свою простою обертку придумали для этого).

Чтобы получить HDR-совместимый выхлоп на коннекторе, надо выкинуть линуксовую оконную подсистему. Что X’овую, что wayland.

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

находится в стадии нестояния последние 4-года https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

Скорее всего они начали делать на основе weston’овского расширения. Который больше в сторону gamescope по сложности/фичам нежели в сторону mutter/kwin. Вангую, что через пол года будет в unstable.

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

Дядя, не торопись, VK_EXT_swapchain_colorspace ещё даже в ARB не приняли. HDR сейчас сам по себе ещё сырой.

P.S: Плазменных вулкановских слоев почему-то нет (помню в 5 плазме пачка была). Видимо 10 bpc заставили работать без них, что отлично. Ушел допиливать свой движок.

P.P.S: Мне лень искать в логах kwin 10bpc, но при включении HDR мой монитор (lg-32un880-b, у меня нет пол ляма для тру-тру 10 битного монитора) выключается и включается, и на несколько секунд в правом верхнем углу написано «HDR».

P.P.P.S: Что мне выводит при включении HDR в dmesg:

[ 7170.691830] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.691834] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.691992] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.691993] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.692048] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.692049] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.692118] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.692119] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.692199] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.692201] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.692272] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.692273] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.692429] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.692430] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.692499] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.692500] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.704485] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.704488] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00
[ 7170.704641] HDR SB:01 1a 02 00 f1 84 d8 3c 43 34 82 81 60 1d 89 09
[ 7170.704642] HDR SB:09 3d 47 40 58 01 e2 0d 58 01 58 01 00 00 00 00

Судя по всему это вот этот принт. Сам kwin надо настраивать, чтобы он что-то в лог писал. Мне, скорее всего, это лень будет делать.

Итого, если у тебя нет квадры, или нет DisplayPort / Dual-link DVI или нет венды - нет у тебя никаких 30-бит на выход в 2018-ом году. А мы, конечно же, говорим не о них.

Ну окей, а в 24-м году есть.

HDR доступен в движках где-то с 7-ого года. К примеру, его поддержку выкатили для Half-Life 2 (которая вообще вышла в 4-ом году). Никаким 10-битным цветом от видеокарты к экрану тогда даже и не пахло

HDR не был стандартизирован в те годы. Я же писал несколько раз, что HDR в компе сегодня, это то, что понимает под HDR Microsoft. А она понимает вот что: расширенный динамический диапазон по яркости, расширенное цветовое пространство, 10-битная разрядность сигнала.

У тебя порочная логика рассуждений: «раз HDR - значит 10-бит, раз поддерживает вывод в HDR - значит внутри работает в 10 бит на канал». Ты подгоняешь причину под следствие.

Это не порочная логика, это стандарт HDR. Сегодня, раз написано HDR, то должно быть: расширенный динамический диапазон по яркости, расширенное цветовое пространство, 10-битная разрядность сигнала.

И нет, это не маппинг HDR в SDR

Это мапинг SDR в HDR. Точно также сегодня телевизоры HDR показывают картинку с DVD плееров, которые не в курсе про HDR.

Вот тебе пример, где выход на видео представляет из себя 10-бит, но поддержки HDR нет - в контрольной панели невидии этот режим обозначен как SDR (30-bit color) / 10 bpc

А это пожалуйста — не называешь это HDR, называй как хочешь, я против nvidia ничего не имею ;-)

А теперь мы пойдём на официальный сайт vesa - https://displayhdr.org/ и прочитаем там английским по белому:

DisplayHDR Performance Levels DisplayHDR 400 First genuine entry point for HDR. Significant step up from SDR baseline: True 8-bit image quality – on par with top 15% of PC displays today

Как мы видим, по оценке VESA и 8-бит на канал достаточно для квалификации экрана как HDR.

Я уже писал выше, что а) VesaHDR400 это самый слабый стандарт в линейке. У меня монитор поддерживает VesaHDR500, а там уже 10-бит на канал обязательны.

б) Microsoft поддерживает стандарт HDR10 и плювать хотела на VesaHDR. HDR10 это стандарт 2015 года, и в нём написано:

EOTF: SMPTE ST 2084 (PQ)
Bit depth: 10 bit
Color primaries: ITU-R BT.2020 (identical to BT.2100 primaries)

А максимальная яркость до 10000 нит (отсюда цифра 10 в названии стандарта).

HDR10 поддерживается Microsoft, Apple, а в недалёком будущем и Linux. Угадай, что станет с остальными стандартами.

Итого: между битностью на канал и HDR нет прямой корреляции.

Итого: включение HDR в винде предполагает 10 бит на канал.

Включение HDR в KDE приводит к заметному эффекту маппинга SDR в HDR, смещению цветов, что говорит о том, что там как минимум прописана поддержка расширенного цветового пространства. Проверить 10-битность пока что не на чем.

Господи, к чему такие страдания?

К тому, что буква «W» на красном фоне нарисована чуть более тёмным цветом в 10-битном цвете, но так, что при маппинге обратно в SDR цвет сливался бы с фоном. Сохранена в файле AVIF, который поддерживает 10 бит на канал. И если я вижу букву «W», то:

1. Браузер поддерживает вывод 10 бит на канал.
2. Графическая подсистема Windows поддерживает вывод 10 бит на канал.
3. Драйвер бытовой встроенной видеокарты поддерживает внутреннее представление 10 бит на канал.
4. Мне не нужна профессиональная квадра для вывода 10 бит на канал.
5. По HDMI кабелю до монитора передаются 10 бит на канал.
6. Матрица монитора поддерживает вывод 10 бит на канал.

Итог: я вижу букву «W» на красном фоне. Это значит, что большая часть того, что ты мне рассказывал, устарела.

Это значит, что большая часть того, что ты мне рассказывал, устарела.

Хорошо, согласен. Пусть HDR в 2К24+ - это 10 бит на канал (и в жопу эту VESA’у с её стандартами).

Теперь переходим к скриншоту в оп-посте и тезису, что «свершилось» - что там с этим HDR в Linux / wayland / chrome / avif ? Видна буква «W» в линуксе-то?

Теперь переходим к скриншоту в оп-посте и тезису, что «свершилось» - что там с этим HDR в Linux / wayland / chrome / avif ? Видна буква «W» в линуксе-то?

Так я ж написал, что свершилось. Появилась поддержка HDR в Wayland в каком-то виде, появился маппинг SDR приложений в HDR - это пока всё, что можно проверить.

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

И да,

HDR в компе сегодня, это то, что понимает под HDR Microsoft. А она понимает вот что: расширенный динамический диапазон по яркости, расширенное цветовое пространство

«Расширенное» и «углубленное» давай оставим Горабчёву. у нас тут формально «технический» форум.

, 10-битная разрядность сигнала.

То есть, в сухом остатке (напоминаю, нас интересует только техническая часть передачи сигнала с видеокарты на экран) мы говорим про HDR10 через HDMI 2.1

P. S.

понимает Microsoft.

HDR10 - это часть стандарта Ultra HD Blu-ray и Ultra HD television / Ultra HD / UHDTV / UHD. Это из области бытовой видео- и телевидео- техники. Компьютеры тут догоняют.

«Расширенное» и «углубленное» давай оставим Горабчёву. у нас тут формально «технический» форум.

Расширенное цветовое пространство — это технический термин, означающий цветовое пространство с охватмо больше чем sRGB. В английском extended gamut color space, в русском gamut отвалилось.

То есть, в сухом остатке (напоминаю, нас интересует только техническая часть передачи сигнала с видеокарты на экран) мы говорим про HDR10 через HDMI 2.1

10-битный цвет при передаче на экран поддерживается, начиная с HDMI 1.3. А ведь есть и другие способы подключения.

HDR10 - это часть стандарта Ultra HD Blu-ray и Ultra HD television / Ultra HD / UHDTV / UHD. Это из области бытовой видео- и телевидео- техники. Компьютеры тут догоняют.

Вполне логично, что разработки для XBox Microsoft тащит на компы. Тут не в чем её упрекнуть.

10-битный цвет при передаче на экран поддерживается, начиная с HDMI 1.3.

Но это не HDR10, ололо. HDR10 - только с 2.0b, т.е. фактически с 2.1

Расширенное цветовое пространство — это технический термин, означающий цветовое пространство

Давай оставим в покое всё пространство вселенной во всех его ипостясях, и с фокусируемся на битах и сигналах по кабелю. То есть тем, что на самом деле выдаёт видеокарта.

Так я ж написал, что свершилось. Появилась поддержка HDR в Wayland в каком-то виде

И мой поинт в том, что у тебя нет технической возможности подать на эту матрицу сигнал, использующий в полной мере её возможности. В Linux’е, во всяком случае.

Вот уже скоро три недели как можно :-)

HDR приложений пока что нет, букву не видно.

М-м-м-м-м-м… Следует ли мне тут задавать какие-либо вопросы? ;)

Но это не HDR10, ололо. HDR10 - только с 2.0b, т.е. фактически с 2.1

А Bluray всякие, для которых этот HDR10 создавался, они как выдавали свои 10 bpp?

Нет, у нас полное согласие и понимание :-)

А Bluray всякие, для которых этот HDR10 создавался, они как выдавали свои 10 bpp?

А обычный Blue-ray никакого 10 bpp не выдаёт. Выдаёт Ultra HD Blu-ray проигрыватель с Ultra HD Blu-ray диска Ultra HD телевизору, если он подключён кабелем стандарта не менее ВНЕЗАПНО HDMI 2.1.

А если кабель фуфлыжный - то не выдаёт.

у тебя нет технической возможности подать на эту матрицу сигнал, использующий в полной мере её возможности. В Linux’е, во всяком случае.

HDR приложений пока что нет, букву не видно

Нет, у нас полное согласие и понимание :-)

Так зажги пиксель в букве, в чём проблема-то? ;)

Я, как программист, могу написать демку, которая создаст нужную поверхность выведет нужное изображение.

Но я не программист.

Разработчики KDE утверждают, что поддержка HDR писалась в расчёте на игры и поддержку со стороны wine. Следовательно, можно попробовать поставить игрушку и запустить её через wine.

К сожалению, на моём ноутбуке мало место на SSD, help wanted.

Это значит, что большая часть того, что ты мне рассказывал, устарела.

Краткое содержание того, что я выше криво рассказывал, для потомков:

https://www.x.org/wiki/Events/XDC2016/Program/xdc-2016-hdr.pdf

HDR Basic Flow  
The basic flow for 3D applications to render and display HDR: 
Application 
 • Create FP16 buffer for rendering. 
 • Render to FP16, using scRGB color space. 
 • Tone map the scRGB FP16 content, for the target monitor's capabilit
 • Provide metadata to be sent to monitor. 
Driver (or composite manager) 
 • Composite with SDR content. 
Driver/GPU 
 • Receive scRGB FP16 image. 
 • Perform inverse EOTF to encode FP16 in display signal. 
 • Send encoded display signal and HDR InfoFrame to monitor. 
Monitor 
 • Receive HDR InfoFrame. 
 • Perform EOTF to decode digital signal into HDR content. 
 
HDR Metadata: SMPTE 2086  
SMPTE 2086 defines HDR-related metadata passed between GPU and monitor: 
The GPU needs this metadata from monitor, to know how to render image. 
The monitor needs this metadata from GPU, to know how to interpret signal. 
CEA-861-3 defines how HDR metadata is transferred: 
• Encoded in EDID (Display => GPU). 
• Encoded in InfoFrame (GPU => Display). 

Ну, и вообще занимательное чтиво.

help wanted.

Не игрушка, но возможно подходит.
https://github.com/mpv-player/mpv/issues/13078#issuecomment-1863788237

О, спасибо, завтра попробую.

Супер, после сборки появилась пачка новых surface’ов:

colorSpace = COLOR_SPACE_HDR10_ST2084_EXT
colorSpace = COLOR_SPACE_HDR10_ST2084_EXT
colorSpace = COLOR_SPACE_EXTENDED_SRGB_LINEAR_EXT
colorSpace = COLOR_SPACE_BT709_LINEAR_EXT

Расширение HDR:

VK_EXT_hdr_metadata  : extension revision 2

mpv тоже заработал в HDR режиме.

Для NixOS можно от сюда взять рецепт для сборки (обновите только rev + hash): https://github.com/nix-community/kde2nix/issues/20#issuecomment-1890432417

А, ну ок. Hdmi 2.1 это 2017 год, Microsoft добавила поддержку HDR10 в 2019-м. Все сходится )

если не ошибаюсь то у меня в Debian Testing где плазма 5.27 можно сделать такую же панель, так что это уже давно