какая должна быть задержка рендеринга в играх

Input lag во время рендеринга и как его побеждать

Привет всем. Многие из вас знакомы с лагом ввода. Это бывает, когда вас в очередной раз убивают в компьютерной игре, и вы кричите: «Ну я же нажал блок/атаку/уворот». Ну а затем джойстик летит в стену. Знакомо? Происходит это потому, что между нажатием клавиш и появлением результата на экране проходит значительное время. Фактически, когда вы смотрите в экран — вы видите прошлое состояние, которое может абсолютно не отражать действительность.

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

Итак, Input lag в любой игре складывается из:

CPU + GPU

Современные GPU — устройства максимально асинхронные. CPU отдает команды видеодрайверу, и идет заниматься своими делами. Драйвер накапливает команды в пачки, и пачками отправляет на видеокарту. Видеокарта рисует, а CPU в это время занимается своими делами. Максимальный FPS, который вы можете получить в этой системе ограничен одним из условий:

1. CPU не успевает отдавать команды видеокарте, потому что видеокарта очень быстро рисует. И нафига вы покупали такую мощную видеокарту?

2. Видеокарта не успевает рисовать то, что дает ей CPU. Теперь CPU халявит…

Для того, чтобы посмотреть, как красиво в паре работает CPU и GPU — есть различные профайлеры. Мы воспользуемся GPUView, который идет в составе Windows Performance Toolkit.

Лог от GPUView может выглядеть как-то так:

Вертикальные синие линии — это VSync. Наваленные горы кубиков — это горы пакетов, которые отправятся на видеокарту, когда та освободится. Штрихованный кубик — это пакет, содержащий переключение буферов. Иными словами — конец кадра. Любой кубик можно выбрать, и видеть, как он постепенно опускается в стопке, и отправляется на видеокарту. Видите на скриншоте кубик с желтой обводкой? Он обрабатывался аж на протяжении 3-х vsync-ов. А целый кадр занимает около 4-х VSync-ов (судя по расстоянию между разными штрихованными кубиками). Между двумя горами пакетов от разных кадров есть маленький зазор. Это то время, пока GPU отдыхал. Этот зазор маленький, и оптимизация на стороне CPU не даст большого выйгрыша.

Но бывают зазоры большие:

Это пример рендера из World of Warcraft. Расстояния между пакетами в очереди просто огромные. Более мощная видеокарта не даст прироста ни одного FPS. Зато если оптимизировать рендер на стороне CPU, то можно получить более чем двукратный прирост FPS на данном GPU.

Чуть более подробно можно почитать тут, а мы пойдем дальше.

Так где же лаг?

Так уж сложилось, что разрыв в производительности между Hi-End и Low-End видеокартами поистине огромен. Поэтому у вас обязательно будут возникать обе ситуации. Но самая грустная ситуация — это когда GPU не справляется. Выглядеть это начинает вот так:

Обратите внимание, сколько времени заняла обработка одного пакета. Кадр занимает 4 VSync-а, а обработка пакета занимает в 4 раза дольше! DirectX (OpenGL ведет себя так же) накапливает данных аж на 3 кадра. Но ведь когда мы кладем в очередь свежий кадр — все предыдущие кадры для нас уже не актуальны, а видеокарта по прежнему будет тратить время на отрисовку. Поэтому наше действие появится на экране спустя аж 3 кадра. Давайте посмотрим, что мы можем сделать.

1. Честное решение. IDXGIDevice1::SetMaximumFrameLatency(1)

Я честно, не представляю зачем копить данных на 3 кадра в буфере. Но MS видимо поняла ошибку, и начиная с DX10.1 у нас появилась возможность задать это количество кадров через специальный метод IDXGIDevice1::SetMaximumFrameLatency. Давайте посмотрим, как нам это поможет:

Ну что же. Стало значительно лучше. Но по прежнему не идеально, т.к. все равно ждем 2 кадра. Еще один недостаток решения — то что оно работает только для DirectX.

