Процесс вывода кадра из Front buffer на матрицу монитора. Как это работает?

монитор ожидает по vga кабелю значение текущего rgb пиксела

Монитор "считает" количество отправленных пикселей? Или только на тайминги ориентируется?

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

А вот здесь можно подробнее? Как передает (пиксель, строка)? Что за буфер (или буферы), что там хранится? Какие компоненты монитора что делают (процессор монитора, контроллер дисплея, еще кто-то)?

krv2k, только тайминги

контроллер дисплея вынужден как то хранить пикселы, потому что сама технология вывода lcd требует память на каждый пиксел

но вот как именно, это к производителю монитора (почти наверняка там типовая dram/sram на десятки мегабайт), но возможна ситуация что пикселы хранятся в самой матрице.

контроллер в современных мониторах может еще и скалировать изображение, а еще есть всякие улучшаторы и прочее, в общем там может быть полноценный микропроцессор

vga -> АЦП -> контроллер монитора + память (обрабатывает изображение, скалинг, улучшение, интерфейс) -> контроллер (обычно lvds) -> панель монитора

один там контроллер или несколько уже не важно

Посмотрите, пожалуйста, мое описание ниже в ответе, верно ли оно?

Монитор "считает" количество отправленных пикселей? Или только на тайминги ориентируется?

krv2k, Вообще, помимо "проводков" по которым передаётся цвет, есть ещё проводки hsync и vsync, которые и позволяют засинхронизировать работу видеокарты и монитора.
Попробуй вот это посмотреть: https://ru.wikipedia.org/wiki/%D0%92%D0%B5%D1%80%D...

Вова, к сожалению, в статься кроме слов "V-Sync помогает избавиться от разрывов" ничего больше нет. Понимание работы V-Sync - это следующий шаг после того, как пойму принцип работы без нее.

krv2k, Можно просто вбить в гугл "hsync vsync" и полистать. Вот, например.

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

Вова, спасибо, понял что вы имели в виду. Про вертикальные и горизонтальные синхроимпульсы в принципе понятно, также понятно как работает вертикальная синхронизация частоты кадров (эта та, про которую как раз статья на вики) на ЭЛТ-мониторах. Непонятным остается вопрос как это работает на ЖК-мониторах при использовании цифровых интерфейсов (DP, например)? С какими-нибудь буферами или аналогично?

krv2k, когда говоришь про не CRT мониторы, не нужно тогда рассуждать про VGA, lcd мониторы работают с цифрой, те. информация о пикселах приходит в контроллер монитора буквально числами, какой там протокол (hdmi/dp/vga) дело десятое, и все нюансы этих протоколов почти не влияют на собственно изображение. CRT фичи при использовании VGA подключения СИМУЛИРУЮТСЯ, изображение рисуется в виртуальный буфер а из которого контроллер уже по своей логики транслирует изображение на матрицу

rPman, ок, не будем отвлекаться на CRT. Также пока не будем учитывать всякие вертикальные синхронизации и прочие улучшайзеры.
Правильно ли я понимаю, что при использовании в том числе цифровых протоколов (например, DP):
1) Видеокарта по готовности кадра помещает его в Front buffer и начинает отправку на монитор. Кадр отправляется построчно.
2) Кадр в мониторе помещается Frame buffer, откуда выводится на матрицу контроллером дисплея. Также построчно.
3) Монитор не знает, что на текущий момент находится в Frame buffer, целый кадр или состоящий из нескольких разных кадров.

Ну и дополнительный вопрос. Если кадр готов, но прошлый еще не до конца передан, то Front buffer обновляется или ожидается окончание передачи предыдущего?

hdmi передает видеокадр целиком, есть инструменты управления паузой между передачами

display port есть различные технологии (я ноль в этом, на любой вопрос гуглю названия) типа Partial Frame Updates - обновление только части экрана или сжатие потока (это же цифра а не аналоговая передача байт в байт)

3) Монитор не знает, что на текущий момент находится в Frame buffer, целый кадр или состоящий из нескольких разных кадров.

