Время кадра: Показатели игровой производительности — что такое средний, 1% и 0.1% низкие FPS — Главная

Содержание

Показатели игровой производительности — что такое средний, 1% и 0.1% низкие FPS

Этот материал написан посетителем сайта, и за него начислено вознаграждение.

За последние годы можно наблюдать всё растущее понимание, что одного только среднего FPS по какой-либо выбранной для целей тестирования игровой сцене недостаточно для описания производительности компьютерной системы, а минимальный и максимальный FPS в этом деле совсем не помощники. Давайте разберёмся, в чём недостаток среднего FPS, чем так плох минимальный FPS, а также познакомимся с набравшими популярность более удачными мерилами игровой производительности — показателями 1% и 0.1% низкие FPS.

Кадр из ролика What Are 1% & 0.1% Lows? канала Gamers Nexus

Время кадра, мгновенный и средний FPS

Отрисовка каждого кадра в игре занимает некоторое время, которое называется, временем отрисовки кадра, или, коротко, временем кадра (frame time). Исчисляется время кадра обычно в миллисекундах (мс), т.е. тысячных долях секунды. Однако в игровых бенчмарках вместо этой характеристики много чаще используется частота смены кадров или, коротко, частота кадров (frame rate), равная количеству кадров, отрисованных за единицу времени. Измеряется частота кадров в количестве кадров в секунду (frames per second, fps), и для краткости частоту кадров также очень часто также именуют аббревиатурой от названия её единицы измерения, т.е. FPS.

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

рекомендации

Необходимо только учесть, что время кадра обычно исчисляется в миллисекундах, а частота кадров в единицах в секунду, поэтому итоговая формула для мгновенного FPS будет такова:

Так, например, если очередной кадр был отрисован, скажем, за 16 мс, то сразу по окончании его отрисовки мгновенный FPS был равен 1000/16 = 62. 5 кадра в секунду.

Но главное мерило производительности, это, конечно же, средний FPS по всей игровой сцене, который с одной стороны представляет собой не что иное, как количество кадров n, отрисованных за всё время бенчмарка t

С другой же стороны, средний FPS можно вычислить как величину, обратную среднему времени кадра

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

Впрочем, всё это, в каком-то смысле, очевидно. А вот что совсем не так очевидно, так это то, что средний FPS не является средним арифметическим значений мгновенного FPS

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

хотя и имеет что-то общее с выражением в правой

но ему в общем случае не равно. При ближайшем рассмотрении видно, что равенство будет иметь место лишь в частном случае, когда все t_i равны между собой (t₁=t₂=…=t_n), то есть когда значения времени всех кадров идентичны, что, конечно же, практически невозможно.

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

помимо всем хорошо знакомого среднего арифметическогосуществует ещё несколько средних величин, из которых нам интересна здесь лишь одна, а именно, среднее гармоническоеЕсли словами, то среднее гармоническое по некоторому набору чисел есть обратная величина к среднему от обратных к числам величинам. Звучит, конечно, несколько кошмарно, и не очень понятно, зачем вообще нужно, но сейчас разберёмся. Давайте сразу скажем, что в общем и целом две обсуждаемые средние величины не равны друг другу, за исключением частного случая равенства всех чисел в наборе, x₁=x₂=…=x_n, того самого случая, который для среднего FPS мы отмечали выше.

Так же как и среднее арифметическое, среднее гармоническое находит своё применение в ряде практических задач. Так, например, если некоторый объект несколько раз подряд преодолевает одно и тоже расстояние с разной скоростью, то его средняя скорость на всём пути есть среднее гармоническое скоростей на всех участках. То есть если n раз проехать расстояние d со скоростями v₁, v₂, …, v_n, то время прохождения каждого отрезка составит t_i = d/v_i, а средняя скорость, равная по определению отношению длины пути, пройденного телом, ко времени, за которое этот путь был пройден, будет равна

т.е. среднему гармоническому скоростей, а не их среднему арифметическому. Например, если Вы по пути на дачу на первом километре попали в “пробку” и двигались со скоростью 30 км/ч, а на втором километре “затор” рассосался и Вы “втопили” уже «под 90», то средняя скорость за 2 километра составила, 2 / (1/30 + 1/90) = 45 км/ч, а не (30 + 90) / 2 = 60 км/ч, в чём легко убедиться. Смотрите, Вы проехали 2 км, и если бы Ваша средняя скорость была равна 60 км/ч, то на дорогу у Вас ушло бы всего навсего 2 км / 60 км/ч = 1/30 ч, т.е. 2 минуты. В реальности же только на первый километр Вы уже потратили 1 км / 30 км/ч = 1/30 ч, эти самые 2 минуты, а затем ещё 1 км / 90 км/ч = 1/90 ч (чуть меньше минуты) ушло на второй километр.

Вообще, среднему арифметическому от скоростей средняя скорость равна лишь тогда, когда тело двигалось с этими скоростями одинаковые промежутки времени, а не одинаковые участки пути, но это уже, как должно быть понятно, не наш случай. Почему? Здесь всё просто — мгновенный FPS суть есть скорость смены кадров на участке длиной в 1 кадр, а не продолжительностью в 1 секунду, а значит и среднюю скорость (средний FPS) следует считать как среднее гармоническое значений мгновенного FPS, а не их среднее арифметическое.

