The OpenNET Project / Index page

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

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


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

Оглавление

Выпуск Wayland-Protocols 1.32, opennews (?), 04-Июл-23, (0) [смотреть все]

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


34. "Выпуск Wayland-Protocols 1.32"  –1 +/–
Сообщение от Oe (?), 04-Июл-23, 13:43 
Дык включенный vsync это такой же костыль, как и xorg, чисто прокладка для устаревших устройств отображения. Не всем приятны дополнительные 20 мс задержек для 60 Гц монитора ценой отсутствия тиринга. А еще vsync при малейшем перегрузе дропает время кадра в N-число раз, вместо просадки до 59 кадров прыгнет сразу на 30, 20, 15, и т.п. Нужны мониторы и протоколы с железом, способным работать от нуля герц, в android смартфонах, если не ошибаюсь, уже были представлены первые такие дисплеи.
Ответить | Правка | К родителю #32 | Наверх | Cообщить модератору

96. "Выпуск Wayland-Protocols 1.32"  +3 +/–
Сообщение от Alladin (?), 05-Июл-23, 03:29 
vsync не нужон?) вот допустим у меня интерфейс в 3000 фпс (ну вот видеокарта моя так могет в 2d..).. ааш монитор отрисует столько? нет? а зачем я трачу ресурсы на 3000 кадров, если мне нужно столько сколько поддерживает мой монитор? (это VSYNC, алилуя..)
Ответить | Правка | Наверх | Cообщить модератору

113. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от Oe (?), 06-Июл-23, 02:59 
Ты уверен, что 60 фпс монитор не может отрисовать больше 60 фпс? При 3000 фпс на 60 фпс мониторе у тебя грубо говоря каждая отрисованная строка на мониторе будет актуальна, а не взятая с отрендериного 20 мс назад кадра. Грубо говоря, 60 Гц монитор может отрисовать половину экрана в 120 Гц, четверть в 240 Гц и так далее. Это ни коим образом не заменяет монитор с большей герцовкой, но дает ощущение меньшей задержки. Или геймеры такие тупые, и просто так лочат фпс на уровне в 2-3 раза выше чем фпс монитора?
Ответить | Правка | Наверх | Cообщить модератору

114. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от n00by (ok), 06-Июл-23, 10:02 
> Ты уверен, что 60 фпс монитор не может отрисовать больше 60 фпс?

Почитайте, как происходит передача кадра по HDMI/DVI, будете так же уверены.

> 60 Гц монитор может отрисовать половину экрана в 120 Гц,
> четверть в 240 Гц и так далее.

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

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

115. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от Oe (?), 06-Июл-23, 20:43 
Если успевать подавать монитору каждую новую строку, а не взятую со статичного кадра, то как раз будут 3000 фпс (между соседними строками). А как с черестрочного 30 Гц видео делается 60 Гц прогрессивное вам тоже не знакомо? А как же роллинг шатер в фотокамерах?
Ответить | Правка | Наверх | Cообщить модератору

118. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от n00by (ok), 07-Июл-23, 07:40 
> Если успевать подавать монитору каждую новую строку, а не взятую со статичного
> кадра, то как раз будут 3000 фпс (между соседними строками).

Куда именно в монитор Вы её подавать собрались, в "вон тот провод"? Монитору требуется знать, в каком месте экрана отображать эту строку. Для чего и служат сигналы кадровой и строчной синхронизации. Без них придётся передавать номера строк, что повлечёт смену формата передачи данных и увеличит их объём.

Ещё раз - читайте описание протокола и в дополнение про VRR (FreeSync и т.п.), что частично решает вопрос с FPS.

> как с черестрочного 30 Гц видео делается 60 Гц прогрессивное вам
> тоже не знакомо?

В отличие от Вас, мне знакомо даже как на бордюре Спектрума рисовать.

> А как же роллинг шатер в фотокамерах?

А это аж два приёма демагогии: "доказательство по аналогии" и "переложить бремя доказательства на оппонента".

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

121. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от Аноним (121), 07-Июл-23, 11:07 
> Если успевать подавать монитору каждую новую строку, а не взятую со статичного
> кадра, то как раз будут 3000 фпс (между соседними строками). А
> как с черестрочного 30 Гц видео делается 60 Гц прогрессивное вам
> тоже не знакомо? А как же роллинг шатер в фотокамерах?

Вы гоните, имхо. Display Controller 60 раз в секунду берет фреймбуфер и начинает синтез протокола и таймингов. В случае CRT это летело в DAC'и. В parallel RGB - DAC'и убрали и данные полетели по проводам как есть (у ряда LCD панелей вот такой интерфейс "нативно"). В комповый монитор 24 или сколько там линий было непрактично тянуть. И туда летит сериализованная версия вот этого. Иногда с разбивкой на 2 lanes (dual-link DVI). HDMI является DVI с одним набором дифференциальных линий и другим разъемом.

LVDS в ноутах примерно то же по смыслу, но электрически эти дифференциальные линии иные чем в DVI/HDMI и lanes может быть более 1-2, вплоть до 4, чтоли. Структура протокола и таймингов однако подразумевает полный кадр, по сути "в стиле CRT". Хоть всякие h/v sync и пустые регионы и не нужны физически, есть определенная польза: во время V-blank самое время заполнить буфер кадра или переключить регион памяти на другой, с подготовленной картинкой ("page flip" при двойной буферизации).