2. Трюк с ID3D11Query

Идея заключается в том, что в конце кадра мы устанавливаем D3D11_QUERY_EVENT. В начале следующего кадра — ждем, постоянно проверяя событие, и если оно прошло, то только тогда начинаем отдавать команды на отрисовку, и с наисвежайшими Input данными.

Картина практически идеальная, не находите? Ожидание я реализовал вот так:

Установка эвента тривиальна:

Ну и в сам рендер добавляем вначале ожидание. Затем перед самой отрисовкой собираем свежие Input данные, а перед самым Present-ом устанавливаем евент:

Недостаток костыля метода — работает только с DirectX. Но можно дождаться синхронизации другим оригинальным способом.

3. Воркэраунд через текстуру

Вот что мы делаем. У нас есть механизмы прочитать данные из видеоресурсов. Если мы заставим видеокарту что-то нарисовать, а потом попытаемся забрать, то произойдет автоматическая синхронизация между GPU-CPU. Мы не сможем забрать данные раньше, чем они будут нарисованы. Поэтому вместо установки евента я предлагаю генерить мипы на видеокарте для текстуры 2*2, а вместо ожидания евента — забирать данные из этой текстуры в системную память. В результате подход выглядит так:

Вот так мы ожидаем евент:

а вот так его устанавливаем:

В остальном подход полностью аналогичен предыдущему. Преимущество: работает не только на DirectX но и на OpenGL. Недостаток — маааленький оверхед на генерацию текстуры и передачу данных назад + потенциально потраченное время на «пробуждение» потока шедулером операционной системы.

Про попробовать

Конечно я тут растекался по дереву… но насколько проблема серьезная? Как пощупать это? Я написал специальную демонстрационную программу (требует DirectX11).

Скачать *.exe можно здесь. Для тех, кто боится качать билды неизвестного производителя — исходный код lazarus проекта здесь (также потребуется моя библиотека фреймворк AvalancheProject, которая находится вот тут)

Программа представляет собой такое окно:

Тут рисуется 40*40*40=64000 (кстати каждый кубик — отдельный дравколл). GPU workload трекбар дает нагрузку на GPU (с помощью бесполезного цикла в вершинном шейдере). Просто опускаете с помощью этого трекбара фпс до низкого уровня, скажем 10-20, а потом пробуете правой кнопкой мыши крутить кубики, и переключать методы уменьшения Input лага с помощью радиобаттонов.

Вы только оцените какая огромная разница в скорости отклика. C Query Event комфортно крутить кубик даже при 20 фпс.

Источник

О режиме низкой задержки nVidia и Radeon Anti-Lag

Предисловие

В конце прошлого года я перешел с R9 290 на GTX 1070, именно тогда еще я заметил неприятные последствия такого перехода в лице увеличившихся задержек.

реклама

Сейчас я не обладаю R9 290, но у меня есть в наличии RX 560, она не настолько производительная как R9 290, и далека от GTX 1070 в плане производительности, тесты могут не отражать ситуацию между R9 290 и GTX 1070, но почему бы и нет.

В данной статье я проведу сравнение таких настроек в драйвере как “режим низкой задержки” от nVidia и “Anti-Lag” от AMD.

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

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

реклама

В итоге я нашел ближайший драйвер версии 431.60 на сторонних ресурсах, в этой версии драйвера еще не должно быть “режима низкой задержки”.

По информации на сайте AMD технология Anti-Lag совместима с DirectX 9, DirectX 11 и DirectX 12, для “режима низкой задержки” от nVidia я не нашел информации на официальном сайте (недостаточно хорошо гуглил?), но сторонние ресурсы говорят о поддержке DirectX 9 и DirectX 11.

Условия

Видеокарты будут работать в стоке, как есть с завода.

реклама

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

