Оригинал материала: https://3dnews.ru/189875

Что считать за минимальный FPS? Так ли прост вопрос, как кажется?

Стр.1 - Постановка вопроса, замечания.

Предисловие

Данная статья является дальнейшим развитием идей, затронутых в статье "Методика тестирования видеокарт 2007. Использование FRAPS". Использование утилиты FRAPS в качестве инструмента тестирования и предложенная нами методика обработки результатов позволяет по-новому взглянуть на привычные, казалось бы, вещи. Более того, в ходе анализа полученных данных возникают новые вопросы. С одним из них мы и хотим вас познакомить.

Предварительные замечания

Как вы все хорошо знаете, наиболее распространенным критерием производительности видеокарт является среднее значение FPS (frame per second, или кадров/с), полученное при тестировании в том или ином приложении (как правило, в 3D-играх). В синтетических 3D-приложениях могут использоваться как обычные FPS, так и свои собственные величины (например – «marks», они же «попугаи»). Сегодня мы не будем рассматривать «синтетику», а ограничимся лишь играми, поскольку производительность видеосистемы в реальной игре гораздо более важна с точки зрения комфортного времяпрепровождения, чем рекорды «в попугаях». А комфорт в различных игрушках, в свою очередь, очень сильно зависит от минимального FPS, который может обеспечить видеокарта. Впрочем, не только видеокарта, а скорее система в целом. Причины «проседания» FPS могут быть самые разные. Это и одновременное появление в сцене большого числа объектов (взрыв, осколки и т.д.), и недостаток оперативной памяти (необходимость подгрузки данных), и медленный жесткий диск (или сильно фрагментированный), да мало ли что может быть. Рассуждая таким образом, легко прийти к выводу, что минимальный FPS отнюдь не всегда определяется только мощностью видеокарты, а может зависеть от производительности других компонентов системы. В тоже время, казалось бы, зачем сыр-бор разводить? Многие игры, обладающие встроенными бенчмарками, показывают не только среднее значение FPS, но так же минимальный и максимальный FPS, полученный в ходе тестирования. Однако все не так просто. Если вы читали статью "Методика тестирования видеокарт 2007. Использование FRAPS", то могли заметить, что результаты, сообщаемые встроенным бенчмарком, могут разительно отличаться от результатов, полученных с помощью FRAPS. В тот раз речь шла о среднем FPS, но вполне разумно предположение, что могут быть значительные расхождения и для минимального FPS. К тому же, что именно считать «минимальным FPS» - сам по себе большой вопрос. Изучением этих моментов мы сегодня и займемся.

Методика тестирования и обработки результатов

Как уже говорилось выше, данный материал является логическим продолжением статьи "Методика тестирования видеокарт 2007. Использование FRAPS". Собственно, методы получения и обработки результатов (с помощью FRAPS) остались неизменными, поэтому здесь мы не будем подробно на них останавливаться. Но необходимо сделать одно разъяснение, касательного способа получения мгновенного значения FPS из времени рендеринга каждого кадра. В прошлый раз автор посчитал, что данный момент очевиден и не вызовет затруднений у читателей. Однако такие манипуляции с временем рендеринга кадра для некоторых читателей оказались сродни «шаманству», да и понятие «мгновенного FPS» в данном контексте также вызвало вопросы. На самом деле, все просто. Пусть у нас есть некоторая величина, предположим – скорость, размерность которой выглядит как «расстояние за единицу времени». Мы взяли в качестве примера «скорость» постольку поскольку производительность видеокарты, измеряемая в FPS, тоже, по сути, является скоростью, и обладает размерностью «количество кадров в единицу времени». Что касается средних величин скорости, тут все понятно. Берем общий путь (общее количество отрендеренных кадров) и делим на затраченное время. Получаем среднюю скорость (среднее значение FPS). C мгновенными значениями скоростей дело обстоит несколько сложнее, но тоже разобраться можно. Предположим, что мы едем на автомобиле, по городу, из точки А в точку Б. Понятно, что скорость движения не будет все время одинакова. На светофоре придется остановиться на «красный», а на проспекте можно и прибавить скорость. То есть - мгновенная скорость будет меняться. Измерять мгновенную скорость каноническим способом, с помощью рулетки и секундомера, как пройденный путь, разделенный на отрезок времени, будет довольно затруднительно. А вот одного взгляда на спидометр будет достаточно, чтобы узнать эту самую мгновенную скорость в любой момент времени. В 3D-приложениях ситуация похожа, какие-то кадры компьютер отрисовывает быстро, какие-то медленнее, а роль «спидометра» играют различные утилиты, такие как FRAPS, RivaTuner и т.д. Однако записывать мгновенные значения FPS, отображаемые утилитами в ходе тестов, довольно утомительно, не говоря уже о возможных «ошибках оператора». Поэтому мы и брали лог-файл FRAPS под названием « … frametimes.csv», в котором хранятся данные о времени рендеринга каждого кадра. Теперь поподробнее расскажем, как из времени рендеринга кадра получить мгновенное значение FPS. Допустим какой-то кадр рендерился в течение 25-ти миллисекунд. Чтобы получить значение FPS, необходимо взять обратную величину к времени рендеринга и умножить ее на 1000 (так как изначально были миллисекунды, а нам надо привести это к секундам), примерно так - «(1 кадр / 25 миллисекунд) * 1000». В итоге получим величину 40 кадров/секунду. Как видите, размерность итоговой величины совпадает с размерностью FPS и выражается в кадрах/секунду. Некоторых читателей смутил момент, что исходное время рендеринга бралось равным не одной секунде, дескать, «FPS то к секунде приводится, значит везде и надо брать отрезок времени именно такой». На самом деле разницы нет. Хоть мы возьмем один кадр длиной 25 мс, хоть 40 кадров каждый по 25 мс – мгновенная скорость будет одинакова. Если вы хотите узнать, с какой скоростью едет ваш автомобиль, не обязательно же нарезать круги в течение часа и считать число километров. Тем более что так вы получите скорее среднюю, а не мгновенную скорость. Именно поэтому мы обрабатывали значения для времени рендеринга каждого кадра и вычисляли соответствующую мгновенную производительность в FPS. Проиллюстрировать вышеизложенное можно следующим образом. Давайте построим график, по оси Х которого отложено время в миллисекундах, а «импульсы» демонстрируют отрезки времени, в течение которых отрисовывается каждый кадр. Для простоты картины возьмем интервал времени, равный одной секунде.
 graph1-render-time.gif
