Comments 48
Без этой платы мониторы разрывает?
Неправильные у них картинки. В нормально написанной игре цикл Draw начинается сразу после предыдущего цикла. Нет никакого Lag.
Просто рисуется картинка в другой буфер, пока предыдущий ждет, когда его покажут. Конечно, если у нас цикл Draw систематически не успевает отрисовываться за время Scan, то будут пропуски кадров. Ну так GSync от этого не спасет — Scanы будут идти реже и получится слайдшоу, только не в видеокарте а уже на мониторе.
Оно должно помогать с плавающей частотой кадров, которая должна быть всегда выше 25 к/с. Т.е. монитор будет адаптироваться под скорость отрисовки видеокарты.
И увидеть эффект реально можно только глазами, потому что видео с фиксированной частотой кадров его не передаст.
Просто рисуется картинка в другой буфер, пока предыдущий ждет, когда его покажут. Конечно, если у нас цикл Draw систематически не успевает отрисовываться за время Scan, то будут пропуски кадров. Ну так GSync от этого не спасет — Scanы будут идти реже и получится слайдшоу, только не в видеокарте а уже на мониторе.
Оно должно помогать с плавающей частотой кадров, которая должна быть всегда выше 25 к/с. Т.е. монитор будет адаптироваться под скорость отрисовки видеокарты.
И увидеть эффект реально можно только глазами, потому что видео с фиксированной частотой кадров его не передаст.
Использую lightboost + 120 Гц дома, но у этого подхода есть свои минусы. Если эта технология позволить плавно выводить изображение, как старенькие ЭЛТ со 120 герц(или больше) и full-hd разрешении — это замечательно.
То, что убирает input lag — тоже очень хорошо.
Посмотрим, что из этого выйдет.
То, что убирает input lag — тоже очень хорошо.
Посмотрим, что из этого выйдет.
А какие минусы у подхода с lightboost?
Искажение цвета, невозможность повлиять на яркость/контраст (оно просто заблокировано, но, теоретически, можно воспользоваться DDC/CI для изменения этих параметров, однако, я думаю, это все равно не сработает (пробовал на linux, тут криво реализован DDC/CI в ddccontrol, а других утилит не нашел, да и ту пришлось допиливать, чтобы скомпилилась и работала)).
Для мониторов даже специальные цветовые профили выкладывают, чтобы все выглядело хотя бы чуточку получше, плюс, в последние месяцы вышел обновленный драйвер NVIDIA и цвета стали еще хуже на Benq XL2411T.
И еще — самый главный и противный для меня минус — невозможность активации lightboost в Linux без участия Windows, т.е. обязательно должна стоять винда с нормально установленными драйверами, чтобы с ней потрахаться и выставить lightboost, да еще и монитор потом нельзя выключать, иначе все сброситься. Но я эту проблему поборол установкой винды в VHD на портативный винчестер и установкой пропатченного grub4dos для восприятия хитрых виндовых VHD-образов и загрузки в них.
Короче, чтобы активировать lightboost на Linux — нужно потратить кучу сил, на винде все проще. Плюс потом еще с цветами ковыряйся.
Для мониторов даже специальные цветовые профили выкладывают, чтобы все выглядело хотя бы чуточку получше, плюс, в последние месяцы вышел обновленный драйвер NVIDIA и цвета стали еще хуже на Benq XL2411T.
И еще — самый главный и противный для меня минус — невозможность активации lightboost в Linux без участия Windows, т.е. обязательно должна стоять винда с нормально установленными драйверами, чтобы с ней потрахаться и выставить lightboost, да еще и монитор потом нельзя выключать, иначе все сброситься. Но я эту проблему поборол установкой винды в VHD на портативный винчестер и установкой пропатченного grub4dos для восприятия хитрых виндовых VHD-образов и загрузки в них.
Короче, чтобы активировать lightboost на Linux — нужно потратить кучу сил, на винде все проще. Плюс потом еще с цветами ковыряйся.
Минус в том, что начало нового кадра вы увидите несколько позже (на 1-3-5мс позже).
Обычный монитор начнет меееедленно переключать пиксель, и вы сразу будете видеть этот процесс.
С lightboost вы увидите изображение только тогда, когда пиксель полностью переключился.
Обычный монитор начнет меееедленно переключать пиксель, и вы сразу будете видеть этот процесс.
С lightboost вы увидите изображение только тогда, когда пиксель полностью переключился.
Интересно, будут ли ATI выпускать аналог. И будет ли в таком случае в каждом мониторе по два чипа от каждой.
Насколько я понимаю это не проблема именно ЖК панелей как таковых?
На плазме тоже встречаетсяразрывы тиринг, и, боюсь соврать, но на ЭЛТ тоже вроде было, не помню уже.
Input lag кстати либо отсутствует, либо совсем не заметен на старых играх сейчас, с включённым v-sync. Т.е. по сути он упирается в вычислительные мощности.
Поправьте если где не прав, мог всё нарвать. =))
На плазме тоже встречается
Input lag кстати либо отсутствует, либо совсем не заметен на старых играх сейчас, с включённым v-sync. Т.е. по сути он упирается в вычислительные мощности.
Поправьте если где не прав, мог всё нарвать. =))
Тут еще не написали что это работает только через DisplayPort, потому что он поддерживает пакетную передачу данных.
Если хорошо пойдет им просто нужно расширить стандарт и сделать стандартную фишку — Variable Frame Rate (VFR).
Если хорошо пойдет им просто нужно расширить стандарт и сделать стандартную фишку — Variable Frame Rate (VFR).
Вроде как давно уже придумали «Triple Buffering» именно для этой цели?
У тройной буферизации огромнейший инпут лаг.
Буферизация служит для того, чтобы минимизировать простой видеокарты когда один кадр уже готов, а другой еще отправляется. Но разрывов не возникает только в случае применения вертикальной синхронизации, иначе же буферы переключаются прямо на лету, как только очередной кадр отрисован, а отрисован он может быть когда угодно.
Мне кажется, что это решение nVidia порочно по своей сути. При неравномерном во времени обновлении экрана о плавной (как на телевизоре) анимации мечтать не приходится.
Что же касается опции V-sync Off и связанным с ней эффектом разрыва — то это вообще пережиток прошлого, когда значительная часть программистов не понимала принципов формирования изображения на мониторе. В этот период как раз и возник термин «FPS», который будто бы чем больше — тем лучше. А на самом деле задача состоит всего лишь в том, чтобы обновлять изображение раз в кадр. Не чаще, но и не реже.
Что же касается лагов — то последние разработки Microsoft и производителей видеокарт только усугубляют ситуацию с ними. Взять хотя бы принудительную буферизацию перед отображением. То изображение, которое было сформировано программой в BackBuffer, появляется на экране не в следующем кадре, а через 3-4 кадра. Проверялось с помощью фотодиода и осциллографа. Только в Direct3D9Ex появляется функция SetMaximumFrameLatency, которая может отключить эту принудительную буферизацию.
Что же касается опции V-sync Off и связанным с ней эффектом разрыва — то это вообще пережиток прошлого, когда значительная часть программистов не понимала принципов формирования изображения на мониторе. В этот период как раз и возник термин «FPS», который будто бы чем больше — тем лучше. А на самом деле задача состоит всего лишь в том, чтобы обновлять изображение раз в кадр. Не чаще, но и не реже.
Что же касается лагов — то последние разработки Microsoft и производителей видеокарт только усугубляют ситуацию с ними. Взять хотя бы принудительную буферизацию перед отображением. То изображение, которое было сформировано программой в BackBuffer, появляется на экране не в следующем кадре, а через 3-4 кадра. Проверялось с помощью фотодиода и осциллографа. Только в Direct3D9Ex появляется функция SetMaximumFrameLatency, которая может отключить эту принудительную буферизацию.
Будет плавно, если между кадрами будет не более 40мс и анимация будет рисоваться по времени, а не по кадрам.
Насчет, что достаточно обновления раз в кадр — согласен. Однако кадров может быть 30 за секунду, а может быть 60. При этом 60 выглядит плавнее чем 30, хотя теория говорит, что 25 достаточно. Вот тут мне не совсем понятно.
С другой стороны в играх все время меняется сложность сцен это приводит к разному времени отрисовки кадров. Если монитор будет подстраиваться под карту, то можно будет получить более плавное отображение на слабом железе ну или увеличить сложность сцен для сильного железа.
Насчет, что достаточно обновления раз в кадр — согласен. Однако кадров может быть 30 за секунду, а может быть 60. При этом 60 выглядит плавнее чем 30, хотя теория говорит, что 25 достаточно. Вот тут мне не совсем понятно.
С другой стороны в играх все время меняется сложность сцен это приводит к разному времени отрисовки кадров. Если монитор будет подстраиваться под карту, то можно будет получить более плавное отображение на слабом железе ну или увеличить сложность сцен для сильного железа.
UFO just landed and posted this here
> Теория говорит, 25 кадров нужно, чтобы движение казалось непрерывным.
Это справедливо для кино, где резкие движения естественным образом размывает выдержка, и анимации, где быстро движущиеся предметы специально рисуют размытыми. Motion blur всего мира в реальном времени пока что недостижим, поэтому плавности добиваются высоким количеством кадров.
Это справедливо для кино, где резкие движения естественным образом размывает выдержка, и анимации, где быстро движущиеся предметы специально рисуют размытыми. Motion blur всего мира в реальном времени пока что недостижим, поэтому плавности добиваются высоким количеством кадров.
Теория говорит про 16 кадров для непрерывности, IIRC.
Глупая теория, на мой взгляд. Вообще, то, насколько последовательность кадров кажется непрерывной зависит от многих факторов, в том числе: телесный угол, размер объекта, движущегося в кадре, насколько он яркий, психофизического состояния наблюдателя и прочее. Поясню на примерах. Возьмите видео, где есть динамичные сцены, и изображение местами подтормаживает. Это если Вы его смотрите на телевизоре 42 дюйма на расстоянии 1 метр. Закачайте его на смартфон и посмотрите то же видео на расстоянии вытянутой руки. Никаких прерываний! По поводу размера объекта. Если снимать даже очень шустрого мастера рукопашного боя неподвижной камерой, причём так, что он полностью умещается в кадре, а не закрывает своим телом весь обзор, то картинка будет смотреться довольно плавно. Но попробуйте произвести панорамную съёмку даже со штатива, то рывки кадров будут видны очень отчётливо.
Я вообще не понимаю зачем в матрице есть понятие развертки. По-идее она должна обновляться по команде из вне, причем не обязательно даже вся целиком. И даже не обязательно сверху вниз, можно как-нибудь в шахматном порядке, чтобы сгладить все эти разрывы и рывки при обновлении экрана.
Почему это все не заложили сразу при проектировании всяких HDMI — не ясно.
Почему это все не заложили сразу при проектировании всяких HDMI — не ясно.
Ну такое уже было — называется «черезстрочная» развертка. :-)
А вообще наверно к этому придут — что то вроде loseless MPEG4 передавать в монитор сразу, а он пусть себе в буфер экрана прямо его разворачивает без промежуточного буфера. Только наверно это усложнит конструкцию буфера — там же надо как то лочить пиксели на запись пока «не знаю как это будет называться» читает значение цвета пикселя чтобы подать напряжение на ячейку в матрице.
А вообще наверно к этому придут — что то вроде loseless MPEG4 передавать в монитор сразу, а он пусть себе в буфер экрана прямо его разворачивает без промежуточного буфера. Только наверно это усложнит конструкцию буфера — там же надо как то лочить пиксели на запись пока «не знаю как это будет называться» читает значение цвета пикселя чтобы подать напряжение на ячейку в матрице.
Насколько знаю, матрица и так обновляется «извне», сначала приходящий по интерфейсу кадр пишется в буфер, затем, после сигнала развертки, изображение отображается на матрице за небольшую долю межкадрового интервала. Тиринг возникает еще при передаче.
> «разрывы кадров… проблема LCD мониторов по сравнению с CRT»
Это неверно. CRT точно так же страдает от «разрыва кадров».
Помню, ещё на бейсике в школе делал «игры», и делали «wait for retrace»: WAIT &H3DA, 8
По-русски ещё говорили «ждать обратного хода луча».
Это неверно. CRT точно так же страдает от «разрыва кадров».
Помню, ещё на бейсике в школе делал «игры», и делали «wait for retrace»: WAIT &H3DA, 8
По-русски ещё говорили «ждать обратного хода луча».
Одного не понимаю, что если производительность просядет до 15 кадров, монитор с этой системой начнет заметно для глаза мерцать?
Меня сильно смущает картинка с иллюстрацией моушен-блюра на lcd.
Смазывание картинки равномерное, без разрывов. Значит объект двигался равномерно. На глазок, смазывание занимает около 25 пикселей. С учетом того, что частота смены кадров заявлена в 60Гц, то время затухания пикселя выходит ~ 400 мс. Что это за антикварная матрица такая?
Нас пытаются на@#ать или это я где-то в расчетах ошибся?
Заголовок
Вот эта, если что
Смазывание картинки равномерное, без разрывов. Значит объект двигался равномерно. На глазок, смазывание занимает около 25 пикселей. С учетом того, что частота смены кадров заявлена в 60Гц, то время затухания пикселя выходит ~ 400 мс. Что это за антикварная матрица такая?
Нас пытаются на@#ать или это я где-то в расчетах ошибся?
Тут подробнее об этом сравнении и методе измерения.
(мимо)
для работы G-Sync будет необходима видеокарта с архитектурой Kepler (GTX 660 и выше).
Что, наконец-то починят рваное видео на линуксах. Не прошло и десяти лет.
Но блин, пару недель назад только взял dell u2713h. Эх.
В гноме 3 лечится легко. Твикнуть немного Clutter и красота. И игры и видео теперь без тиринга.
… для работы G-Sync будет необходима видеокарта с архитектурой Kepler (GTX 660 и выше).
Какой замечательный маркетинг. А монитору не по фиг, какая к нему видеокарта подключена?
Какой замечательный маркетинг. А монитору не по фиг, какая к нему видеокарта подключена?
Ну надо же как то новые линейки продукции продвигать. Теперь им остается только заключить какой-нибудь хитрый договор с Intel и для работы G-Sync будет также станет необходим процессор не ниже Intel i7…
В мониторе будет встроена плата, которая будет работать напрямую с видеокартой. Подозреваю, что только 660 и новее будут уметь работать с этой платой.
А тем временем пока данное изобретение не попало на рынок, можно улучшить ситуацию своими силами.
Вот одно из решений.
Кто может порекомендовать более всеобъемлющий гайд — велкам.!
Кстати, кто пробовал adaptive Vsync?
Вот одно из решений.
Кто может порекомендовать более всеобъемлющий гайд — велкам.!
Кстати, кто пробовал adaptive Vsync?
А как происходит отрисовка нового кадра?
Почему вообще смаз происходит, а не выпадание кадров или частей кадра?
В крайнем случае возможно наложение двух кадров из-за ограниченной скорости реакции, но не плавный смаз.
Почему вообще смаз происходит, а не выпадание кадров или частей кадра?
В крайнем случае возможно наложение двух кадров из-за ограниченной скорости реакции, но не плавный смаз.
Лучше бы изобрели адаптивный рендеринг, который всегда любой ценой поддерживает вывод 60fps, в сложных местах автоматически снижая качество картинки (меньше полигонов или поменьше текстура).
Sign up to leave a comment.
Nvidia представила технологию G-Sync: плата, встраиваемая в мониторы, должна избавить их от разрыва и пропуска кадров