1.3 GHz в играх
nVidia:
MSI GeForce GTX 1070 AERO OC 8 GB 8-Pin

1.8 GHz в играхИгры, участвующие в сравнении*** (Steam)1) 7 Days to die (Alpha 19.3) (Unity, DX11)
2) CS:GO (Source, DX9)
3) Destiny 2 (Tiger Engine, DX11)Процессор

Разгон через P-State, частота зафиксирована на максимальной планом электропитания Windows.ОЗУ Samsung M378A1G43TB1-CTD
3400 MHz Dual-Channel Dual-Ranks CL18
Дополнительное охлаждение турбиной.***Destiny 2 имеет аномальную зависимость от процессора в паре с видеокартами AMD, однако несмотря на “кривую” работу игры она войдет в сравнение.

Запись видео:

Чтобы правильно определять задержки, было решено перепроверить фотокамеру, на всякий случай т.к. она пишет файл с частотой 29.970 (30000/1001) FPS.

Я сделал запись таймера в формате 320 FPS и разложил одну секунду таймера в виде jpg файлов, и у меня вышло 324 файла (4 файла погрешность из-за ручного выделения фрагмента видео), в итоге производитель камеры не обманул, один кадр имеет длительность 3.125ms.

реклама

Дополнительно смастерил насадку на объектив камеры для увеличения угла обзора, таким образом лучше видно, что происходит в целом.

Подробности ОЗУ-ЦП:

Драйвера:

У меня уже установлены старые драйвера как для AMD так и для nVidia, потому я переустановлю их используя стандартные средства, что предлагает установщик.

Устанавливаю галочку восстановления заводских настроек, одна перезагрузка и готово.

Первое что меня встречает:

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

nVidia:

Я забыл сделать скриншот окна установщика драйвера с галочкой чистой установки, и хотел запустить чисто ради скриншота, но я обнаружил что папки драйвера версии 461.92 нет в “C:\NVIDIA\DisplayDriver\”, похоже nVidia теперь подчищает за собой папку распакованного драйвера.

Но это не проблема, распространяемый файл можно снова распаковать и сделать заветный скриншот:

После закрытия установщика драйвера папка сама исчезла снова, все же это дело в установочном пакете драйвера, правда непонятно зачем это нужно было делать, что если мне нужно будет менять версию драйвера или откатывать назад? Каждый раз делать распаковку с нуля?

Интересующая настройка присутствует в классической контрольной панели драйвера, по умолчанию настройка отключена, быстрое изменение настройки невозможно:

В драйвере версии 431.60 я не обнаружил “режим низкой задержки”, однако обнаружил настройку “максимальное количество заранее подготовленных кадров”, судя по описанию эту настройку переименовали в “режим низкой задержки” и выдали за уникальную функцию.

Можно выбрать значения от 1 до 4, но по умолчанию установлено “использовать настройку 3D-приложения”, влияние этой настройки я тоже проверю.

Результаты nVidia (431.60)

7 Days to die (Alpha 19.3) (Unity engine actual)

CS:GO (Source)

Destiny 2 (Tiger Engine)

Результаты nVidia (461.92)

7 Days to die (Alpha 19.3) (Unity engine actual)

CS:GO (Source)

Destiny 2 (Tiger Engine)

Результаты AMD (21.3.1)

7 Days to die (Alpha 19.3) (Unity engine actual)

CS:GO (Source)

Destiny 2 (Tiger Engine)

Сравнение

Результаты в другом виде:

Итоги

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

Игры я выбирал по принципу “что под рукой было”, но старался на разных игровых движках выбрать, конечно, мою бывшую R9 290 было бы намного объективнее использовать, она незначительно слабее чем GTX 1070 в отличие от RX 560, но что есть, то есть.

7 Days to die (Unity): Можно сказать моя основная игра, именно в ней я почувствовал увеличившиеся задержки после перехода с R9 290 на GTX 1070, однако даже слабая RX 560 показала разницу в пользу AMD.