А вот всякие DisplayPort уже несколько более продвинутые штуки. И там в провод летят таки пакеты, но вообще, их тайминги более-менее повторяют вон то. Потому что у LCD такого размера нет своей памяти - и картинка держится лишь потому что ячейка держит заряд до следующего фрейма. Это накладывает определенные лимиты на рефреш "всей площади". Тем не менее эти лимиты не такие уж и жесткие и возможны нестандартные FPS (например старый HDMI можно пюзать как 4K@30FPS вместо 1080p@60FPS) - или даже переменный FPS как это в FreeSync реализовано, чтобы дать GPU закончить рендер фрейма до того как слать его в провод, даже если он и не успевает к фиксированным таймингам. Сие позволяет рисовать без тиринга даже если в тайминги не уложились. Тем не менее, это не доступ к конкретным строкам в любой момент времени.

И кстати у камер интерфейс обычно выдает примерно такой же сигнал с такими же таймингами, только источник и назначение инвертированы. И FPS там как правило подразумевается фиксированный, а скан конкретных строк быстрее чем остального не предусмотрен. FPS может зависеть от разрешения - с одними и теми же фундаментальными таймингами битов передать 320x240 получается быстрее чем 1920x1080 и как таковой FPS в допущении что шина всегда работает без idle может быть выше. В случае дисплеев они обычно работают близко к топовой возможности линка, или же электроники дисплея, но фокусы типа 4K@30FPS намекают что да, это до некоторой степени можно переигрывать. Но ни там ни там нет доступов в конкретные строки, как максимум программируется регион/разрешение, а шина не станет работать быстрее ее характерных таймингов. Ну а rolling shutter как таковой внутреннее дело камеры как оно там реализует сканирование своей матрицы.

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

126. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от Oe (?), 07-Июл-23, 17:08 
Посмотрите пример видео с роллинг шаттером, 30 фпс видео выглядит гораздо плавнее чем 30 фпс без роллинг шаттера, именно из за роллинг шаттера достигается эффект большего фпс, конечно же ценой искажений изображения. С монитором абсолютно те же процессы, тиринг это тот же роллинг шаттер, чем больше фпс выдает видеокарта, тем больше в одном кадре становится разрывов, и эффект всё ближе к роллинг шаттеру. Разница в плавности на 60 Гц мониторе, если отрендерить ему 120 кадров с тирингом - огромна, не заметить её невозможно. Выше 240 Гц уже нету смысла, это уже 4 мс задержка, дальнейшее понижение будет просто незаметно.
Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от Аноним (127), 07-Июл-23, 18:07 
> Посмотрите пример видео с роллинг шаттером, 30 фпс видео выглядит гораздо плавнее
> чем 30 фпс без роллинг шаттера, именно из за роллинг шаттера

В конечном итоге 30 FPS это 30FPS - максимум 30 разных картинок каждую секунду. Они вообще совсем никак не станут 60, или сколько там. Прямо на уровне потока с камеры по щине - идет очередной кадр, строка за строкой, и так пока весь кадр не улетит в провод. Потом начинается новый. И FPS такой какой есть. Как кадр формировался внутри чипа - вопрос номер два, сие может влиять на некоторые артефакты, но добавить число кадров в секунду - это как?

> достигается эффект большего фпс, конечно же ценой искажений изображения.

FPS камеры чаще всего ограничен шиной и потоком данных/таймингами - особенно на жирных матрицах. Можно поменьше картинку и FPS повыше, или побольше картинку и FPS пониже. Выше возможностей шины не прыгнешь. У мониторов однако электроника обычно не готова жрать FPS более энного, заявленного как максимальный/нативный т.к. это еще и тайминги рефреша LCD матрицы заодно, они не могут быть бесконечные. Можно немного придержать эти тайминги в сторону замедления и обычно за это ничего не будет - но это все. А какой нибудь 320x240 хардварно апскейлится в полный размер матрицы, хоть там как, и тот лимит в силе.

> С монитором абсолютно те же процессы, тиринг это тот же роллинг шаттер,

Тиринг - это когда вы слали буфер кадра в провод, по вон тем таймингам, и тут в процессе действа в буфер прилетела новая картинка. Так что в провод улетела половина старого и половина нового кадра. Возможны разные варианты, в зависимости от скорости writer'а vs скорость scanout. Может как writer обогнать отрисовку, так и отрисовка обогнать writer'а. В обоих случаях в провод летит часть старого и часть нового кадра.

Есть технологии достаточно радикально лечащие это, скажем page flip. Это когда буферов два, и writer рисует в неактивный буфер, а железка рисует активный. Потом - как правило в V-blank драйвер переключает указатель на фреймбуфер железке, и та рисует из второго буфера. А первый отдается writer'у. Недостатками является повышенный лаг и нужда чтобы софт который writer мог в достаточно прецизионные тайминги - с чем у иксов до сих пор проблемы, они под такое не делались.

> чем больше фпс выдает видеокарта, тем больше в одном кадре становится разрывов,

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

> и эффект всё ближе к роллинг шаттеру. Разница в плавности на
> 60 Гц мониторе, если отрендерить ему 120 кадров с тирингом -
> огромна, не заметить её невозможно. Выше 240 Гц уже нету смысла,
> это уже 4 мс задержка, дальнейшее понижение будет просто незаметно.

А таки FPS хотят лишь потому что движки ввод и сеть обрабатывают с привязкой к времянкам кадров. Это не очень умное и эффективное решение но переделывать кучу движков никто не хочет. Это обрекает желающих FPS выше мониторного на тиринг. Ну как, если writer догоняет и обгоняет scanout?

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

120. "Выпуск Wayland-Protocols 1.32"  +/–
Сообщение от Аноним (-), 07-Июл-23, 10:40 
> Не может. А вот экранный буфер видеокарты может измениться в неподходящий момент
> в процессе передачи информации о кадре. Отсюда и дефекты изображения ("тиринг"),
> когда на экран попадают части от разных кадров.

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

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

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

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

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




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

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