Минимальный, 1% и 0.1% низкие FPS

Что ж, со средним FPS разобрались, едем дальше. Собственно, очень давно известно, что использование каких-либо средних величин в качестве единственных характеристик некоего набора данных — всегда плохая идея. Так, например, в нашем конкретном случае необходимо понимать, что время каждого кадра напрямую зависит от его сложности, и периодически в игре могут встречаться кадры со сложностью, существенно превышающей среднюю, на отрисовку которых, как следствие, уходит заметно больше времени. В результате такие “длинные” кадры задерживаются на экране существенно дольше и могут приводить к визуально заметным “подтормаживаниям” и “фризам”, способным испортить всё удовольствие от игры. И тут надо понимать, что такие “длинные” кадры часто бывают редкими, и проблема использования среднего FPS и состоит как раз в том, что в процессе усреднения значений времени кадра информация о “длинных” редких кадрах теряется.

Поясню на небольшом примере. Пускай, за 1 секунду игрового времени было отрисовано 30 кадров со следующими значениями времени отрисовки в мс:

48, 35, 33, 31, 14, 38, 29, 24, 17, 16, 90, 21, 43, 36, 19, 22, 10, 11, 37, 26, 28, 18, 27, 98, 50, 47, 25, 42, 44, 21

Среднее время кадра равняется 33 мс, а средний FPS — 30 кадрам в секунду. Казалось бы, всё неплохо, но обратите внимание на присутствие парочки очень “длинных” кадров (выделенных жирным шрифтом) со временем отрисовки втрое большим среднего, а именно, 90 и 98 мс. При усреднении значений времени кадров информация о наличии столь “длинных” пускай и редких кадров была потеряна, и в результате полученные средние величины вроде бы сигнализируют о достижении минимального порога играбельности, но на деле визуально заметные “просадки” и “фризы” при подобного рода наборах значений времени кадра неизбежны.

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

В математической статистике существует понятие процентиля, которое для наших целей можно определить как значение, ниже которого находится определённый процент данных из набора. Например, 99-процентиль — значение, ниже которого находятся 99% данных из набора. В нашем примере с 30 кадрами, отрисованными за 1 с, 99-процентиль равен 96 мс, и означает это, что 99% значений времени кадра из нашего набора меньше 96 мс, и лишь 1% больше или равен этому значению. Обратите особое внимание, что в нашем конкретном случае из-за малого числа данных в наборе существенной разницы между минимальным значением и 99-процентилем нет, и, как следствие, 99-процентиль здесь ничем не лучше минимального значения в отношении грубых промахов. По сути из всего нашего набора данных лишь единственное значение (минимальное) и не попало “под” 99-процентиль. Однако, если набор данных будет существенно больше, скажем, будет содержать время отрисовки нескольких тысяч кадров, то “длинных” кадров, не попадающих “под” 99-процентиль будет уже порядка нескольких десятков и вместо единственного минимального значения, которое, возможно, является грубым выбросом, у нас будет иметься уже какая-никакая статистика по всем редким “длинным” кадрам. Это обеспечит не только более адекватное описание набора данных, но и значительно лучшую воспроизводимость результатов.

Надеюсь, теперь понятно, чем так хороши процентили, и здесь осталось прояснить лишь какие конкретно процентили использовать. И тут всё, по большому счёту, определяется негласными соглашениями в какой-либо области, и в игровых бенчмарках де-факто стандартом стали 99- и 99.9-процентили времени кадра. Точнее, как уже отмечалось выше, в игровых бенчмарках обычно приводят значения FPS, поэтому и вместо 99- и 99. 9-процентилей времени кадра в результатах обычно фигурируют обратные им 1- и 0.1-процентили FPS, именуемые 1% низкий FPS и 0.1% низкий FPS, соответственно. При этом следует понимать, что 1% и 0.1% от всего набора данных — это лишь небольшая часть данных, описывающая редкие и крайне редкие игровые события. Поэтому в самом факте, что 1% низкий FPS и 0.1% низкий FPS оказываются зачастую значительно ниже среднего FPS нет ничего страшного — такая картина лишь говорит о том, что сложность кадров в игровой сцене непостоянна, что совершенно нормально. Плохо лишь, если обсуждаемые показатели «просаживаются» на конкретной игровой системе слишком сильно, выходя за границы играбельности, так как в этом случае нас ожидают визуальные неприятности.