что значит несколько разных кадров, монитор работает с единственным frame буфером, а всякие альфа каналы, наложения спрайтов или несколько кадров (текущий который выводится, а второй - который формируется, бывает еще третий, плюс алгоритмы поверх них для оптимизации или наложения эфектов) - это все фишки видеокарты, до монитора доходит только готовая картинка в единственном виде

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

rPman, Frame buffer - это кадровый буфер в самом мониторе, я про него.
На стороне видеокарты Front buffer (передний буфер), из которого передается кадр. Да, новый кадр готовится в другом буфере, и они потом меняются местами. Если не включена вертикальная синхронизация, то он может поменяться в момент передачи.

Я тут понял, что на текущий момент у меня непонимание в одном ключевом вопросе, который не дает мне дальше продвинуться.
Всегда ли в мониторах есть Frame buffer на полный кадр, и изображение выводится на матрицу с него. Варианты следующие:
1) Да, Frame buffer на полный кадр есть, процессы передачи кадра и его вывода не синхронизированы.
2) Да, Frame buffer на полный кадр есть, но процессы передачи кадра и его вывода синхронизированы.
3) Нет, Frame buffer на полный кадр нет, соответственно, процессы передачи кадра и его вывода синхронизированы.

В случае с display port, при наличии в мониторе технологии частичной передачи кадра, скорее всего возможно не полная отрисовка

в остальных случаях все зависит от реализации процесса отрисовки в мониторе, например hdmi позволяет сэкономить и сделать построчную развертку, сохраняя в памяти только одну строку

и самое главное, получить доступ к таким низкоуровневым операциям не получится, это драйвер должен сам это делать. Мало того, если ты разрабатываешь видеокарту (или подключаешь свое устройство к монитору напрямую), такие вещи не должны так же волновать, ты отсылаешь кадр, как именно он рисуется в мониторе знает только его производитель, т.е. нужно брать datasheet конкретного контроллера и изучать,...

rPman, так вот вопрос в том числе про отправку кадра. Правильно ли я понимаю, что если видеокарта отправила одну строку кадра, то эта строка нигде не задержится и сразу отрисуется на матрице? То есть, передача кадра всегда синхронизирована с выводом изображения?

krv2k, что во фразе - только производитель контроллера монитора знает, не понятно?

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

rPman,

а всякие HDR и вовсе требуют содержимое всего буфера кадра

Но тогда они требуют также и вертикальной синхронизации, правильно? Да и задержка вывода в этом случае увеличивается, так?

krv2k, зачем, просто лаг, пока ты передаешь по кабелю следующий кадр, оно считает и выводит предыдущий

rPman, правильно ли я понимаю, что в этом случае используется полнокадровый буфер на стороне монитора и будет задержка в 1 цикл?

1) Цикл №1
- видеокарта передает кадр №1
- монитор принимает его и сохраняет в буфер
2) Цикл №2
- видеокарта передает кадр №2
- монитор выводит кадр №1
- на освободившееся место в буфере начинает записываться кадр №2

Я правильно уловил суть процесса?

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

в современных мониторах может быть напихано столько технологий, каждая из которых может требовать дополнительной памяти (та же HDR например), или вот погуглил, есть Motion Blur Reduction или Overdrive/Response Time Compensation

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

Немного резюмирую:
1) Данные передаются из Front buffer видеокарты (в момент готовности кадра) в Frame buffer монитора. При этом до окончания передачи кадра Front buffer не обновляется.
2) Монитор постоянно построчно читает данные из Frame buffer и выводит их (а иначе он не успеет поддерживать свою частоту обновления). При этом монитор не знает, полный кадр сейчас находится в Frame buffer или части двух (или более) разных, просто выводит что есть.

Я все правильно понял?

1. Передний буфер видяхи не обновляется и не переключается только в случае VSYNC. Если он обновился или переключился посреди передачи кадра, это всем известный разрыв.
Обновился = данные в нём изменились.
Переключился = другой буфер стал передним.

2. Архитектура главной мониторной микросхемы (нормально я её назвал?) может быть самая разная. Декодирует видеоданные, проводит с ними свою магию и чем быстрее передаёт на матрицу. У современных мониторов задержка обработки исчисляется несколькими строками, однако присущие телевизорам улучшайзеры могут вносить задержку кадр и больше.

