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

Что такое FPS и кому это нужно

Содержание

Содержание

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

Что такое FPS и на что влияет

FPS — аббревиатура от английского Frames Per Second или «количество кадров в секунду», пришедшая к нам из кинематографа.

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

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

Какой должна быть частота смены кадров и от чего это зависит

Если в мире кинематографа все относительно просто: частота кадров определяется техникой, поэтому все стандартизировано и количество кадров в секунду всегда точно известно. То в мире компьютерных игр так не получается.

Казалось бы, чего проще — человеческий глаз воспринимает в среднем по 50 кадров в секунду. Если частота обновления экрана будет 60 Гц, то глаз мерцания не заметит. Именно по этой причине современные мониторы идут 60 Гц и выше. Но чтобы монитор воспроизводил с такой частотой сменяющиеся кадры, их надо на него подать с видеокарты, а для этого сначала требуется выполнить графические вычисления. Вот с этим как раз и возникают основные проблемы.

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

Все это делается ради того, чтобы в тесте и игре при как можно более высоком разрешении и детализации добиться максимального FPS — чем больше, тем лучше. И желательно стремиться к 60 кадрам в секунду и выше, чтобы происходящее на экране действие было как можно более естественным. Разумеется, при максимально высоком разрешении экрана и детализации. И уж точно не стоит опускаться ниже 30 кадров в секунду, так как чем ниже будет FPS, тем более рваной и дерганой станет картинка, тем менее комфортной станет игра.

Что влияет на FPS

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

Что влияет на значение FPS? Есть несколько факторов:

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

Система должна быть сбалансированной: быстрой, производительной видеокарте, чтобы она показала все, на что способна, нужен приличный процессор и быстрое ОЗУ.

Оказывает влияние на FPS и монитор. Если он дешевый и поддерживает частоту обновления экрана в 60 Гц, то, как бы быстро не считала видеокарта полигоны и пиксели, визуально для пользователя ничего не изменится, так как все ограничит монитор. Поэтому, чем выше частота обновления экрана монитора, тем лучше.

Но «железо» — это еще не все. FPS существенно зависит от настроек в конкретных приложениях-играх и самих программ. Как это проявляется в реальном использовании? Очень просто: чем слабее ваше оборудование, чем меньше производительность видеокарты и процессора, тем меньшее разрешение и настройки детализации вам придется выставлять, вплоть до отключения ряда опций, на которые уходит драгоценная вычислительная мощность (вся эта реалистичная трава, волоски, кожа, листья, вода).

Поэтому даже если FPS на максимальных настройках не очень хорош, например, падает до 20–30 кадров в секунду, его всегда можно улучшить, снизив немного разрешение выводящейся на экран картинки. То есть, упростив вычислительную задачу, стоящую перед видеокартой и остальным «железом» вашего компьютера.

Впрочем, бывают и особенно сложные случаи, как с Wolfenstein New Order, когда разработчики сделали такой игровой движок, что он умудрялся выдавать минимальный FPS на любом компьютерном железе. Сказывается на количестве кадров в секунду и наличие параллельно работающих приложений, например, антивирусного ПО: чтобы выжать максимум FPS, можно, отключить его на время игры.

FPS и Ping

Еще одна «больная» для игроков тема — это пинг (от английского «ping»). При высоком пинге, когда информация от клиента к серверу и наоборот передается слишком долго, да еще теряется часть пакетов, FPS будет снижаться вплоть до замирания «картинки». Для игр вроде Counter-Strike и прочих экшенов высокий пинг и такие потери сказываются на качестве игры губительным образом. Недаром в сетевом мониторинге net_graph разработчики Counter-Strike выдают также информацию о FPS.

Как узнать свой FPS

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

Гораздо интереснее проверка FPS в конкретных приложениях, потому что количество кадров в секунду в каком-нибудь последнем Battlefield или Star Wars Battlefront с максимальными настройками — это одно, а какая-нибудь стратегия или казуальная игра — это совсем другое. И интересно узнать FPS для той игры, в которую вы играете, настроить ее таким образом, чтобы играть было комфортно.

Проверить FPS в приложениях можно двумя способами:

Из отдельных приложений для измерения количества кадров в секунду можно отметить, например, утилиту Fraps, появившуюся в 1999 году и успешно работающую на современных машинах. Преимущество этого приложения — невысокие системные требования. Утилита работает на слабых компьютерах и не отнимает дополнительных ресурсов. Кстати, это же приложение используют для того, чтобы делать скриншоты.

Также для контроля FPS используют приложения PlayClaw, FPS Monitor, MSI Afterburner и другие. Разумеется, это не одна их функция, Afterburner, например, используют для разгона видеокарт, а FPS Monitor — для контроля загрузки процессора и видеокарт.

Можно проконтролировать FPS, не устанавливая дополнительные приложения, а включив отображение количества кадров в секунду в настройках игровых сервисов Steam и Origin.

В ряде игр можно включить отображение величины FPS непосредственно в их собственных внутренних настройках. Например, в CS:GO это делается через консольную команду, а в Dota 2 — в расширенных игровых настройках.

Источник

Оптимизация: почему время важнее полигонов

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

В этом материале преподаватель курса OutBlock и левел-дизайнер VOID Interactive Денис Куандыков объясняет, как устроена оптимизация, и почему количество полигонов тут — не ключевой фактор.

Если 3D-артист со стороны попытается самостоятельно оценить сложность кадра, то может получиться недоразумение. Художник не знает, какое количество треугольников будет оптимальным, если нет чёткого технического задания.

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

Как устроена отрисовка кадра

Процесс отрисовки кадра — это та самая «магия под капотом движка». У отрисовки, как и у работы художника, есть стоимость, и рассчитывается она исходя из необходимого времени.

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

«Время кадра» — это время в милисекундах, за которое может быть построен и отрисован один кадр. Чтобы получить 60 кадров в секунду, один кадр должен быть обсчитан за 16 милисекунд или еще быстрее.

Draw Call (вызов отрисовки) — это одна графическая команда, которая должна что то отрисовать.

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

И наоборот — чем меньше вызовов отрисовки, тем быстрее считается кадр, и тем выше FPS.

Примерный разброс лимитов на Draw Call можно описать так:

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

— Игры для ПК и консолей — до 4000.

Например, Battelfield и третий «Ведьмак» в среднем работают на 1000-2000 вызовах отрисовки.

В то же время, некоторые внутренние движки Ubisoft спокойно работают на значениях вплоть до 20 тысяч. Дело в том, что Draw Call — это тоже не идеальное мерило производительности. Вызовы отрисовки бывают разные, и тут всё зависит от того как работает конкретный рендер-пайплайн в конкретном проекте. Подробно разобраться в том, как это устроено, можно здесь.

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

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

— Intel Graphics Perfomance Analisys

Подробнее обо всех этих инструментах можно узнать здесь.

Самое важное: нужно оценивать стоимость кадра. А первичное мерило стоимости — это время. Уже затем можно всё раскладывать на процессы, то есть, на те самые вызовы отрисовки.

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

Вызовы отрисовки

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

Простой пример: у нас есть 10 ящиков и одно дерево. Все десять ящиков имеют один и тот же шейдер, материал и количество полигонов. Логично предположить, что у нас будет 11 вызовов, ведь в кадре 11 объектов.

Всё почти так и есть. Программа рендерит так: «ящик, ящик, ящик, ящик, ящик. и потом дерево. Кадр построен».

Однако, судя по статистике, у нас всего три батча (вызова отрисовки):

Дело в том, что движок сам понимает, что перед ним десять одинаковых ящиков. Он сам «сшивает» ящики в один объект, и теперь процессор отдает нашей видеопамяти на отрисовку один кусок меша, который мы видим как 10 отдельных ящиков.

Этот процесс называется «батчинг». Он бывает динамическим и статическим.

Как устроен батчинг

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

Обычно у динамического батчинга очень жёсткие лимиты; он не позволяет сшивать тяжёлую геометрию и занимается в основном мелкими деталями в кадре. Например, если от стены динамически отделились мелкие осколки, то они они, скорее всего, будут сшиты динамическим батчингом в каждом отдельном кадре.

Как устроен батчинг

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

Обычно у динамического батчинга очень жёсткие лимиты; он не позволяет сшивать тяжёлую геометрию и занимается в основном мелкими деталями в кадре. Например, если от стены динамически отделились мелкие осколки, то они они, скорее всего, будут сшиты динамическим батчингом в каждом отдельном кадре.

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

Например, тысячи рыб в кадре в Abzu — это на самом деле партикли, геометрия которых дополнительно анимирована шейдером с вертексной анимацией.

Отличие от динамического батчинга в том, что он позволяет перерабатывать огромное количество объектов. За один батч Unity может сшить объектов общим количеством до 64 000 треугольников.

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

Чтобы батчинг сработал, объекты должны быть «одинаковы». Объекты должны иметь один и тот же шейдер, материал на этом шейдере (в Unreal это инстанс материала), текстуру и остальные параметры объекта, а также не должны иметь Non Uniform Scale и не должны быть разбиты светом.

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

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

Однако батчинг тоже не «бесплатен» — даже если он статический и обсчитан заранее. Сцены в играх нужно освещать, и даже в случае статичного освещения это будет влиять на батчинг.

Так например, два одинаковых ящика, которые в обычной ситуации превратились бы в один батч, разделят на два батча, так как они привязаны к разным лайт-пробам (Light Probe).

Освещение в реальном времени тоже будет влиять на то, какие объекты сбатчатся, а какие — нет.

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

Поэтому иногда применяют «ручной» батчинг, он же просто «мердж» (merge). Берём геометрию, и в любой программе сшиваем так, как нужно под конкретную сцену.

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

Иногда гораздо выгоднее скормить движку огромный меш в 64 тысячи треугольников, чтобы отрисовать всю локацию целиком. Так поступили, например, разработчики Guns Of Boom.

Уровни детализации

Level of Detail (LOD, или уровень детализации) — простая техника, которая позволяет уместить огромное количество объектов в кадре, не отнимая время на обработку лишней геометрии.

LOD может разбить объекты на разные батчи: и в этом нет ничего страшного, ведь зачастую несколько сотен лишних DrawCall будет быстрее обсчитаны на лодированых мешах чем рисовать их оригиналы — но сбатченные.

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

Обычно используют четыре уровня детализации. LOD-0 — это оригинальная модель, а LOD-3 — дальняя. LOD4 может быть просто 2D спрайтом который всегда смотрит на игрока.

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

Это касается даже мелких объектов: например, у обычной кружки в одной из стартовых сцен Dead Space 2 было достаточно полигонов, чтобы она не казалась «квадратной», в то время как в остальной игре в LOD-0 у аналогичных объектов не было такого сглаживания.

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

Если модель, например, можно разглядеть вблизи с максимальным приближением, то просто сделайте LOD-0 достаточно детализированным, — а в самой сцене основным рабочим уровнем будет LOD-1.

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

Alpha overdraw

Рендер-пайплайн должен адекватно рассортировать и нарисовать сцену — обработать шейдеры, геометрию, текстуры и пост-процессы. К тому же он должен учитывать, что объекты могут быть прозрачными.

Чем больше площадь прозрачности в кадре, и чем больше прозрачные объекты наслаиваются друг на друга — тем дольше рендер-пайплайн будет рисовать итоговый пиксель, ведь ему придётся каждый раз его перерисовывать. Это называется Alpha overdraw.

Чем меньше альфы, тем быстрее будут обсчитаны пиксели. По сути, шейдер и сам рендер — это процесс/программа, которая рисует конкретный цвет конкретного пикселя на экране. И в этом случае пара десятков лишних треугольников, наоборот, ускорит рендер.

Z-Fight — артефакт, который образуется, если поставить несколько полигонов в одной плоскости. Рендеру не хватает точности глубины, чтобы отсортировать отрисовку этих полигонов в правильном порядке.

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

Итог

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

Нынешнее железо — даже мобильное, — может обрабатывать огромное количество треугольников. Объёмы памяти и скорость растут. Чипы на мобильных устройствах и их батареи, которые перегреваются при высоком 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

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

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

но ему в общем случае не равно. При ближайшем рассмотрении видно, что равенство будет иметь место лишь в частном случае, когда все 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, что периодически порождает путаницу и неразбериху.

Источник