Последнее, о чём, пожалуй, стоит ещё обмолвиться, перед тем, как перейти к выводам, так это так называемый средний за секунду (или по секунде) FPS, а также характеристики на нём основанные, например, минимальный средний за секунду FPS. Этот «зверь», впрочем, простой: средний за секунду FPS — это просто средний FPS на отрезке в 1 с. Равен он количеству кадров, отображённых за одну прошедшую конкретную секунду, но, так же как и средний FPS за всё время бенчмарка, может быть посчитан и как среднее гармоническое значений мгновенного FPS за эту конкретную секунду. Обычно, именно средний за секунду FPS и отображают на экране различные счётчики частоты кадров наподобие FRAPS, так как значение мгновенного FPS пришлось бы обновлять настолько часто, что в этом месиве всё равно бы никто ничего не разобрал. Использовать же значения среднего за секунду FPS вместо значений FPS мгновенного для более детального анализа бессмысленно, так как наиболее важная информация о времени отрисовки «длинных» кадров в них уже потеряна (см. пример выше). А касательно минимального среднего за секунду FPS упомянем лишь, что он, в отличие от минимального мгновенного FPS, может быть больше, скажем, 0.1% низкого FPS, что периодически порождает путаницу и неразбериху.

Выводы

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

Дополнять среднее число кадров минимальным и максимальным бессмысленно, так как эти единичные значение из набора данных статистически не устойчивы, а максимальное число кадров ещё и в целом показатель бесполезный.
Значительно лучше дополнять среднее число кадров значениями процентилей, например, 1% низким FPS и 0.1% низким FPS, детально обсуждаемыми в тексте статьи. При этом дополнительно указывать ещё и минимальный FPS вместе с процентилями — глупость, так как весь смысл процентилей и состоит как раз в том, чтобы не опираться на статистически недостоверный показатель минимального числа кадров.
Конечно, при небольшом количестве сравниваемых систем (2–3) можно приводить и сами графики (или гистограммы) времени кадра, дающие возможность увидеть все детали игровой производительности участников сравнения, но при большем количестве конфигураций такой подход уже не сработает, так как визуально разобрать что-то будет уже крайне сложно.
Поэтому наиболее универсальны способ — приводить в результатах значения среднего, 1% низкого и 0.1% низкого FPS.
Для накопления значений времени кадров можно использовать всем известную утилиту FRAPS, однако, у неё имеется ряд ограничений, например, отсутствие поддержки современных API (DirectX 12, Vulkan). Значительно лучше в этом плане смотрится свободный инструмент PresentMon, который поддерживает все графические API и к тому же умеет работать с UWP-приложениями. Кстати, именно PresentMon накапливает значения времени кадров, информацию о которых затем отображают такие известные утилиты, как FrameView и OCAT.

Этот материал написан посетителем сайта, и за него начислено вознаграждение.

Неуловимая проблема тайминга кадров / Хабр

Технический директор Croteam Ален Ладавач, участвовавший в разработке Serious Sam и Talos Principle, рассказывает, как ему удалось найти причину торможения графики даже на самых мощных машинах.

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

Т-т-тормоза

Вы с нетерпением ждали следующей части вашей любимой серии видеоигр для PC и она наконец вышла. На этот раз вы хотите насладиться ею во всей полноте, поэтому потратили деньги и время на тщательную подготовку. Вы заменили процессор, поставили сверхсовременную видеокарту, добавили ещё ОЗУ — чёрт возьми, даже купили RAID на SSD. Игра должна быть плавной с самой заставки.

Предзаказ наконец разблокирован и вы только что завершили установку. В нервном предвкушении вы впервые запускаете игру. Пока всё хорошо — она работает с частотой 60 кадров в секунду. Или, по крайней мере, так сообщает счётчик кадров тюнера GPU. Но что-то не так. Вы делаете мышью резкие, хаотичные движения. Стрейфитесь влево-вправо, и тут игра… начинает тормозить! Блин, да как такое возможно? Как она может тормозить при 60 кадрах в секунду?

Если такое с вами никогда не случалось, то это может показаться смешным. Но если вы их испытали, то, скорее всего, ненавидите тормоза всей душой. Тормоза в играх. Это не старый добрый «лаг». Не низкая частота кадров. Это просто «тормоза», происходящие при высоких частотах кадров на идеальных, супербыстрых машинах. Что это, откуда они взялись и как от них избавиться? Позвольте мне рассказать вам историю…

Тормоза, плавность, скорость… это ведь одно и то же?

Видеоигры работали с частотой 60 fps ещё со времён первых аркадных автоматов в 70-х годах. Обычно ожидается, что игра работает с той же частотой, которая используется дисплеем. Так было до популяризации 3D-игр, в которых впервые стала допустимой пониженная частота кадров. В 90-х, когда «3D-карты» (так мы называли их до того, как они стали «GPU«) начали заменять программный рендеринг, люди играли в игры при 20 fps, а 35 fps считались приличным значением для серьёзных сетевых боёв. Я не шучу.

Сегодня у нас есть супербыстрые машины и «разумеется, они могут работать при 60 fps«.

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

Если почитаете разные игровые форумы, то наверняка найдёте подобные сообщения:

Можно подумать, что это единичные проблемы, но посмотрите на статистику поисковых запросов Google:

За последние пять лет тормоза (stutter) стали (относительно) более серьёзной проблемой, чем скорость!

(Учтите, что это относительные значения. Они не значат, что в целом люди спрашивают о торможениях больше, чем о частоте кадров. Они значат, что запросы о частоте кадров (frame rate) остаются на том же уровне, а количество запросов о тормозах растёт, особенно в последнее время.)