Как видно из графика, в одну секунду отрендерилось 18 кадров, то есть значение FPS, если считать его привычным образом, как раз и равно 18 кадров/с. Но это значение не является мгновенным! Так как время рендеринга каждого кадра не одно и то же, а существенно отличается от кадра к кадру. Поэтому такое «мгновенное» значение FPS в каждую секунду времени, по сути, является усредненным. Собственно, именно такие значения мы и видим в файле в лог-файле FRAPS с именем «… fps.csv». Период усреднения уменьшился до одной секунды, но суть осталась прежней – это средние значения FPS в каждую секунду времени. Если же мы пересчитаем время рендеринга каждого кадра по нашей методике, то получим следующую диаграмму FPS.
 graph2-fps-at-moment.gif
На этой диаграмме мы вместо «импульсов» отобразили мгновенные значения FPS для каждого кадра и поместили их в середину каждого «импульса». Для наглядности, ось Х осталось прежней, с отметками времени в миллисекундах, а по оси Y отложены значения FPS. Если мы теперь подсчитаем среднее значение FPS из вычисленных мгновенных значений для каждого кадра, то получим значение 25,7 FPS. Как видите, разница по сравнению с прежними 18 FPS – огромная! Не говоря уже о взлетах и провалах величины FPS, которые скрадываются даже таким маленьким интервалом времени, как одна секунда. Собственно, тема минимальных FPS и есть то, ради чего затевалась данная статья. Теперь, после несколько затянувшегося вступления, мы спокойно можем заняться этим вопросом.

Стр.2 - Тестирование в F.E.A.R.

Тестирование в F.E.A.R.

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

Тестовый стенд
Процессор
AMD Athlon64 X2 3800+ @ 2,7 ГГц
Плата
ASUS A8N-SLI Premium
Память
Hynix DDR400 2x1024 Мб
ОС
WinXP + SP2 + DirectX 9.0c
Блок питания
FSP 400 Вт
Видеокарта
PCI-E GeForce 7800GTX
Для тестирования использовались драйверы ForceWare 93.71 WHQL. Этот стенд «слабее» по производительности, чем тестовый стенд на базе Intel Core Duo, который мы обычно используем в тестах, но в данном случае это некритично, поскольку наша задача состоит не в сравнении результатов разных видеокарт между собой, а в изучении минимального FPS. Что касается видеокарты, если кто забыл, то по конфигурации и производительности GeForce 7800GTX наиболее близка к GeForce 7900GT и имеет лишь чуть заниженные по сравнению с ней частоты. Мы решили начать наше рассмотрение с хорошо известной игры F.E.A.R. Такой выбор обусловлен тем, что игра имеет встроенный бенчмарк, который показывает средний, минимальный и максимальный FPS, а также несмотря на солидный «возраст» довольно требовательна к железу. При прогоне бенчмарка одновременно запускалась утилита FRAPS, таким образом в нашем распоряжении оказывалось целых три набора данных. Первый набор – результаты показываемые самой игрой. Второй набор – данные FRAPS из файла « … minmaxavg.csv». Третий набор – данные, полученные после обработки файла FRAPS с именем « … frametimes.csv». Для режима MaxQuality, 4AA/16AF, SS OFF - 1280x1024 получены следующие значения FPS (min, avg, max, соответственно):
  • FEAR benchmark – 26; 48; 108;
  • FRAPS minmaxavg – 23; 47,8; 110;
  • FRAPS frametimes – 5,3; 62; 266;
