Проблемы тестирования 3D производительности при помощи FRAPS


В повседневной работе 3D тестеров всегда есть несколько "больных" вопросов. Одним из наиболее значимых является то, что далеко не во всех трехмерных играх разработчиками предусматривается возможность проведения тестов производительности. А еще меньше игр выходит, где это сделано действительно удобно для пользователей, где есть возможность автоматизации и получения наиболее полной информации о производительности игры при определенных настройках. Возможности разных игр по тестированию значительно отличаются, некоторые не дают даже простейшего счетчика мгновенной частоты кадров (FPS), а некоторые предлагают все необходимые средства, которые только можно себе представить.

С этой точки зрения, по большому счету, существует три типа игр: в которых тестов производительности нет (таких приложений больше всего, например, Need For Speed: Most Wanted, Condemned: Criminal Origins, Ghost Recon Advanced Warfighter, Tomb Raider: Legend и пр., список практически бесконечен), в которых возможность тестирования есть, но оно удобно не во всех случаях (в качестве примера можно привести F.E.A.R., где отсутствует возможность автоматизации, невозможны запуск теста из командной строки и использование своих демок, а также множество игр, где реализовали лишь вывод мгновенной частоты кадров, вроде TES4: Oblivion). И лишь малая часть игр обладает всеми необходимыми возможностями по определению среднего FPS, а иногда и минимального с максимальным, позволяя записывать собственные демо на разных уровнях игры и при их последующем проигрывании подсчитывать все необходимые цифры. Примеры таких игр: Half-Life 2, DOOM 3, Serious Sam 2 (в последнем есть следующие возможности: запись пользовательских демок, стандартные демки в комплекте, вывод минимального, максимального и среднего значений частоты кадров в секунду, с учетом и без учета пиков и др.).

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

Данный метод измерения производительности является, пожалуй, единственной возможностью проведения бенчмарков в приложениях без интегрированной поддержки, но он не свободен от недостатков. Мало того, эти недостатки могут свести на нет все его преимущества. В этой статье мы попробуем разобраться, имеет ли смысл проведение измерений производительности при помощи FRAPS в 3D играх, не имеющих встроенных тестов скорости рендеринга, и постараемся разобраться в основных недостатках данного метода.

Теоретический взгляд

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

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

Весьма расстраивает абсолютная необходимость в ручной работе — запуске и остановке теста (за исключением возможности, описанной выше). Никакой автоматизации. Представьте, чтобы получить более-менее правильные данные о средней частоте кадров, желательно запускать тест несколько раз, отбрасывая явно неправильные значения (полученные в результате вышеуказанных недостатков человека или технических проблем) и усредняя оставшиеся. А если тестов несколько? В разных разрешениях, с разными настройками, с разными сценами, с разными аппаратными конфигурациями, наконец! Тестеру придется быть внимательным и не совершать ошибок на протяжении нескольких часов (!), не только изменяя настройки и разрешения, но и нажимая клавиши запуска и окончания теста в строго отведенных для этого местах. Время проведения таких тестов может растянуться на несколько дней, кто тогда поручится за то, что тестер под воздействием человеческих слабостей будет делать все точно и постоянно одинаково?

Рассмотрим наглядно примеры ошибок, которые может совершить человек при подобном тестировании. Посмотрите на рисунок, там схематически представлены возможные ошибки тестера на основе реальных результатов игры F.E.A.R. Красным цветом выделен участок, который должен использоваться для измерения средней, минимальной и максимальной частоты кадров (он используется в игре встроенным бенчмарком), а остальными — примеры участков, которые может использовать тестер под влиянием человеческого фактора.

Errors

В первом случае (розовый цвет) наш тестер чуть позже нажал клавишу начала теста и значительно позже — окончания, что привело к большому искажению результатов в большую сторону, так как в конце показатель мгновенного FPS сильно вырос. Во втором случае (зеленый цвет) он заранее включил тест, включив в него ту часть, которая не должна использоваться для тестов и снижает рассчитанный показатель FPS. И выключен тест был также заранее, в него не вошла финальная часть анимированной 3D сцены. И третий случай, отмеченный коричневым цветом, показывает ошибки раннего включения и позднего выключения теста. Это также далеко от идеала, хотя и может показать результаты, близкие к правильным, из-за того, что в начале FPS был низкий, а в конце демки он большой, эти два захваченных с краев кусочка могут уравновесить друг друга.