Игра определенно использует очереди кадров.

CS:GO (Source): Разница мала, можно сказать на грани погрешности, но она в пользу nVidia, возможно с R9 290 вместо RX 560 были бы изменения в пользу AMD, но об этом уже сказано выше, игра вероятно использует очереди кадров.

Destiny 2 (Tiger Engine): Игра очевидно ограничивает очередь кадров, однако я заметил невероятную любовь к nVidia у данной игры, и необъяснимую зависимость от процессора если установлена видеокарта от AMD, по слухам, на форуме Bungie игнорируют и даже банят темы касающиеся этого нюанса (есть что скрывать?).

В любом случае игра выглядит крайне подозрительно, причем она не позволяет использовать оверлеи MSI Afterburner и прочие для вывода информации.

nVidia (431.60): Настройка “Максимальное количество подготовленных кадров” действительно работает, и предоставляет приложениям выбор длинны очереди кадров по умолчанию, я не стал перебирать все 4 варианта настройки, это сильно усложнит всё.

nVidia (461.92): Очевидно что nVidia переименовала настройку “Максимальное количество подготовленных кадров” в более презентабельную “Режим низкой задержки” и выдала это как инновацию что ли, но при этом урезали контроль над этой настройкой, нельзя выбрать конкретно от 1 до 4 кадров.

Еще было обнаружено, что для CS:GO очередь кадров была ограничена до 1, никаких изменений от разных значений режима низкой задержки, как это было в старом драйвере, т.е. настройка есть, но она стала бесполезной в данной игре.

Судя по 7 Days to die и Destiny 2 очевидно nVidia поработали над общим снижением задержек относительно старого драйвера, как с ограничениями очереди кадров так и без, но это не касается CS:GO, минимальный порог остался одинаков.

Еще отмечу что с драйвером 461.60 счетчик FPS (Steam оверлей стандартный) показывал уверенно меньше чем с драйвером 431.60, хотя разница незначительна (всего 2-3фпс), но FPS практически не изменялся при изменении настроек очереди кадров (режим низкой задержки) и Anti-Lag.

AMD (21.3.1): В случае 7 Days to die Radeon Anti-Lag показал хорошие результаты, хотя и без него задержки оказались ниже чем у nVidia несмотря на слабую RX 560.

Но в случае CS:GO разница уже не так значительна, с отключенным Anti-Lag ситуация схожа со старым драйвером nVidia.

Другое дело Destiny 2, которая неадекватно работает на системах с видеокартами от AMD, однако здесь есть разница от работы Anti-Lag, поведение похоже на старый драйвер nVidia, но задержки в целом оказались между старым и новым драйвером nVidia.

Хотя AMD и не везде показала хорошие результаты в плане снижения задержек, но возможность изменять Anti-Lag (и другие параметры) прямо во время игры это весьма полезно, nVidia на такое не способна, и это факт.

Но Radeon Boost и прочие настройки пожалуй оставлю в покое на данный момент, статья не про них, хотя они и относятся к теме.

Источник

Какой fps вам нужен?

Современный геймер очень часто наслышан о существовании такого понятия как fps (“frames per second”/кадров в секунду), но недостаточно хорошо разбирается в том как частота кадров влияет на игровой процесс.

Действительно ли оправдана неограниченно высокая частота кадров? Есть ли смысл в том, чтобы она превышала частоту обновления монитора?

Портал Techspot попытался разобраться и получить ответ на этот, несомненно насущный, вопрос.

Подробнее о частоте кадров

С такой разницей в скорости рендера отдельных кадров, возникает разброс и в отправке отрендеренных кадров на монитор. Кадр попадает на дисплей как только полностью отрендерится при выключенной вертикальной синхронизации, а при включённой синхронизации дисплей сначала полностью обновляется и лишь потом отправляет новый кадр.

Выключенная вертикальная синхронизация, “Vsync off”

Разрывы

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

Включённая вертикальная синхронизация, “Vsync on”

Подробнее о включенной вертикальной синхронизации

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

Если видеокарта не успевает отрендерить кадр… все тормозит

Включенная вертикальная синхронизация на 60 Гц-дисплее при 200 кадрах в секунду

Теперь перейдем ко второй проблеме, которая проявляется, если ваша видеокарта, наоборот, очень быстрая и может рендерить кадры со скоростью большей, чем частота обновления монитора. Скажем, карта может выдать 200 кадров в секунду, тем самым выдавая по кадру каждые 5 мс, если, конечно, у вас не 60 Гц дисплей с “окном” обновления в 16.7 мс.

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

А вот тут и начинается путаница.

Это рассуждения довольно логичны и отчасти правдивы, но лишь отчасти. А всё потому, что при этом не учитывается время обработки команд и то, сколько времени нужно для их отображения на дисплее.

Включенная синхронизация и команды

Чтобы объяснить, что при этом происходит, давайте рассмотрим диаграмму синхронизации, на которую наложим диаграмму команд, поступающих с клавиатуры и мыши (обычно записываются каждую 1 мс). И давайте снова обратимся к примеру, в котором наша видеокарта может рендерить 200 кадров в секунду,а частота обновления дисплея составляет 60 Гц.

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

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

Даже в самом лучшем случае у нас будет задержка, как минимум, в 16.7 мс между введёнными командами и отображением результатов этих команд на дисплее.

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

Выключенная вертикальная синхронизация с командами, дисплей 60 Гц, 200 кадров в секунду

И вот так вы сможете получить преимущество. В данном случае, при игре на 200 кадрах в секунду, выключенная вертикальная синхронизация на 60-герцовом мониторе, даст результат задержки ввода всего лишь в 5 мс, а с включённой синхронизацией эта задержка достигнет 16.7 мс, если не больше.

Пусть дисплей и не в состоянии отобразить все 200 кадров в секунду, он отображает команды ближе ко времени к заявленным 1/60 секунды, необходимым для их записи.

Этот феномен, разумеется, применим и к мониторам с высокой частотой обновления дисплея. На 144 Гц, например, вы сможете увидеть намного больше кадров в секунду, а следовательно, игра на них в целом будет более плавной. И даже на подобном мониторе, 200 кадров в секунду с выключенной вертикальной синхронизацией обеспечат вам 5 мс отклика ввода вместо 7 мс, которые вас ждут при включенной синхронизации.

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

В обоих случаях на дисплее новый кадр будет появляться 60 раз в секунду, однако на мониторах с частотой 144 Гц или 240 Гц игра будет казаться плавнее. Стоит отметить, что разница в задержке ввода команд огромная: на 400 кадрах в секунду задержка в 7 раз ниже. Протестируйте эти мониторы сами и вы гарантированно заметите разницу.

Fast Sync создаёт дополнительный буфер для вертикальной синхронизации под названием “последний отрендеренный буфер”. Это позволяет видеокарте продолжать рендерить новые кадры, которые будут попадать в него по мере готовности. Затем, во время обновления дисплея, последний отрендеренный буфер перемещается в передний буфер, к которому у дисплея есть доступ.

Fast Sync / Enhanced Sync

Главный козырь данных технологий заключается в том, что видеокарта больше не простаивает после рендера нового кадра в ожидании обновления дисплея, как это происходит в случае с включённой вертикальной синхронизацией. Вместо этого карта беспрерывно продолжает рендерить, в результате чего новые кадры выходят ближе к началу цикла обновления. Так уменьшается задержка ввода. Однако, отличие от выключенной вертикальной синхронизации, Fast Sync отправляет законченный кадр на дисплей в начале каждого цикла, вместо отправки кадра на дисплей сразу же, из-за чего исчезает проблема разрыва кадров.

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

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

Источник