Давайте построим диаграмму распределения FPS по диапазонам значений с шагом в 1 FPS на основе данных из FRAPS «frametimes». Поскольку нас интересуют минимальные значения, на диаграмме распределения мы оставим «главный колокол» значений, и отметим минимальные значения FPS для каждого набора. Первому набору соответствует зеленый цвет, второму – оранжевый, третьему – красный. Вот что получится в итоге.
 graph3-fear-spectrum.gif
Возникает закономерный вопрос, что же в этом случае считать минимальным FPS? вопрос не праздный. От принятого решения зависит и способ «борьбы» с минимальным FPS (в смысле его повышения). Если принять за правду показания встроенного бенчмарка, то вполне можно оставить все как есть, не так уж и критично выглядит картина. Но из диаграммы видно, что значение минимального FPS, сообщаемое встроенным бенчмарком игры, не является достоверным, поскольку присутствует заметное количество значений меньшей величины. И это действительно ощущается в виде заметных «лагов» или «спотыканий». Что касается результатов «FRAPS minmaxavg», то эта отметка ближе к реальности. Примечательно, что значение 23 FPS является практически «срезом» левой стороны главного колокола распределения. В диапазоне от 0 до 21 FPS мы видим «хвост» распределения из незначительного числа «провалов», минимальным из которых является значение 5,3 FPS из «FRAPS frametimes» (по построению). Приверженцы крайностей вполне могут посчитать именно это значение за «минимальный FPS», поскольку ниже уже некуда. Мы не будем сейчас обсуждать природу этих «провалов» производительности, а приведем еще одну диаграмму распределения, полученную в тех же самых условиях, но для разрешения 640х480.
  • FEAR benchmark – 43; 108; 299;
  • FRAPS minmaxavg – 44; 109; 305;
  • FRAPS frametimes – 9,8; 158; 444;
 graph4-fear-spectrum640.gif
Как и ожидалось, при уменьшении разрешения результаты резко выросли, практически в 2 раза для всех типов значений (min, avg, max). Тем не менее, несмотря на значительное облегчение графического режима, «провалы» производительности вплоть до 10 FPS никуда не делись. Что может быть причиной их возникновения? Объем оперативной памяти стенда равен 2 Гб, а загрузка оперативной памяти в ходе тестирования не превышала 700 Мб. Видеопамять тоже не причем, как видно из скриншота ниже.
 riva-mon.gif
Для данной тестовой сцены максимальная загрузка видеопамяти была меньше 230 Мб, так что установленных на видеокарту GeForce 7800GTX 256 Мб видеопамяти вполне достаточно, чтобы не гонять текстуры по шине туда-сюда. Как оказалось, в ходе теста все же идет подгрузка данных с жесткого диска, о чем свидетельствовал моргающий светодиод «HDD» на лицевой панели корпуса. Увеличение скорости жесткого диска наверняка может сгладить проблему. Поэтому, как ни смешно это звучит, вполне реальным представляется тестирование «зависимость минимального FPS от скорости работы дисковой подсистемы». С другой стороны, даже самый быстрый диск (или массив) не решит проблему полностью. В наших условиях тестирования объем оперативной памяти более чем достаточен, поэтому приходится констатировать, что это проблема движка игры, и дальнейшая борьба за увеличение минимального FPS находится за пределами выбора «правильного железа». Ну а раз «провалы» производительности все равно будут иметь место даже на столь малых разрешениях, зачем отказывать себе в качественной графике? Для примера мы приведем еще одну диаграмму распределения, единственное отличие которой от первой из рассмотренных состоит в том, что режим 4AA/16AF заменен режимом NO AA/AF.
 graph5-fear-spectrum1280noaaaf.gif
Как и ожидалось, «провал» на месте, а минимальный FPS по версии встроенного бенчмарка игры подрос с 26 до 33 FPS. Улучшение есть, но не настолько кардинальное, чтобы жертвовать полноэкранным сглаживаем и высококачественной анизотропной фильтрацией. Подведем промежуточные итоги. На взгляд автора, «минимальным FPS», который зависит от выбранного графического режима и производительности видеосистемы (а именно эта цифра представляет наибольший интерес при тестировании непосредственно видеокарт), все же следует считать значение FPS, которое находится у левого «среза» главного «колокола» распределения. Как видно из тестов F.E.A.R., это значение очень близко к тому, что показывает встроенный в игру бенчмарк. А что делать, если игра не обладает встроенными средствами измерения производительности? Вышеизложенный принцип определения «минимального FPS» может пригодиться и здесь. Давайте проверим это на игре Need For Speed Most Wanted.