В практической части мы рассмотрим подобные ошибки, оценив, насколько сильно они могут повлиять на результат расчета FRAPS в реальных 3D приложениях. Но все это было написано про игры, в которых хотя и нет счетчика производительности (средней частоты кадров, как минимум), но есть постоянные скриптовые сценки и/или возможность записи и проигрывания пользовательских демо. Даже в таких случаях полученные цифры могут значительно отличаться от реальной игровой производительности, так как игра — это не скриптовые сцены и не проигрывание демок. А если и таких возможностей нет... Например, некоторые тестеры пользуются таким фокусом, в случае отсутствия возможности использования демок и скриптовых сцен — они загружают определенный уровень игры и просто проходят его несколько раз, с разными программными и аппаратными настройками. Видимо, считая, что средняя частота кадров все равно будет достоверной статистически. Этот вопрос мы также обязательно проверим в практической части статьи.

Проверка в реальных приложениях

В этой части статьи мы рассмотрим вопрос о том, насколько можно доверять цифрам, полученным при тестировании с применением FRAPS. Мы попробуем использовать разные условия тестирования и даже воссоздать некоторые из вероятных ошибок тестеров. Для начала посмотрим, насколько цифры, полученные от FRAPS,  соответствуют тем, что мы привыкли измерять. Для этого мы взяли известный бенчмарк 3DMark06, его первый игровой тест в режиме построения графиков производительности. Заодно запустили и FRAPS, чтобы сравнить показатели, измеренные двумя разными методами, пока только мгновенной частоты кадров.

FPS compare

С этой частью FRAPS справился неплохо, получаемым цифрам среднего FPS за каждую секунду верить можно. Мгновенных значений частоты кадров FRAPS почему-то не измеряет, и из-за подобной усредненности некоторые детали на графике 3DMark06 от него ускользнули. Эти детали не являются существенными, кроме того, раз FRAPS измеряет время, потраченное на построение кадра (есть у него и такая возможность), то есть надежда, что для измерения максимального и минимального FPS он их использует.

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

Тест 1 2 3
Serious Sam 2 42.9 42.8 42.8
FRAPS 42.3 42.0 42.4
Разница 1.4% 1.9% 0.9%

Пожалуй, и тут FRAPS справляется неплохо, его результаты отличаются от цифры встроенного измерителя производительности менее чем на 2%. С другой стороны, результаты явно получаются менее стабильными, по сравнению с результатами, полученными от самой игры, все-таки человек привносит свое влияние. Кроме того, относительно неплохой результат FRAPS мог получиться из-за большой длительности тестовой демки, когда влияние начала и конца демки, где и возникает погрешность, невелико. Посмотрим, что получится в других случаях…

Тест 1 2 3
Far Cry 115.6 49.8 45.3
FRAPS 118.6 48.7 44.6
Разница 2.6% 2.3% 1.6%

Мы попробовали несколько тестовых демок в Far Cry, для разных уровней этой игры, и в этом случае разница была несколько больше той, что показал Serious Sam 2. Возможно, так получилось из-за того, что демки были заметно короче, и большая разница была достигнута на начальных и конечных временных отрезках используемых демок. То есть, проще говоря, подобная разница получилась из-за того, что запуск и остановка подсчета среднего количества кадров в секунду осуществляются вручную, увеличивая влияние на конечный результат.

Чтобы проверить высказанное предположение в теоретической части статьи, посмотрим на сравнительные цифры, показанные встроенным в игру F.E.A.R. тестом, и сравним их с результатами программы FRAPS. В одном из тестов мы специально остановили подсчет FRAPS чуть позже окончания тестовой демки, как бы захватив этим часть того, что не входит в игровую демку, а находится за ее краем. В меню, которое появляется после теста, достигается более высокий FPS, поэтому разница должна получиться существенней. Этим мы пытаемся воссоздать реальные условия, когда после сцены, используемой в качестве тестовой, может начать рендериться значительно более простая (меню, заставка и т.п.).

Тест 1 2 3
FEAR 62 61 62
FRAPS 62.8 62.2 71.8
Разница 1.3% 2.0% 15.8%

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

Тест 1 2 3
3DMark06/GT1 13.7 13.7 13.7
FRAPS 13.3 16.8 13.4
Разница 3.0% 22.6% 2.2%

Можно лишь подтвердить написанное выше — в случае невнимательности тестера и остановки им теста FRAPS позже положенного срока буквально на доли секунды, можно получить результат, не соответствующий действительным значениям производительности. Подобные результаты необходимо отбрасывать, а для верности проводить тесты несколько раз (минимум раз пять, в крайнем случае — три), усредняя их значения, так как дополнительная погрешность измерений, привносимая таким методом тестирования, подтверждается и в этот раз — 2-3%.