3. У ноутбуков нет главной мониторной микросхемы. Данные из кадрового буфера напрямую превращаются в команды матрице. Часть расчётов и улучшайзеров (в основном опциональные вроде G-Sync) работает прямо на вычислительном ядре видяхи.

Правильно ли я понимаю, что у ЖК-монитора всегда есть полноценный Frame buffer? Ведь только в этом случае не нужно синхронизировать передачу кадра и вывод его на экран.

Я процесс представлял следующим образом:
- Видеокарта передала кадр максимально быстро согласно скорости интерфейса
- Монитор вывел кадр как успел

Или это не так и скорость передачи синхронизируется со скоростью обновления экрана, чтобы монитор сразу выводил то, что прислали?

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

Переключение — в играх, когда каждый кадр перерисовывается весь экран.

Правильно ли я понимаю, что у ЖК-монитора всегда есть полноценный Frame buffer?

Какой-то буфер есть. Не обязательно на весь кадр, может быть и на пару строк, но в современных реалиях весь кадр, просто для работы улучшайзеров и G-Sync/FreeSync.

- Видеокарта передала кадр максимально быстро согласно скорости интерфейса
- Монитор вывел кадр как успел

Или это не так и скорость передачи синхронизируется со скоростью обновления экрана, чтобы монитор сразу выводил то, что прислали?

Второе. Видяха передаёт кадры ритмично согласно оговоренной кадровой частоте. Монитор устроен так, что придерживает видеоданные как можно меньше (а старый кинескопный — вообще никак не придерживает).

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

А ещё существует такая штука, как G-Sync/FreeSync — расширение протоколов DVI/DisplayPort, чтобы со стороны видяхи можно было приостановить виртуальную «развёртку», если кадр игры ещё не готов. В таком случае и монитор приостанавливает свою «развёртку», но долго это делать нельзя — пиксели матрицы возвращаются в исходное положение, обычно серое. Тогда монитор по своей инициативе производит обновление матрицы по тем данным, что завалялись в его кадровом буфере. Если вдруг в это время придёт новый кадр, случится разрыв. G-Sync (который одинаков у всех производителей) прикидывает, когда обновлять матрицу, чтобы это было пореже. И это — одна из разниц между разными FreeSync-мониторами.

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

Кажется, начинаю понемногу понимать.

1) При обычной вертикальной синхронизации, если кадр не готов, то видеокарта отправляет повторно старый, или ничего не делает, рассчитывая на полный кадровый буфер в мониторе? А при G-Sync/FreeSync?
2) При G-Sync/FreeSync монитор ждет полного кадра, чтобы начать его отрисовывать? В этом случае, наверное, кадр на полной скорости передается?

Mercury13,

они могли задерживать изображение на два-три кадра

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

krv2k, До G-Sync вообще не было понятия «кадр не готов». Видяха ритмично передаёт на монитор то, что находится в переднем буфере.
При G-Sync видяха ПРИОСТАНАВЛИВАЕТ «РАЗВЁРТКУ», чтобы дождаться появления нового кадра. Помните, я говорил, что в играх происходит переключение буферов — задний буфер становится передним — вот этого события и ждёт. Про скорость передачи я не в курсе, но, с большой вероятностью, обычная, ведь всё ещё надо эти данные вывести на матрицу с той скоростью, которую позволяет главная мониторная микросхема и матрица.

krv2k, Получается, что пара кадров буферизировалась. Подозреваю, причина — нехватка разрядности ЦАП (подчас 6 бит — а значит, временнóй дизеринг) и овердрайв (подача на матрицу более сильного импульса, чем нужно, чтобы пиксели побыстрее переключились).

Mercury13, так если есть полный кадровый буфер, то можно и не синхронизировать скорости: передали за 5 мс, а вывели за 10 мс. Вроде, логично, если весь сигнал в цифре. Зачем монитору синхронизироваться с видеокартой, если можно просто читать из буфера что там есть? Или так не делают по какой-то причине?

krv2k,

передали за 5 мс, а вывели за 10 мс.

А зачем? Это просто внесение неоправданных задержек изображения и усложнение входных цепей монитора.

Mercury13,

А зачем?