Стр.3 - Тестирование в NFS MW и Carbon

Тестирование в NFS Most Wanted и Carbon

Тестовый стенд остался без изменений. Поэтому сразу приступим к ознакомлению с результатами. В качестве демо-сцены использовалась кольцевая трасса, по которой проезжалось два круга, чтобы включить все возможные особенности – смену дня-ночи, дождь, различное положение соперников и «ботов» на трассе. Число соперников и уровень трафика выбралось максимальным. Встроенного в игру теста нет, поэтому в нашем распоряжении только результаты, полученные с помощью FRAPS.
  • FRAPS minmaxavg – 29; 43,3; 54;
  • FRAPS frametimes – 18,4; 44,4; 64,7;
 graph6-nfsmw-12-4aa-16af.gif
Как и в случае с F.E.A.R., пересчет данных «FRAPS frametimes» дает более низкое значение минимального FPS. А вот минимальный FPS из файла «FRAPS minmaxavg» дает значение, близкое к левому срезу «колокола» распределения. Впрочем, если определить срез «колокола» как 10% от максимального значения (высоты столбцов распределения), то эта величина находится на уровне 30-31 FPS. Теперь посмотрим, что будет если уменьшить разрешение до 640х480, при сохранении неизменными всех прочих параметров.
  • FRAPS minmaxavg – 41; 56,6; 67;
  • FRAPS frametimes – 20; 57,4; 79;
 graph7-nfsmw-64-4aa-16af.gif
Опять видим знакомую картину. «Хвост», обозначающий проседания производительности, находится практически на том же месте что и в разрешении 1280х1024, в то время как минимальный FPS по версии «FRAPS minmaxavg» переместился к значению 41, а срез колокола распределения по уровню «10% от максимума» находится на уровне 44-45 FPS. Если мы возьмем последнюю версию из серии Need For Speed под названием Carbon, то увидим следующую картину.
 graph8-nfscarbon-64-4aa-16af.gif
 graph9-nfscarbon-64-4aa-16a.gif
Мы специально выполнили диаграммы в одном масштабе по оси Х, чтобы можно было сравнить изменения в величине минимального FPS в зависимости от графического режима. Игра довольно насыщена шейдерами, поэтому в режиме 1280х1024 ширина «колокола» мала. С уменьшением графического разрешения «колокол» смещается по оси Х вправо, при этом в диапазоне от 9 до 40 FPS мы можем видеть все те же самые провалы производительности. Как и в случае с F.E.A.R., объема и оперативной, и видеопамяти, установленной на стенде, вполне достаточно, но провалы все равно имеются. Хотя с Need For Speed ситуация не настолько мистическая, поскольку гоночная трасса довольно протяженная и без подгрузки данных с жесткого диска никак не обойтись. На этом мы закончим тесты и подведем итоги.

Выводы

Мы выяснили, что значение «минимального FPS» сильно зависит от способа его вычисления. Рассмотренные в статье игры были выбраны произвольно, а не из-за своей исключительности. Очевидно, что рассмотренный метод вычисления «минимального FPS» можно легко применить и к любым другим 3D-играм. Но главное не это. Во-первых, сама величина «минимального FPS» зависит от способа ее измерения, или средств, для этого использованных. Это уже вносит неоднозначность. Во-вторых, абсолютный минимум FPS, который мы получили после обработки файла статистики «FRAPS frametimes», как оказалось, практически не зависит от собственно видеосистемы и графического режима, а скорее характеризует «движок» игры или другие компоненты системы. Поэтому говорить о зависимости «минимального FPS» от производительности видеосистемы не приходится. В третьих, выбор любого другого «минимального FPS» кроме абсолютного, будь то значение, сообщаемое встроенным бенчмарком, утилитой FRAPS или «срезом левой части главного колокола распределения по уровню 10% от максимума» - является чистой воды произволом. Что касается мнения автора, то считать минимальный FPS по «срезу…» является более правильным и информативным, с точки зрения тестирования видеосистемы. Но и здесь возникает вопрос, например – почему именно 10% от максимума, а не 5% или 15%? И это не считая множества других возможных возражений. Поэтому… Вопрос о том, что же считать «минимальным FPS», остается открытым. Обсудить тему на форуме. P.S. Именно поэтому в наших тестах видеокарт мы не спешим приводить значение минимального FPS



Оригинал материала: https://3dnews.ru/189875