Введение
Этим материалом мы продолжаем исследование, начатое в прошлый раз, и очень желательно для начала ознакомиться с ним. За прошедшие с того времени почти два года, проблемы тестирования 3D-производительности не исчезли. И самым главным осталось то, что разработчики не во все игры встраивают возможность тестирования производительности, не говоря уже о том, чтобы это было сделано удобно, поддавалось простой автоматизации и выдавало полную информацию о среднем, минимальном и максимальном количестве кадров в секунду.
С точки зрения возможностей по тестированию производительности, существует три типа игровых приложений: не имеющих встроенных возможностей тестирования, имеющие возможность вывода мгновенного значения FPS или с тестом, плохо поддающимся автоматизации, и игры, обладающие всеми необходимыми возможностями по определению среднего FPS, а также минимального и максимального, с возможностью записи собственных демок.
К первому типу отнесем такие популярные приложения, как BioShock, DiRT, Need for Speed: ProStreet, Test Drive: Unlimited и многие другие, таких приложений больше всего. Ко второму типу можно отнести World in Conflict, встроенный бенчмарк которого плохо поддаётся автоматизации (необходимо писать сложные скрипты в специальных приложениях), где невозможен запуск теста из командной строки и запись собственных демок, и большое количество игр, где реализован вывод только мгновенной частоты кадров. К наиболее приятному для тестеров типу игр относятся: Crysis, Call of Juarez и S.T.A.L.K.E.R. В них есть возможности записи пользовательских демок (в первом — ещё и качественные стандартные демки в комплекте), вывод минимального, максимального и среднего значений частоты кадров в секунду.
Естественно, число игр со встроенными средствами тестирования слишком мало, и разнообразие игр без бенчмарков шире, поэтому многие тестеры решаются на тесты таких 3D-приложений любым доступным способом. Например, при помощи сторонних утилит, позволяющих измерять FPS (минимальный, максимальный и средний). Наиболее известной из таких утилит является программа FRAPS, но есть и другие схожие программы.
Их применение является единственной возможностью проведения тестов производительности в приложениях без встроенных возможностей. И в этом — несомненное достоинство такого метода. Но в прошлом исследовании мы подробно разбирали и его недостатки, которые вполне могут лишить такие тесты смысла. В данной статье мы продолжим разбираться, возможно ли проведение измерений производительности при помощи FRAPS в играх, не имеющих встроенных тестов, и какой погрешностью это нам грозит.
Теория
На теоретических вопросах мы подробно останавливались в первой части исследования, советуем ознакомиться с ней. Здесь повторим лишь главное. Одним из основных недостатков методики является человеческий фактор, так как возможности тестера ограничены временем реакции, внимательностью и другим. И тестер не может с абсолютной точностью нажимать клавишу запуска и остановки тестирования по несколько раз, а для цифр средней частоты кадров с приемлемой погрешностью нужно, чтобы моменты начала и конца подсчета на разных видеокартах были максимально близки при каждом тестировании.
Кроме того, для тестирования большого количества видеокарт в разных условиях очень важна возможность автоматизации. Ведь при ручной работе по запуску и остановке теста по несколько раз, в разных разрешениях, с разными настройками, да при разных видеокартах, тестеру придётся быть внимательным всё это время. И его неизбежные ошибки повлияют на погрешность измерения, увеличив её до неприемлемой величины (больше обычных 2-3%, типичных для тестов в игровых приложениях третьего типа).
А сейчас мы продолжим исследование в нескольких современных играх, оценим ошибки тестера и то, насколько сильно они влияют на результаты. В этот раз особое внимание обратим на игры, где нет возможности записи и проигрывания пользовательских демо или повторов, так как там, где они есть, тестирование при помощи FRAPS имеет определённый смысл, как мы поняли из предыдущей статьи. Но если таких возможностей нет, то некоторые тестеры выкручиваются так — загружают определенный сейв или уровень игры и проходят определённую его часть несколько раз, с разными программными и аппаратными настройками. Считая, что погрешность в подсчёте средней частоты кадров в таком случае будет приемлемой. Это мы сейчас и проверим.
Конфигурация и настройки тестовой системы
При тестировании использовалась следующая программно-аппаратная конфигурация:
- Процессор: AMD Athlon 64 X2 4600+ Socket 939
- Системная плата: Foxconn WinFast NF4SK8AA-8KRS (Nvidia nForce4 SLI)
- Оперативная память: 2048 МБ DDR SDRAM PC3200
- Видеокарты: Nvidia Geforce 8800 GT 512 МБ
- Жесткий диск: Seagate Barracuda 7200.7 120 ГБ SATA
- Операционная система: Microsoft Windows Vista Home Premium
- Видеодрайвер: Nvidia ForceWare 169.21
Использовался единственный режим видеонастроек — довольно распространенное и требовательное разрешение 1600x1200 (близкое к нему широкоэкранное 1680x1050 покажет схожий результат), с включенными мультисэмплингом с четырьмя выборками (MSAA 4x) и анизотропной фильтрацией максимально возможного уровня — 16x. Все возможности включались из игровых настроек, в конфигурационной панели видеодрайвера ничего не форсировалось.
Набор игр, использовавшихся в наших тестах, включает современные проекты, не имеющие встроенных возможностей тестирования. Предпочтение отдавалось новым и интересным с точки зрения технологий 3D-графики играм разных жанров. Список используемых в исследовании игр: BioShock, Call of Duty 4, DiRT, Need for Speed: ProStreet, Oblivion, Test Drive: Unlimited. Дополнительно из программного обеспечения использовалась последняя версия утилиты FRAPS.
Практические результаты
Итак, рассмотрим случаи, если в игре нет возможности записи и проигрывания пользовательских демо-записей. Хотя они не всегда отражают реальную производительность, но близки к тому, что происходит на экране во время игры. В некоторых случаях допустимо использование скриптовых сцен, использующих тот же игровой движок, но такие сцены плохо отражают игровую производительность, полученные цифры будут значительно отличаться от FPS в игре. Они могут показать сравнительную производительность разных видеокарт при рендеринге скриптовых сценок, но не отразят производительность в самой игре.
Попробуем воссоздать работу тестера при измерении производительности в таких играх, как Oblivion, Need For Speed, BioShock, в которых и возможность записи своих демок отсутствует, также нет скриптовых сцен, отражающих игровую производительность. Допустим, в таких случаях тестеры используют прохождение определенных частей уровней, например, от забора до следующего дуба. Посмотрим, что получится, если загрузить определенный уровень и пройти его часть несколько раз. Хоть мы и будем проходить одну и ту же часть, но намеренно будем проходить её каждый раз немного иначе, чтобы оценить возможную разницу от упомянутых ошибок тестера.
Начнем мы с игры BioShock, с первого полноценного уровня игры. На графике представлены достигнутые среднесекундные показатели частоты кадров на протяжении четырёх прохождений определённого участка этого уровня.
По графикам мы видим, что время прохождения было несколько разным, но слишком сильно оно отличалось только в одном случае (красный цвет). Этот вариант прохождения можно даже отбросить, как заведомо выбивающийся из ряда. Ход количества FPS на остальных линиях в целом совпадает, видна лишь небольшая разница в некоторых пиках FPS и разное время с повышенным значением частоты кадров в секунду в середине графика.
Однако, несмотря на то, что графики схожи, средние значения получились от 39,4 до 43,1 FPS, то есть 9,4% разницы, что слишком много, на наш взгляд, чтобы измерять производительность подобным образом. Конечно, можно отбросить значение 43,1, и тогда погрешность будет вполне приемлемой, но как определять эти «правильные» и «неправильные» измерения? Единственно верного метода нет, помогут многочисленные тесты, тщательный анализ и усреднение.
Следующей игрой будет Call of Duty 4, в своей «одиночной» версии не имеющая возможности тестирования по причине ошибок в коде. Мультиплеерная версия подходит для тестов, но это всё-таки не совсем то, что хочется тестерам. Мы попробовали проверить, насколько сильно будет отличаться средняя частота кадров при многократном прохождении бонусного уровня на самолёте:
Общий ход FPS и в этом случае схожий во всех проходах, наибольшее расхождение видно в конце прохождения уровня. Отбрасываем короткий красный проход, получаем разницу в 9,3% между полярными значениями, что также слишком много для того, чтобы принимать подобные измерения всерьёз. И даже если по какому-то принципу отбросить ещё один проход («бордовый», с максимальным значением среднего FPS), тогда получаем больше 3% погрешности.
Далее, рассматриваем два графика из гоночной игры DiRT, в которой нет средств тестирования производительности. Даже повторы нельзя записывать и воспроизводить. Мы протестировали два разных типа игры: состязание двух автомобилей на закольцованной трассе, которое больше зависит от видеокарты, и соревнование нескольких багги, сильнее зависящее от мощности центрального процессора системы. Интересно, будут ли сильно отличаться результаты в разных игровых режимах? Проверяем первый вариант:
Довольно ровная частота кадров, очень похожие графики во времени, кроме выделившегося красного. Если учитывать и его, то получаем 4,4% разницы между экстремальными значениями средней частоты кадров: 28,6 и 27,4. А если его отбросить, то получается всего 1% погрешности!
В таком случае метод измерения производительности при помощи FRAPS применять вполне можно. Единственное — нужны ещё более обширные тесты, чтобы перепроверить всё, и подтвердить пригодность такого тестирования. А мы посмотрим другой игровой режим DiRT, все ли они подходят для наших задач? Чем больше автомобилей (3D-объектов) на экране, тем больше разница в нагрузке на видеокарту, ведь ни один заезд в точности повторить невозможно…
Но и в этот раз получилась примерно такая же картина — графики уже меньше походят друг на друга, но в целом повторяются. Если учесть «красный» вариант, то получаем неприемлемые 9% разницы в производительности между 20,5 и 18,8, а если его убрать из рассмотрения как некачественный — то 2,6%, а такая погрешность близка к грани пригодности, хотя в приличных тестах практически не бывает и такого разброса как между 19,3 и 18,8 FPS.
Делаем вывод, что при дополнительном исследовании и тщательном анализе результатов, игру DiRT вполне можно применять для измерения производительности методом с использованием FRAPS. А сами продолжаем исследование. На очереди ещё одна аркадная гонка — Need for Speed: ProStreet:
Удивительно, но даже в этой игре, где каждый заезд уникален, все графики частоты кадров показывают похожую картинку. Разве что только «синий» график немного выбивается из колеи, на первый взгляд. Все графики примерно одинаково волнообразны, но давайте посмотрим, какая разница в средней частоте кадров у нас получилась в случае последней серии Need for Speed…
Сначала учитываем все четыре измерения. Между 24,7 и 22,2 FPS получается целых 11% разницы, что просто неприемлемо для полноценных тестов. И даже если убрать максимальный результат 24,7, то получаем почти 6% разницы между остальными цифрами. Можно, конечно, убрать ещё и отсчёт с 22,2 FPS, тогда получится 1,7%, а это уже нормально. Но всё это слишком походит на подгонку результатов…
Теперь смотрим довольно старую уже игру TES4: Oblivion, её очень любят использовать при измерении 3D-производительности многие тестеры. Мы специально взяли сцену внутри помещений, так как снаружи влияющих на FPS факторов даже больше, и мы уже исследовали эту игру в таких условиях в прошлый раз. Итак, четыре прохода части уровня Oblivion:
Получились очень разные графики FPS, скачущие туда-сюда, как попало. Понятно, что при тесте специально вносились небольшие погрешности — отходы от начальной траектории, повороты камеры, но это нормально и для тестера, так как никто не сможет повторить свой путь со 100% точностью несколько раз, да ещё в разные дни.
Снова убираем «красную» линию, так как она явно выбивается из числа остальных. Между максимальным значением 63,8 FPS и минимальным 55,4 FPS получаем 15% разницы, что крайне много. Подобные «тесты» не подходят для измерения скорости видеокарт. Попробуем отбросить ещё и максимальное значение, как в предыдущие разы. Получаем 9% разницы между близкими, казалось бы, значениями: 60,4 и 55,4… Явно слишком много, не подходит Oblivion под нашу задачу.
И последняя игра — гоночная Test Drive: Unlimited, которая отличается ровным FPS, и поэтому потенциально может подойти для измерения скорости даже в условиях отсутствия возможности записи и проигрывания демо-записей. Смотрим:
Очень похожий ход графиков. Видно, что частота кадров в секунду очень ровная, около 25 кадров в секунду, и опускается она только в момент старта, когда идёт дым из-под колёс автомобилей соперников. Да и по значениям среднего FPS видно, что результаты могут получиться неплохими.
Но это не так… Разница между максимальным значением 24,3 FPS и минимальным 22,8 FPS получилась 6,6%, что меньше, чем во всех предыдущих случаях, но всё-таки слишком большая, чтобы считать погрешность измерений приемлемой. А если отбросить максимальный результат? Всё равно 5%, а это многовато для нормальных тестов, где погрешность не должна быть выше 2-3%.
Выводы
Подводим итоги очередного исследования, посвященного методике тестирования при помощи FRAPS. Тесты с четырёхкратным повторением на каждой системе без обработки результатов слишком грубы и могут дать погрешность до 10-15%, что совершенно неприемлемо! Даже, несмотря на то, что частота кадров во многих играх сравнительно стабильна и на графиках видны схожие пики, разница в среднем FPS иногда получается слишком большой. На основе таких тестов сравнивать производительность видеокарт мало смысла, так как разница между разными моделями видеокарт порой не достигает и 10%. И даже если проводить 4-10 измерений, внимательно следить за проведением тестов, и обрабатывать результаты, отбрасывая аномальные, невозможно быть уверенным в получаемых цифрах.
Это не говоря об огромной разнице в достигнутых максимальных и минимальных показателях FPS. Ведь игровая ситуация в каждой игре каждый раз несколько отличается, идентичности 3D сцены раз от раза не достичь. Например, во многих гоночных играх на частоту кадров влияет многое: изменяющаяся погода, время суток, плотность транспортного потока (если трафик на дорогах есть), каждый раз отличающееся поведение управляемых компьютеров соперников, умения самого игрока. Каждый раз сцена другая, и частота кадров поэтому довольно сильно отличается. В таком случае может помочь разве что многократное тестирование и отбрасывание заведомо аномальных результатов.
С современными играми жанра шутер от первого или третьего лица всё ещё хуже. В них повторить игровую ситуацию ещё сложнее, каждая попытка прохождения части уровня приносит что-то отличное от других. Ведь в современных играх противники обладают искусственным интеллектом, используют сложные скрипты для поведения, каждый раз действуя по-своему. Поэтому если для измерения производительности в игре тестеры применяют описанный выше метод загрузки сохранения и прохождения части уровня, то можно сказать точно — пройти несколько раз одинаково невозможно, если продолжительность тестового отрезка достаточно велика.
Есть ещё вариант — покрутиться вокруг без прохождения уровня или даже просто снять мгновенный FPS после загрузки. Да, какой-то смысл для сравнения производительности разных карт будет в таком случае. Но он явно хуже полноценного тестирования в тех играх, которые предоставляют все удобные средства для этого, хотя может и лучше, чем ничего.
Итак, главные выводы, перекликающиеся с выводами, сделанными в прошлом материале. Тесты производительности 3D-игр с применением FRAPS можно, но со следующими оговорками и ограничениями:
- метод следует применять для тестирования тех игр, где нет встроенных возможностей для измерения производительности, но есть возможность записи и проигрывания демо-записей или повторов. В данном случае погрешность измерений может быть близкой к той, что мы получаем в играх со встроенными бенчмарками;
- в тех играх, где есть возможность вывода неизменной каждый раз анимации, использующей игровой движок, тестирование производительности с FRAPS использовать также можно, но с учётом того, что это будет не тестирование производительности игры, а тестирование производительности рендеринга скриптовых роликов. То есть, вполне подходит для интерактивных игр, где большая часть времени занята такими сценками;
- в случае игр без таких возможностей, нужно предварительно тщательно исследовать их пригодность для тестирования. Провести пару десятков прохождений одного и того же уровня, чтобы определить максимальную погрешность. Только в случае небольшой разницы до 3%, применять такую игру и метод допустимо;
- но даже в случае всех перечисленных вариантов, нужно осторожно относиться к полученным при помощи FRAPS результатам. Чтобы получить достоверные результаты, необходимо на каждой испытываемой системе повторять тест по несколько раз, минимум 4-5 отсчётов. После этого необходима обработка результатов, тщательный анализ каждого прогона, определение и отбрасывание явно аномальных цифр и усреднение остальных. Только в таком случае получится достоверный результат.
Всё вышеперечисленное приводит к огромному увеличению трудоёмкости 3D-тестов, если к этому приплюсовать и отсутствие реальной возможности автоматизации, за исключением установки фиксированной продолжительности теста, а, следовательно, и увеличения необходимого на тесты времени. Прибавляем ко всему сказанному немаленькую погрешность даже в случае многократных повторений и получаем низкую пригодность подобного метода измерения 3D-производительности для материалов вроде i3D-Speed.
Для игр без возможности воспроизведения повторяемых сцен, тестирование с FRAPS таит слишком много опасностей с ошибками тестера при снятии цифр и их анализе. Разброс результатов может быть слишком большой, и 9-10% являются неприемлемыми цифрами. Конечно, можно придумать методы смягчения влияния человеческого фактора и различий в игровой ситуации. Например, в гоночных играх можно выбрать кольцевую (или даже прямую) трассу без трафика и соперников, а в FPS играх найти ровное место без врагов и идти по ней по прямой недолгое время… Но будут ли такие результаты соответствовать реальному положению дел? Такое синтетическое тестирование ничем не лучше тестов в том же 3DMark…
В очередной раз хотим попросить разработчиков игр, чтобы они прислушались к людям, интересующимся 3D-графикой и технологичными играми. Если бы современные и технологичные игры имели качественные возможности тестирования, поддающиеся автоматизации, то и трудностей у тестеров было бы гораздо меньше. И данная статья была бы ненужной.
А мы в своих материалах пока будем продолжать использовать приложения с встроенными бенчмарками. Так как методы, рассмотренные в статье, использовать хоть и можно, но осторожно, в единичных случаях, по несколько раз проводя тесты и тщательно проверяя достоверность всех результатов. И обязательно нужно публиковать подробную методику тестирования, каким образом проводятся тесты производительности.