Я имел в виду не задержку, а, наоборот, передачу кадра быстрее, чем может его отобразить монитор (скорость интерфейса выше).
И это кажется не усложнением, а упрощением. Вместо синхронизации передачи каждой строки, мы синхронизируем только передачу кадра. То есть, передали быстро в буфер монитора кадр, а монитор уже сам с ним разбирается.

Для примера возьмем монитор 60 Гц.
1) Экран обновляется за 16,7 мс.
2) Передать кадр мы можем, допустим, за 5 мс.
3) Этот кадр записывается в буфер монитора.
4) Монитор выводит этот кадр за 16 мс.

Здесь нам нужно лишь синхронизировать время передачи нового кадра, а за счет быстрого интерфейса мы можем передать его быстрее. Я предполагал, что по сравнению с CRT направление ЖК ушло именно в эту сторону. Или все не так и передача до сих пор синхронизируется построчно?

Не забудьте, что...
1. Монитор — самая скоростная периферия наших компов. Просто посчитайте поток данных.
2. Разрыв означает, что в видеопотоке появились новые данные. И это пусть не самый красивый, но самый корректный способ это передать на монитор.

Передача быстрее (при неспособности монитора угнаться), как ни странно, увеличивает задержку между переключением буферов и появлением изображения на мониторе.

...ну, если vsync отключён — но он сам изрядная задержка.

Mercury13, "Разрыв означает, что в видеопотоке появились новые данные. "
Это если данные аналоговые. Но у нас цифра, и отдельные каналы взаимодействия видеокарты и монитора. Не вижу проблем сигнализировать другими способами.

Что значит «аналоговые»? Мы исходим из трёх посылок.
1. Доступ к видеопамяти быстрый, переключение буферов мгновенное.
2. Передача команд на матрицу всё ещё медленная.
3. Мониторный интерфейс крайне быстр, быстрее всех сетей и USB, и требует дальности в метры. На мобильных устройствах другая архитектура.

А кадровый буфер всегда цифровой. Буферизация нескольких кадров в первых мониторах служила целью

...служила целью поднять измеряемые характеристики при том, что единственный способ измерить задержку — снимать скоростной камерой запараллеленные кинескоп и ЖК.

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

Mercury13,

увеличивает задержку между переключением буферов и появлением изображения на мониторе

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

Mercury13,

Мы исходим из трёх посылок.

Исходя из этих предпосылок есть несколько теоретических вариантов реализации, и я как раз хочу понять как это реализовано. Что с буфером, что без буфера есть возможность достичь минимальных задержек.

Mercury13,

что единственный способ измерить задержку — снимать скоростной камерой запараллеленные кинескоп и ЖК

Есть тесты, в них как раз изменяют задержку, но там не нашел инфы что происходит "внутри монитора",
https://blurbusters.com/gsync/gsync101-input-lag-t...

Пусть кадр для простоты телепортируется мгновенно, но только 60 раз в секунду. Тогда смена кадра посреди показа означает сначала ожидание нового пакета, потом ожидание команды на матрицу. При постепенной передаче будет разрыв (половина одного кадра, половина другого), но не будет задержки, напоминающей vsync.

Mercury13,

Тогда смена кадра посреди показа означает сначала ожидание нового пакета

Ожидания не будет, так как буфер считывается построчно. Просто после считывания строки 155 кадра №1 будет считана и выведена строка 156 кадра №2. То есть, монитор не знает что сейчас есть у него в буфере, просто читает его построчно и выводит.

Но это значит, что кадры могут телепортироваться не просто 60 раз/с, а С ЧАСТОТОЙ, МНОГОКРАТНО ПРЕВЫШАЮЩЕЙ МОНИТОРНУЮ. И нахуа такое усложнение, если монитор — и так самая быстрая периферия в наших компах?

Не забудьте, что буфер видяхи и монитора — это не одно и то же. Между ними два метра витой пары.

Мобильные устройства действительно имеют дело с видяшным буфером. Но это имеет один минус: у них с апскейлерами швах. А может, и не швах, а фича — определённые разрешения показываются в окошке, а не на весь экран.

Mercury13,

нахуа такое усложнение,

Наоборот, же, упрощение. Нам не нужно синхронизировать 2 процесса - передача и вывод. То есть, нужно, но не построчно, а только начало кадра.