Подобная погрешность (2-4% в обе стороны) была бы допустимой в определенных случаях, если бы во всех играх была возможность записи и проигрывания пользовательских демо. Хотя и они могут не отражать реальной игровой ситуации, это хотя бы близко к тому, что происходит во время игры. Иногда допустимо использование скриптовых сцен в реальном времени, использующих тот же игровой движок, но эти данные еще меньше отражают именно игровую производительность, полученные цифры будут значительно отличаться от FPS в игре и смысла в них не так много. Да, они могут показать сравнительную производительность разных видеокарт и настроек при рендеринге скриптовых сценок, но никак не отразят производительность самой игры.

Рассмотрим наиболее спорные возможности, используемые некоторыми тестерами для измерения производительности в таких играх, как Oblivion, Need For Speed: Most Wanted и пр. В них возможности записи своих демок отсутствуют, нет и длительных скриптовых сцен, отражающих игровую производительность, которые можно использовать для тестов. Поэтому некоторые используют такие решения, как прохождение уровней по несколько раз. Посмотрим, что получится, если просто загрузить определенный уровень игры и пройти его часть три раза. Естественно, 3D сцены в таком случае все равно будут отличаться и будет ли средняя частота кадров в таком случае хотя бы близкой?

Начнем мы с игры Serious Sam 2, с уровня под названием Greendale. На графике представлены достигнутые среднесекундные показатели частоты кадров на протяжении трех разных прохождений большого равнинного участка этого уровня. Время прохождения его весьма велико, от 7 до 9 минут, поэтому средние значения вряд ли будут отличаться слишком сильно.

Serious Sam 2 — Greendale

Так и есть, разница в частоте кадров лишь немного превышает 6%, что может показаться небольшой погрешностью, но на наш взгляд все же значительной. На графике видна как очень большая разница в достигнутых максимальных и минимальных показателях FPS в разных прохождениях уровня, так и разная их длительность. Это и понятно, игровая ситуация каждый раз развивается по-разному, и идентичности 3D сцены каждый раз не достичь, тем более, на протяжении достаточно длительного времени. Мы специально исследовали случаи возможных ошибок тестеров и поэтому графики даже в общих чертах не повторяют друг друга, и лишь усредненное значение частоты кадров у них схоже. А, например, минимальные значения FPS были в разбросе от 18 до 31, что уже недопустимо грубо для тестов. Максимальный FPS также отличался очень сильно, между 83 и 117 — пропасть.

Рассмотрим еще один шутер от первого лица, игру Far Cry, начало уровня River. Игра отличается тем, что повторить игровую ситуацию раз к разу тут еще сложнее, каждая попытка приносит что-то свое, оригинальное. Это часто случается в современных играх, когда противники обладают определенным интеллектом и не появляются в одних и тех же местах, каждый раз действуя по-новому. К тому же, будет интересно посмотреть на более короткую сцену, в которой усреднение FPS поможет не так сильно.

Far Cry — River

Разброс значений частоты кадров оказался очень велик, максимальная разница между значениями среднего FPS почти в 16% делает подобное "тестирование" бессмысленным. Отличаются и минимальные и максимальные значения, а какая-то повторяемость графиков наблюдается лишь в небольшой начальной части, где и противников еще нет...

Одной из наиболее интересных игр последнего времени, с точки зрения применяемых графических технологий, является The Elder Scrolls IV: Oblivion. К сожалению, в самой игре доступен лишь счетчик кадров в секунду, который можно включить в консоли, а возможностей записи и проигрывания демок нет, поэтому для измерения производительности в игре некоторые тестеры применяют описанный нами выше метод — загружают сохранение и проходят часть уровня каждый раз заново. Соответственно, одинаково пройти каждый раз не получится, поэтому и результаты должны быть с большой погрешностью.

TES4: Oblivion

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

Последней игрой, которая будет рассмотрена в практической части статьи, является Need For Speed: Most Wanted. Эта игра, по сути, как раз и являлась толчком к написанию данного материала, так как отличалась практической невозможностью стабильного воссоздания игровой ситуации для тестов при помощи FRAPS. В статье о игре я уже отмечал, что применение утилит подобных FRAPS с измерением среднего FPS во время прохождения одной и той же гонки с одной конфигурацией и машиной сильно затрудняется из-за погодных и прочих условий гонки. Разброс результатов оказался даже еще больше, чем указанные в той статье 10%. Одна трасса и те же автомобили с одинаковыми настройками каждый раз дают отличающийся результат. Результаты трех пробных заездов представлены на графике:

Need For Speed: Most Wanted — Circuit