Десяток лет в поисках причины необъяснимых тормозов

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

Впервые я столкнулся с этой проблемой ещё примерно в 2003 году. Мы работали над Serious Sam 2, и пользователи начали отправлять нам отчёты о том, что они тестировали что-то на пустом уровне, и при перемещениях мыши движения не были плавными. Это сопровождалось очень характерным паттерном на графике частоты кадров, который мы прозвали «кардиограммой».

Мы думали, что где-то в коде есть баг, но не могли его найти. Казалось, что проблема появляется и исчезает случайным образом — после перезапуска приложения, перезагрузки машины… а потом игрок менял какую-нибудь опцию скорости и она исчезала. Потом игрок снова включал эту опцию, но проблема не возвращалась. Она была похожа на призрака.

Очевидно, что эта проблема возникала не только у нас. Наблюдая за теми же проблемами в других играх, мы начали думать, что виноваты драйверы. Но это происходило на видеокартах разных производителей. Даже на разных API (OpenGL, DirectX 9, DirectX 11…) — единственным общим у них было то, что они появлялись на разных машинах, в некоторых сценах… иногда.

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

Мы выпустили ещё несколько игр, но это странное поведение по-прежнему появлялось и исчезало. Некоторых пользователей оно раздражало, и мы рекомендовали им изменить опции скорости — иногда это помогало, иногда нет. Такова жизнь, не правда ли?

Но однажды, в отличный зимний день в начале 2013 года мой коллега Дин позвал меня, чтобы я увидел ещё один пример этой проблемы, который он на тот момент мог относительно стабильно воспроизводить. На этот раз проблема возникала на уровне из Serious Sam 3. Мы экспериментировали с опциями в этой сцене, пока до меня внезапно не дошло. Я понял, в чём была причина! И она была очень проста — неудивительно, что она ускользала от всех в течение десятка лет.

Изменив всего одну очень простую опцию игрового движка, мы смогли заставить эту проблему появляться и исчезать в этой конкретной сцене. Но нам стало сразу же очевидно, что на её качественное решение потребуется гораздо больше усилий. Усилий не только с нашей стороны, но и всей игровой экосистемы PC — программистов драйверов GPU, разработчиков API, поставщиков ОС — каждого.

Позвольте объяснить.

В чём же была причина всё это время

Хотел бы я показать вам её на примере сцены из Serious Sam 3, которую мы с Дином исследовали пять лет назад. Или даже ещё лучше — на примере тестовой сцены из Serious Sam 2, в которой мы впервые её увидели. Но, к сожалению, после замены «железа» этот ускользающий зверь может переместиться в другую сцену. У меня есть сцена из The Talos Principle, в которой мне недавно удалось воспроизвести эту проблему, и я заснял несколько видео, позволившие проанализировать её более подробно.

Но прежде чем мы начнём, убедитесь, что вы на самом деле смотрите видео в 60 fps. Для просмотра представленных ниже примеров переключитесь в 1080p60, как показано на картинке:

Чтобы смотреть видео в 60 fps, переключитесь в YouTube на 1080p60.

Если вы всё сделаете правильно, а ваш компьютер и веб-браузер способны показывать видео с частотой 60 fps, то представленное ниже видео должно воспроизводиться плавно и без всяких тормозов. Если это не так, то именно поэтому мы и говорим об этом — многие другие приложения тоже демонстрируют такое поведение, не только игры. Пока я могу только рекомендовать вам попробовать посмотреть видео на какой-нибудь другой машине, или просто читать текст.

Проверка, проверка, раз, два, три… Вы должны видеть это видео в плавных 60 fps.

А теперь перейдём к делу. Если вы сталкиваетесь с тормозами, то вероятнее всего это выглядит примерно так:

Вот как выглядят «тормоза при 60 fps». Мы называем этот симптом «кардиограммой».

Да, именно так выглядят «тормоза», даже когда игра работает с 60 fps. Вы могли сталкиваться с чем-то подобным в любой современной игре, и вероятно думали, что «игра не оптимизирована». Так вот, вам стоит пересмотреть свою теорию (о том, что такие тормоза возникают из-за «медленного» рендеринга игры). Если игра «слишком медленная», то это значит, что в какие-то моменты она не сможет достаточно быстро отрендерить один кадр, а монитору придётся заново показывать предыдущий кадр. Поэтому когда мы записываем видео такой игры в 60 fps, то видим «пропущенные кадры». (Это такие кадры, при которых следующий кадр не был отрендерен вовремя, поэтому текущий кадр показывается дважды.)

Теперь снова запустите предыдущее видео с тормозами («кардиограммой»), поставьте его на паузу и нажимайте в проигрывателе YouTube клавишу . (точка), чтобы перемещаться от кадра к кадру. Попробуйте заметить, когда один и тот же кадр показывается дважды. Давайте, попробуйте, я подожду…

Ну как, нашли? Нет? Странно, не правда ли?..

Видео выглядит не плавным, когда смотришь всю анимацию в целом, но когда рассматриваешь покадрово, разрывов нет!