Но это все теоретически. Как на практике реализовано, наверное, есть в спецификациях, но, к сожалению, я даже не знаю что и где читать.

Mercury13,

Между ними два метра витой пары.

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

krv2k,
Идеал — передавать данные ровно тогда, когда монитор их захочет. И современный протокол — при условии, что матрица одна и нет G-Sync — достаточно близок к этому.

Mercury13, немного резюмирую, чтобы понять, правильно ли я все понял (пока не рассматриваем улучшайзеры).

1) Передача кадра из переднего буфера видеокарты на монитор всегда синхронизирована с выводом изображения на матрицу. То есть, при 60 Гц, и кадр выводится на матрицу 16 мс, и само изображение от видеокарты также передается 16 мс.
2) Если в момент передачи буфер обновился, то получаются разрывы изображения.
3) При использовании вертикальной синхронизации пока идет передача блокируется обновление переднего буфера.

Я ничего не упустил? Если это так, то принцип передачи кадра почти ничем не отличается от ЭЛТ-мониторов: тоже все ориентируются на тайминги.

Еще такой вопрос появился.
У монитора на 60 Гц время обновления матрицы ~16 мс + 0.7 мс VBLANK, у монитора на 120 Гц время обновления матрицы 8 мс + 0.35 VBLANK. Если Монитору на 120 Гц выставить частоту 60 Гц, то время обновления матрицы будет 8 мс или 16 мс?

krv2k, 16 мс. За это время матрица точно не уползёт в дефолтный цвет.

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

Разрыв случается, если кто-то обновит данные в буфере или переключит его (сделает передним другой буфер), пока идёт передача кадра.

При вертикальной синхронизации переключение буферов (реже перезапись) происходит между кадрами.

Протоколы были разработаны на заре ЖК с оглядкой на кинескопы, но оказались достаточно удачными и для ЖК.

krv2k, ТруъЦвет ФуллХэДэ 60 fps — это 3 Гбита/с без учёта технических данных. Немало.

Mercury13, отлично, картина начинает проясняться )
Теперь можно перейти к VRR (G-Sync/FreeSync).
1) Здесь передача тоже завязана на тайминги, но начало отправки кадра привязано не к частоте монитора, а зависит от видеокарты (в допустимых пределах, на которые влияет диапазон частоты обновления монитора).
2) Монитор ждет от видеокарты начала передачи кадра, и как только передача начинается, он стандартно начинает выводить этот кадр.
3) При выводе кадра используется максимально доступная скорость (как на максимальной частоте монитора), даже если реальный FPS гораздо меньше.
4) Если новый кадр не успевает подготовиться к нужному времени (зависит от минимально возможной частоты монитора), то видеокарта повторно отправляет предыдущий кадр.

Все ли правильно я описал?

1. Да.
2. Да.
3. Не в курсе, но подозреваю рабочую частоту — так меньше глюков из-за странного монитора, 10-метрового кабеля и прочего. К тому же скоростные мониторные кабели содержат больше пар.
4. Монитор сам делает обновление матрицы имеющимся кадром, когда совсем уж невтерпёж, понимая, что если в этот момент придут данные с видяхи, будет разрыв. На настольном. В мобильных системах многое что идёт прямо на вычислительном ядре видяхи.

Mercury13,

Монитор сам делает обновление матрицы имеющимся кадром

1) Откуда у него кадр? Или у таких мониторов всегда есть буфер с полным кадром?
2) Что происходит, когда монитор начал сам обновлять экран, дошел до строки 150, и тут начинает приходить новый кадр от видеокарты? Может, все-таки видеокарта должна отправить кадр повторно?

krv2k,
1. У всех современных мониторов есть полный кадр просто для работы улучшайзеров. Чтобы приблизительно понимать, что творится на экране. А в модуле G-Sync™️ вообще едва ли не гиг памяти.
2. Мы делаем систему, призванную снизить задержку от кнопки до изображения. Модет, лучше разрыв?

Mercury13,
1)

У всех современных мониторов есть полный кадр

Так если монитор сразу выводит строку, которая пришла, то откуда полный кадр? Или одновременно строка и выводится и записывается в буфер? Тогда как работает улучшайзер, если строка уже выведена? Я что-то запутался.