Некоторая повторяемость графиков есть, все они одинаково волнообразны, но это не помогает в достижении близких значений усредненной частоты кадров, она отличается почти на 30% для двух крайних случаев! Влияет на частоту кадров в NFS:MW очень многое: динамическая погода, время суток гонки, плотность транспортного потока, уровень и ошибки AI соперников, умение и удачливость самого игрока. Каждый раз ситуация на дороге иная и поэтому частота кадров всегда отличается. Подобным "тестам" может не помочь даже многократное тестирование и отбрасывание заведомо аномальных результатов. А представьте, что тестерам, использующим подобные методы измерения производительности, еще и приходится по несколько раз играть в одну и ту же игру, сохраняя при этом внимание для того, чтобы нажать вовремя клавишу остановки теста...

Выводы

Тесты производительности, проведенные в рамках материала, показали, что измерение FPS при помощи программ типа FRAPS с определенными оговорками и ограничениями можно использовать для тех игр, где нет встроенных возможностей для измерения производительности (подсчет средней, минимальной и максимальной частоты кадров в секунду), но есть запись и проигрывание демок или хотя бы возможность вывода неизменной каждый раз 3D анимации в реальном времени, использующей игровой движок.

Но даже в случае таких игр, где есть возможность проигрывания демок или скриптовых роликов в реальном времени, относиться к результатам, полученным при помощи FRAPS, нужно осторожно, так как разброс даже в этом случае может достигать 2-4% в обе стороны. Поэтому, чтобы получить хоть какие-то достоверные результаты, необходимо обязательно повторять тест несколько раз (мы бы советовали минимум пять раз), что накладывает на рассматриваемый в статье метод дополнительные ограничения в виде необходимости обработки результатов (отбрасывание явно аномальных данных и усреднение остальных), резкого увеличения трудоемкости тестов, без возможности автоматизации, за исключением установки фиксированной продолжительности теста, а, следовательно, и увеличения необходимого на тесты времени. Прибавляем ко всему сказанному весьма немаленькую погрешность даже в случае многократных повторений и получаем низкую достоверность подобного метода измерения 3D производительности.

Для игр без возможности проигрывания роликов (а это Need For Speed: Most Wanted, TES4: Oblivion и некоторые другие), на наш взгляд, тестирование с FRAPS не имеет никакого смысла, так как разброс результатов подобные тесты "на глазок" дают очень значительный, даже 10% является цифрой неприемлемой, не говоря уже о большем. Конечно, наши тесты показали слабые места слишком ярко, можно придумать методы смягчения таких побочных эффектов, как влияние человеческого фактора и различной игровой ситуации при каждом тестировании, чтобы результаты разных видеокарт были похожи на правду. Например, в NFS: Most Wanted можно выбрать пустую трассу, без автомобилей трафика и соперников, но будет ли полученный результат соответствовать реальному положению дел в игре? А в Oblivion можно найти пустынное пространство, какую-нибудь равнину, и идти по ней каждый раз по прямой, не сворачивая и не встречая врагов. Только тестирование такое слишком похожим на синтетическое будет, это уже 3DMark какой-то получается. А ведь подается оно как тестирование именно игровой производительности...

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

Хотелось бы, чтобы разработчики понимали, чего от них хотят люди, интересующиеся 3D графикой и производительностью высокотехнологичных игр на разных аппаратных платформах и с разными настройками. Очень желательно, чтобы хотя бы наиболее технологичные игры обзаводились встроенными возможностями тестирования, причем, чтобы все было сделано удобно для пользователя и с максимальными возможностями по автоматизации. В конце концов, разработчики и сами заинтересованы в этом. Во-первых, им самим нужны удобные средства анализа производительности. Во-вторых, может упроститься работа с тестерами игры на разных стадиях отладки и доводки (публичные тестовые бета-версии ведь выпускают, взять тот же F.E.A.R.), и, в-третьих, применение высокотехнологичных игр в качестве приложений для тестирования производительности в среде 3D энтузиастов может поднять их популярность. А самое главное — сделать удобные возможности по тестированию производительности в играх для разработчиков не так уж сложно, им нужно просто захотеть этого.

Мы пока будем продолжать использовать те приложения, в которых есть встроенные бенчмарки и возможности по их удобному обустройству. Утилиты, подобные FRAPS, использовать можно, но лишь в определенных (единичных) случаях, по несколько раз проводя тесты, проверяя достоверность полученных результатов, по возможности используя игровые демки. Публикуя данные о том, каким образом проводятся тесты производительности, что они были проведены с использованием утилиты FRAPS, методом, на который влияет человеческий фактор и который снижает достоверность получаемых в итоге цифр. Для постоянного применения такой метод не годится.





Дополнительно

Нашли ошибку на сайте? Выделите текст и нажмите Shift+Enter

Код для блога бета

Выделите HTML-код в поле, скопируйте его в буфер и вставьте в свой блог.