Как такое может быть?

Позвольте мне объяснить более подробно.

Вот сравнение идеально плавного видео и видео с тормозами в виде «кардиограммы», воспроизводимые на 1/20 от исходной скорости, чтобы мы могли видеть отдельные кадры:

Сверху правильное видео с 60 fps, снизу «кардиограмма». Воспроизведение замедлено в 20 раз.

Можно заметить две вещи: во-первых, они действительно воспроизводятся с одинаковой частотой — когда сверху есть новый кадр, снизу тоже есть новый кадр. Во-вторых, они по какой-то причине движутся немного по-разному — есть заметный «разрыв» в середине изображения, который становится то более, то менее заметным.

Внимательный зритель может заметить и ещё одну любопытную деталь: нижнее — тормозящее — изображение — которое считается «медленным»… на самом деле «опережает» правильное. Странно, правда?

Если мы посмотрим на два соседних кадра и их тайминги (заметьте, что во всех показанных мной видео были точные таймеры (с точностью 1/10 000 секунды), то можем заметить нечто очень интересное: первые два кадра идеально синхронизированы, но третий…

Шесть идущих друг за другом кадров из видео с точными таймингами. Верхние — правильные, нижние — с «кардиограммой».

…на третьем кадре мы видим, что дерево в «тормозящем» видео значительно опережает свою копию из правильного видео (обведено красным). Также можно заметить, что на этот кадр, похоже, ушло больше времени (обведено жёлтым).

Постойте… если видео «медленнее», и на кадр «ушло больше времени», то как он может опережать правильный?

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

Краткая история таймингов кадра

Давным-давно, в далёкой-далёкой галактике… Когда разработчики создавали первые видеоигры, они обычно подстраивались под точную частоту кадров, с которой работает дисплей. В регионах NTSC, где телевизоры работали при 60 Гц, это означало 60 fps, в регионах PAL/SECAM, где телевизоры работали при 50 Гц, это означало 50 fps.

Они даже и думать не могли о какой-то возможности «пропуска кадра».

Большинство игр было очень вылизанными и упрощёнными концептами, работавшими на конкретном оборудовании — обычно на аркадном компьютере, или на «домашнем микрокомпьютере», наподобие ZX Spectrum, C64, Atari ST, Amstrad CPC 464, Amiga и т.д. По сути, разработчик создавал дизайн, реализовывал и тестировал игру под конкретную машину и конкретную частоту кадров, и был на 100% уверен, что она никогда не пропустит ни кадра.

Скорости объектов тоже хранились в единицах «кадров». Поэтому говорили, не на сколько пикселей в секунду должен двигаться персонаж, а на сколько пикселей за кадр. Известно, что в Sonic The Hedgehog для Sega Genesis скорость вращения, например, была равна 16 пикселям за кадр. У многих игр даже были отдельные версии для регионов PAL и NTSC, в которых анимации вручную рисовались специально под 50 fps и 60 fps. По сути, запуск при любой другой частоте кадров даже не рассматривался.

Когда игры начали работать на более разнообразных машинах — в частности, на PC с расширяемым и заменяемым «железом» — разработчики больше не могли знать, с какой частотой кадров теперь будет работать игра. Дополните это тем фактом, что игры стали более сложными и непредсказуемыми. Самыми выдающимися в этом плане стали 3D-игры, отличавшиеся разнообразием сложности сцен, иногда даже зависящей от игрока. Например, всем нравится стрелять в бочки с топливом — при этом происходит огромный взрыв, красивые эффекты… и неизбежная просадка кадров. Но здесь никто не против пропуска кадров, потому что это так интересно.

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

Если мы не можем быть уверенными, при какой частоте кадров будет работать игра, нам приходится измерять текущую частоту кадров и постоянно адаптировать физику и скорость анимаций игры. Если один кадр занимает 1/60 секунды (16,67 мс), а персонаж бежит со скоростью 10 м/с, то в каждом кадре он перемещается на 1/6 метра. Но если кадр перестаёт занимать 1/60 секунды, а вместо этого внезапно начал занимать 1/30 секунды (33,33 мс), то надо начать перемещать персонажа на 1/3 метра (в два раза «быстрее») за кадр, чтобы на экране он продолжал двигаться с кажущейся постоянной скоростью.

Как же игра это делает? По сути она измеряет время в начале одного кадра, а затем в начале следующего и вычисляет разность. Это довольно простой способ, но он очень хорошо работает. То есть простите, он работал хорошо. В 90-х (вспомните фразу «35 fps считались приличным значением для серьёзных сетевых боёв» из начала статьи), людей более чем устраивал этот способ. Но в то время графическая карта (не забывайте, их даже ещё не называли GPU) была очень «тонким» элементом «железа», и попаданием объектов на экран непосредственно управлял основной ЦП. Если в компьютере не было 3D-ускорителя, процессор даже сам отрисовывал эти объекты. Поэтому он точно знал, когда они появятся на экране.

Что происходит сегодня

Со временем у нас появились более сложные GPU, и они становились всё более и более «асинхронными». Это значит, что когда ЦП отдаёт GPU команду отрисовать что-то на экране, то GPU просто сохраняет эту команду в буфер, чтобы ЦП занимался своими делами, пока GPU выполняет рендеринг. В результате это привело к тому, что когда ЦП сообщает GPU, что «это конец кадра», GPU просто сохраняет сообщение как ещё один фрагмент данных. Но он не относится к нему как чему-то особо срочному. Да и как он может — ведь ему по-прежнему нужно обрабатывать часть из ранее переданных команд. Он покажет кадр на экране, когда закончит всю работу, которую ему дали раньше.

Поэтому когда игра пытается вычислить тайминги, вычитая метки времени начала двух кадров, то актуальность этого, грубо говоря… весьма сомнительна. Давайте вернёмся к нашему примеру из коротких видео. У нас есть эти кадры, где камера перемещается вдоль деревьев:

Теперь вспомните то, что я говорил о таймингах и перемещениях. В первых двух кадрах тайминг кадра равен 16,67 мс (то есть 1/60 секунды), и камера движется на одну и ту же величину и сверху, и снизу, поэтому деревья синхронизированы. На третьем кадре (внизу) игра увидела, что время кадра равно 24,8 мс (что больше 1/60 секунды), поэтому она думает, что частота кадров снизилась и торопится переместить камеру чуть дальше… только для того, чтобы обнаружить, что тайминг четвёртого кадра составляет всего 10,7 мс, поэтому камера движется здесь чуть медленнее, и деревья снова более-менее синхронизируются. (Синхронизация восстановится полностью только спустя два кадра.)

Здесь происходит следующее: игра измеряет то, что она считает началом каждого кадра, а эти тайминги кадров иногда по разным причинам колеблются, особенно на такой высоконагруженной многозадачной системе, как PC. Поэтому в некоторые моменты игра думает, что не успевает обеспечить 60 fps, и в какие-то моменты генерирует кадры анимации, рассчитанные на меньшую частоту кадров. Но из-за асинхронной природы работы GPU он на самом деле успевает обеспечить 60 fps для каждого отдельного кадра этой последовательности.

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

То есть, по сути, здесь нет никакой проблемы — всё действительно работает плавно, просто игра об этом не знает.

При этом мы возвращаемся к началу статьи. Наконец обнаружив причину проблемы (на самом деле, это иллюзия проблемы — ведь её на самом деле нет, так?), вот что мы сделали для проверки:

Сначала мы наблюдаем «кардиограмму», а затем используем небольшой трюк, чтобы избавиться от неё.

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

Что же это за волшебная опция? В Serious Engine мы называем её sim_fSyncRate=60. Если говорить простыми словами, то это значит «полностью игнорировать все эти заморочки с таймингами и притвориться, что мы всегда замеряем стабильные 60 fps». И благодаря этому всё работает плавно — просто потому, что всё и так работало плавно! Единственная причина, по которой всё выглядело тормозящим — это ошибочные тайминги, используемые для анимации.

И на этом всё? Достаточно сделать так и всё станет замечательно?

Неужели решение настолько простое?

К сожалению — нет. Это всего лишь тест разработчиков. Если мы перестанем замерять частоту кадров в реальных ситуациях и просто будем предполагать, что она всегда равна 60, то когда она упадёт ниже 60 — а на PC она рано или поздно обязательно упадёт по тем или иным причинам: ОС запустит какой-нибудь фоновый процесс, включится экономия энергии или защита от перегрева GPU/ЦП… кто знает — то всё замедлится.

Итак, если мы изменяем частоту кадров, то возникают торможения, если нет — то всё в какие-то моменты может замедляться. Что же нам делать?

Реальное решение заключается в том, чтобы измерять не начало/завершение рендеринга кадра, а время отображения картинки на экране.

Как же нам сообщить игре, что изображение кадра уже показывается на экране? Вы можете удивиться, узнав это — но на сегодняшний день такого способа нет!

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

Что дальше?

Но не волнуйтесь, всё не так мрачно. Многие люди в графической экосистеме активно работают над реализацией поддержки правильного тайминга кадров для разных API. Для Vulkan API уже есть расширение под названием VK_GOOGLE_display_timing, которое продемонстрировало свою полезность в реализации proof of concept. Однако оно доступно только для ограниченного ассортимента оборудования, в основном на Android и Linux.

Уже ведётся работа по созданию аналогичных и более качественных систем для всех основных графических API. Когда она закончится? Сложно сказать, потому что проблема лежит довольно глубоко внутри различных подсистем ОС.

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

Мы стремимся сделать это решение доступным для более широкой аудитории, и когда это случится, мы подготовим апдейт The Talos Principle с реализацией этой функции.

Различные помехи и другие подробности

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

«Композитор»

Эффект матового стекла? Да, для него нам определённо нужен композитор. Он просто-таки необходим, правда?

За кулисами со всем этим связан концепт под названием «композитный менеджер окон», или композитор. Это система, существующая теперь во всех ОС, которая позволяет окнам быть прозрачными, иметь размытый фон, тени, всплывающие поверх окна Skype и т.д. Композиторы даже могут отображать окна в 3D. Для этого композитор перехватывает управление над последним этапом создания картинки кадра и решает, что ему сделать с ней, прежде чем она попадёт на экран монитора. Это ещё больше всё усложняет.

В некоторых ОС композитор можно отключить в полноэкранном режиме. Но это не всегда возможно, а даже если и возможно — то разве можно запретить запускать игру в оконном режиме?

Управление питанием и тепловыделением против сложности рендеринга

Мы также должны учитывать, что современные ЦП и GPU не работают с фиксированной частотой, а имеют системы, изменяющие их скорости в соответствии с нагрузкой и температурой. Поэтому игра не может просто предполагать, что GPU и ЦП будут иметь одинаковую скорость в каждом кадре. С другой стороны, ОС и драйверы не могут ожидать, что у игры в каждом кадре будет одинаковый объём работы. Чтобы учесть это, необходимо разработать сложные системы для общения этих двух сторон.

А разве мы не можем просто…

Скорее всего нет. 🙂 Обычно измерение времени GPU считается альтернативой таймингам дисплея. Но оно не учитывает наличие композитора и тот факт, что ни один из таймеров рендеринга GPU на самом деле не синхронизирован напрямую с обновлением дисплея. Для идеальной анимации нам абсолютно точно нужно знать время отображения изображения, а не время завершения рендеринга.

Что такое время кадра и почему оно так важно в играх?

Измерение производительности игр может быть довольно сложным. Дело не только в средней частоте кадров; время кадра тоже имеет значение. Это стало очевидным с выпуском Gotham Knights , где, несмотря на то, что игра в целом работает хорошо с приличной средней частотой кадров, у нее есть серьезные проблемы с временем кадра. Это реальная проблема, поскольку, хотя время кадра является немного абстрактным для большинства игроков, это жизненно важный показатель при оценке того, насколько хорошо игра на самом деле работает.

Содержание

Время кадра по сравнению с количеством кадров в секунду
Извлечение большего количества данных из времени кадра
Как улучшить время кадра в играх

Не выплескивайте вместе с водой ребенка; частота кадров по-прежнему не менее важна. Но время кадра многое говорит о том, как игра может ощущаться во время игры, и идет глубже, чем просто количество кадров, которые ваша система может выводить каждую секунду. Мы собираемся помочь развеять тайну того, что такое время кадра, как его можно измерить и почему на него следует обращать внимание при оценке производительности вашего игрового ПК.

Время кадра в зависимости от количества кадров в секунду

Большинство игровых тестов выражаются в кадрах в секунду или fps. Счетчики частоты кадров и программное обеспечение для бенчмаркинга работают, захватывая секунду игры, проверяя, сколько кадров было отрендерено за эту секунду, а затем добавляя это к скользящему среднему значению. Например, если игра отрисовывала 62, 64, 58 и 56 кадров в секунду с четырехсекундным интервалом, в игре будет среднее значение 60 кадров в секунду. Но секунда — это много времени в динамичной игре, и не все эти кадры будут рендериться одинаково, причем некоторые кадры рендерятся быстрее, чем другие. Время кадра — это время, которое проходит между каждым из этих кадров, отвечая на вопрос: «Сколько времени проходит между каждым кадром?»

При тех же 60 кадрах в секунду время кадра (теоретически) будет 16,6 мс, или 1/60 секунды. Вы можете сделать это с любой другой частотой кадров. 1/144 секунды будет означать, что каждые 6,9 мс появляется кадр. Просто разделите единицу на среднюю частоту кадров, а затем умножьте на 1000, чтобы получить время кадра в миллисекундах.

Это хорошее упражнение, чтобы понять, что такое время кадра, но оно бесполезно, потому что нереалистично. Время кадра важно, потому что оно варьируется. В секунду, где есть 60 кадров, эти кадры обычно неравномерно распределены по 16,6 мс, и если дисперсия достаточно высока, игра не будет такой гладкой. Возьми Gotham Knights в качестве примера. Хотя на графике выше игра работает со средней скоростью 60 кадров в секунду, есть скачки времени кадра, значительно превышающие 100 мс. Из-за этого игра кажется заикающейся и прерывистой, несмотря на то, что она работает с целевой частотой кадров.

При оценке игры важно учитывать как частоту кадров, так и время кадра, а инструменты сравнительного анализа, такие как CapFrameX, упрощают составление графиков времени кадров. Одно объективно не лучше другого. Они смотрят на две стороны одной медали. Частота кадров говорит вам об общем уровне производительности, а время кадра больше говорит об опыте игры.

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

Извлечение дополнительных данных из кадра

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

Это число, иногда также называемое 99-м процентилем, берет 1% самых низких кадров из набора данных и усредняет их. По сути, минимальные значения в 1 % учитывают максимальное время кадров и, следовательно, самые низкие частоты кадров в наборе данных. Когда вы видите большой разрыв, это указывает на плохое время кадра и на то, что игра не кажется гладкой, даже если она достигает желаемой средней частоты кадров.

Например,

ПК-порт God of War имеет очень стабильное время кадра. Вы можете видеть это на графике выше. Средняя частота кадров 75,7 кадра в секунду и низкая частота кадров 62,6 на 1% относительно близки, около 19% разницы, что указывает на то, что игра работает гладко. Сравните это с Gotham Knights, , где разница составляет 58% между средним значением FPS 49,4 и минимумом 1% 27,2.

кадров в секунду и 1% низких кадров в секунду не являются идеальными показателями, но они все же обобщают производительность игры на определенном оборудовании. Вы можете рассматривать время кадра как необработанные данные, а частоту кадров — как абстракцию этих данных, которую легче усваивать и сравнивать с другими играми или оборудованием. Если вы видели два графика времени кадра для двух разных графических процессоров, это гораздо меньше говорит о том, как они работают по отношению друг к другу, чем сравнение средней частоты кадров, достигнутой этими графическими процессорами в игре.

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

Как улучшить время кадра в играх

Время кадра часто является проблемой игры, драйвера или какого-то промежуточного шага между ними. То есть трудно решить проблемы с временем кадра, если вы столкнетесь с ними. Gotham Knights — хороший недавний пример. Проблемы со временем кадра являются результатом зависаний компиляции шейдеров, которые мы наблюдали в Elden Ring ранее в этом году.

Одна вещь, которую вы можете сделать, чтобы исправить ситуацию, это установить предел частоты кадров. Это не решит проблемы со временем кадра, связанные с такими вещами, как компиляция шейдеров, но может помочь со скоростью кадра в плохо оптимизированных играх. Многие игры имеют встроенное ограничение частоты кадров, но вы также можете установить его с помощью программного обеспечения вашей видеокарты. Для Nvidia перейдите на Панель управления Nvidia , выберите Управление настройками 3D, и установите Максимальная частота кадров на вкладке Глобальные настройки . AMD имеет аналогичную функцию в программном обеспечении Radeon под названием Frame Rate Target Control (FRTC).

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

Что такое время кадра? Почему время кадра важно?

Что такое время кадра?

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

Пример времени кадра

В приведенном выше видео показан пример того, как работает время кадра. Посмотрите на разные частоты кадров: 120 кадров в секунду, 60 кадров в секунду и 30 кадров в секунду. Синие линии для каждого представляют кадры. Оранжевая линия, прокручивающаяся через кадры, представляет время рендеринга или выполнения. По сути, чем ниже частота кадров, тем больше времени требуется для рендеринга кадра. Чем выше частота кадров, тем меньше времени требуется для рендеринга кадра. Из этого примера мы можем ясно видеть, сколько кадров рендерится в зависимости от частоты кадров.

Возьмите нижние 30 кадров в секунду, например, если игра постоянно работает со скоростью 30 кадров в секунду, то для рендеринга одного кадра требуется 33,33 миллисекунды. Если игра постоянно работает со скоростью 60 кадров в секунду, то для рендеринга одного кадра требуется 16,67 миллисекунды. Если игра постоянно работает со скоростью 120 кадров в секунду, то для рендеринга одного кадра требуется 8,33 миллисекунды. За время, необходимое для рендеринга одного кадра со скоростью 30 кадров в секунду, рендерятся четыре кадра со скоростью 120 кадров в секунду. Это довольно резкий скачок в количестве отображаемых кадров.

*Обратите внимание, что это пример рендеринга кадров с постоянной скоростью*

Почему время кадра важно?

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

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

через Gfycat

Это пример микрозаикания, которое происходит в играх.

Несогласованное время кадра приводит к заиканию

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

Например, представьте, что вы делаете что-то простое, например, «О, я не знаю», перемещайте своего персонажа. Вы нажимаете кнопку один раз, и для регистрации ввода требуется 50 миллисекунд. Затем вы пытаетесь двигаться в другом направлении, вы снова нажимаете кнопку, и вдруг требуется 300 миллисекунд, чтобы зарегистрировать точно такой же ввод. К сожалению, к тому времени, когда ваш ввод закончил регистрацию, вы были застрелены. Игра закончена. О, как прекрасно!

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

Как рассчитать время кадра

Уравнение для понимания этого довольно простое. время кадра = 1000 миллисекунд / кадры в секунду

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

Время кадра
15 кадров в секунду соответствует 66,66 мс для рендеринга кадра
30 кадров в секунду соответствует 33,33 мс для рендеринга кадра
45 кадров в секунду соответствует 22,22 мс для рендеринга кадра
60 кадров в секунду соответствует 16,67 мс для рендеринга кадр
75 кадров в секунду равняется 13,33 мс для рендеринга кадра
90 кадров в секунду равняется 11,11 мс для рендеринга кадра
105 кадров в секунду равняется 90,52 мс для рендеринга кадра
120 кадров в секунду равняется 8,33 мс для рендеринга кадра

Заключение

Из этого мы можем сделать вывод, что частота кадров — не единственный показатель, который следует изучать при оценке производительности.

Время кадра: Показатели игровой производительности — что такое средний, 1% и 0.1% низкие FPS