2)

Модет, лучше разрыв?

Может, и лучше, но вот какой он будет? Монитор прервет вывод прошлого кадра с 150-й строки и начнет выводить новый с первой строки?

Давайте тогда еще упростим:
- Передается только изображение, а точнее - один кадр из буфера.
- Преобразование сигнала для передачи не будем учитывать, пусть он уже добрался до кабеля.
- Никаких хабов нет, прямое подключение DP-DP.

Уточню еще один момент. Меня, скорее, интересует логическая реализация (какие блоки есть), а не физическая.

Это что, ИИ так отвечает?
Очень подозреваю.

1. "Да, в некоторых случаях frame buffer (кадровый буфер) может располагаться в мониторе, хотя обычно он находится в видеокарте или GPU. В современных мониторах с интегрированными скалерами, как правило, есть собственный буфер для хранения текущего кадра, который выводится на экран." (с) Гугл

2. DAC - это цифро-аналоговый преобразователь. Можно считать, что это просто горсть резисторов (R-2R), которая позволяет подать на вход, например, один байт (в виде нулей и единиц), а на выходе получить аналоговое напряжение. Условно, подали на вход 00000000, получили на выходе 0 Вольт. Подали 11111111, получили 5 Вольт. Это было актуально, когда мониторы были ЭЛТ, ибо напряжением можно было задавать яркость каждого пикселя. Используется ли аналоговый сигнал внутри LCD мониторов - я не знаю. В любом случае, DAC не занимается обработкой изображения.

Вова,

в некоторых случаях frame buffer (кадровый буфер) может располагаться в мониторе

В современных мониторах он обычно есть или нет? Если нет, то как данные с кабеля (например, DP) попадают на матрицу? Контроллер дисплея в реальном времени (как в ЭЛТ-мониторах) получает их и обновляет матрицу?

Вова,

Используется ли аналоговый сигнал внутри LCD мониторов - я не знаю

Как тогда применяются настройки монитора в части яркости и контрастности? Кто и в какой момент этим занимается?

В современных мониторах он обычно есть или нет?

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

Если нет, то как данные с кабеля (например, DP) попадают на матрицу?

Сигналы hsync и vsync, которые посылает видеокарта, явным образом говорят монитору, где начинается кадр, и где начинается каждая строка. Сейчас, видимо, эти сигналы говорят, в какое конкретно место фрейм-буфера надо произвести запись. Думаю, что раньше, когда фрейм буфера не было в мониторе, эти сигналы просто запускали какие-то внутренние генераторы в мониторе, которые виртуально двигали виртуальный луч слева направо и сверху вниз. (Ну или реальный луч в ЭЛТ мониторах).

Контроллер дисплея в реальном времени (как в ЭЛТ-мониторах) получает их и обновляет матрицу?

Думаю, что матрицу никто не "обновляет". Чисто технически LCD матрица это миллионы "пикселей", каждый из которых представлен парой металлических пластин и капли "жидких кристаллов" между ними. Подаёшь напряжение - кристалл упорядочивается/поворачивается и становится прозрачным. (Сейчас мониторы цветные, и таких капель-кристаллов три штуки, на каждый пиксель. Там выше есть ссылки и внутри картинки). Короче, матрицу нельзя обновить, просто потому, что она не хранит данные о цвете. Всё, что делает матрица, это меняет яркость конкретного пикселя, в зависимости от поданного на этот пиксель напряжения. Данные хранятся снаружи, в какой-то видеопамяти. Плюс есть некая схема-драйвер, которая берёт конкретное значение из видеопамяти и формирует напряжение, которое управляет пикселем. (Ну да, это ЦАП, он же DAC).

Как тогда применяются настройки монитора в части яркости и контрастности? Кто и в какой момент этим занимается?

По-видимому в тот момент, когда от видеокарты приходит сигнал, процессор монитора корректирует яркость/контрасность (путём умножения цифры - значения яркости на некий коэффициент) и записыват результат во фрейм-буфер.

Вова, яркость в некоторых технологиях (oled/плазма/microled) определяется скоростью мерцания пиксела плюс глобально яркостью подсветки (на современных мониторах подсветка на зоны поделена)

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