Показатели игровой производительности - что такое средний, 1% и 0.1% низкие FPS
реклама
За последние годы можно наблюдать всё растущее понимание, что одного только среднего FPS по какой-либо выбранной для целей тестирования игровой сцене недостаточно для описания производительности компьютерной системы, а минимальный и максимальный FPS в этом деле совсем не помощники. Давайте разберёмся, в чём недостаток среднего FPS, чем так плох минимальный FPS, а также познакомимся с набравшими популярность более удачными мерилами игровой производительности — показателями 1% и 0.1% низкие FPS.
Время кадра, мгновенный и средний 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
Математически убедиться в этом, впрочем, опять же несложно: нетрудно заметить, что выражение в левой части неравенства выше
хотя и имеет что-то общее с выражением в правой
но ему в общем случае не равно. При ближайшем рассмотрении видно, что равенство будет иметь место лишь в частном случае, когда все ti равны между собой (t1=t2=...=tn), то есть когда значения времени всех кадров идентичны, что, конечно же, практически невозможно.
Вообще, те читатели, кто неплохо знаком с физикой и математикой, тут уже кое-что должны были увидеть. Если вкратце, то, в математике для некого набора чисел
помимо всем хорошо знакомого среднего арифметическогосуществует ещё несколько средних величин, из которых нам интересна здесь лишь одна, а именно, среднее гармоническоеЕсли словами, то среднее гармоническое по некоторому набору чисел есть обратная величина к среднему от обратных к числам величинам. Звучит, конечно, несколько кошмарно, и не очень понятно, зачем вообще нужно, но сейчас разберёмся. Давайте сразу скажем, что в общем и целом две обсуждаемые средние величины не равны друг другу, за исключением частного случая равенства всех чисел в наборе, x1=x2=…=xn, того самого случая, который для среднего FPS мы отмечали выше.
Так же как и среднее арифметическое, среднее гармоническое находит своё применение в ряде практических задач. Так, например, если некоторый объект несколько раз подряд преодолевает одно и тоже расстояние с разной скоростью, то его средняя скорость на всём пути есть среднее гармоническое скоростей на всех участках. То есть если n раз проехать расстояние d со скоростями v1, v2, …, vn, то время прохождения каждого отрезка составит ti = d/vi, а средняя скорость, равная по определению отношению длины пути, пройденного телом, ко времени, за которое этот путь был пройден, будет равна
т.е. среднему гармоническому скоростей, а не их среднему арифметическому. Например, если Вы по пути на дачу на первом километре попали в “пробку” и двигались со скоростью 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.
реклама
Лента материалов
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила