Методика тестирования видеокарт 2007. Использование FRAPS.

Предисловие

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

Однако, несмотря на трудности использования FRAPS, мы уже начали использовать ее для тестирования видеокарт в таких играх, как Need for Speed Most Wanted и Carbon, Elders Scrolls IV Oblivion, Titan Quest и других, потому что нам удалось разработать методику получения стабильных и качественных результатов с помощью этой утилиты. Каким образом? Читайте далее.

FRAPS. Точный инструмент или «кувалда с оптическим прицелом»?

Сначала давайте еще раз вспомним, что такое FRAPS. Это утилита, которая способна измерять скорость отрисовки сцены и вычислять минимальный, максимальный и средний FPS. В данном исследовании мы будем рассматривать эти возможности как основное предназначение программы. Что касается снятия скриншотов и видеороликов, то данные возможности программы мы пока не будем рассматривать подробно. Итак, FRAPS умеет измерять FPS. Много это ли мало? Возьмусь утверждать, что этого вполне достаточно для того, чтобы считать FRAPS точным и универсальным инструментом для измерения производительности видеокарт в играх.

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

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

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

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

А теперь давайте подумаем - является ли все указанное недостатками именно утилиты FRAPS? Вряд ли. Обратите внимание, все вышеперечисленное это не погрешности измерения, вносимые утилитой, это - погрешности обусловленные способом измерения. В силу того, что данный способ измерения является единственно возможным при использовании FRAPS, часто погрешности способа измерения приписывают погрешностям самой утилиты, причем совершенно не заслуженно. Вы можете возразить - а что же делать, способ измерения единственный и другого нет! Конечно. Но даже в этих условиях можно получить вполне достоверные результаты, причем с большой точностью и информативностью. То, что FRAPS не очень удобна для тестирования, тем более автоматизированного - это правда. Но зато с ее помощью можно получать куда более интересные результаты, причем, если хорошенько подумать, и усилий это не так много требует, как кажется на первый взгляд. Как это сделать, мы расскажем дальше. Но сначала необходима…

Проверка результатов FRAPS на встроенных в игры бенчмарках

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

Для экспериментов был использован наш обычный тестовый стенд

В данный стенд была установлена видеокарта ASUS 7950GT. Для тестирования использовались драйверы ForceWare 93.71 WHQL.

Мы взяли хорошо известную игру F.E.A.R. и прогнали встроенный тест производительности, при этом одновременно запускали FRAPS. Режим тестирования - 1280х960, Video Max, 4AA/16AF, Soft Shadows OFF. Вот что получилось в итоге.

Утилита FRAPS выдала следующие результаты (тест прогонялся 3 раза):

Эти данные взяты из файла с окончанием « … minmaxavg.csv», генерируемого утилитой. Как видите, несмотря на «человеческий фактор», результаты тестирования очень близки между собой и вполне укладываются в пределы погрешности. Удивительно, но FRAPS показывает даже чуть большие результаты, чем встроенный бенчмарк в F.E.A.R., хотя более логична была бы обратная ситуация, ведь утилита использует ресурсы системы, и могла бы ее «притормаживать». Конечно, то, что использовалась одна и та же демо-сцена, облегчило задачу по получению стабильных результатов. Из случайных погрешностей оставалась погрешность времени старта-стопа FRAPS. Но, если общее время тестирования достаточно велико, данная погрешность практически не сказывается на конечных результатах. Аналогичным образом мы протестировали также DOOM3, Half-Life 2 и несколько других игр, и получили схожие результаты.

Вывод - FRAPS выдает вполне адекватные результаты, совпадающие (с незначительной погрешностью) с результатами встроенных в игры бенчмарков.

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

Давайте сначала посмотрим на содержимое файла результатов FRAPS, оканчивающегося на «… fps.csv». Ниже приведен фрагмент файла, в котором содержится всего один столбец данных - значение FPS в каждую секунду с момента старта утилиты.

Усреднением полученных значений мы и получаем привычный нам средний FPS. Отсюда же легко можно узнать минимальный и максимальный FPS для тестируемой демо-сцены. Собственно, эти данные и являются основой для вычисления значений, указанных в файле результатов « … minmaxavg.csv». Но сейчас подробные данные о значении FPS в каждый момент времени нам полезны тем, что мы можем легко построить график изменения FPS в зависимости от времени. Вот так он выглядит для тестов F.E.A.R. в наших условиях тестирования.

Мы дополнили получившийся график описанием характерных сцен, имеющихся в встроенном демо F.E.A.R. Жирная синяя линия отмечает значение среднего FPS, которые выдает встроенный тест. Как видите, практически половину времени теста занимает сцена перестрелки, при этом значения FPS в этой сцене заметно ниже результирующего среднего и находятся на уровне около 40 FPS. В то же время, «беготня по коридорам» не сильно нагружает видеокарту. На значительном участке FPS зашкаливает за 100 и в итоге мы получаем средний FPS равный 59. Вывод отсюда очень простой - встроенное демо F.E.A.R. больше тяготеет к демо, призванному показать «красоты» графического «движка» (вода + огонь), и дает несколько завышенный FPS по отношению к реальному геймплею (перестрелка). Конечно, в реальности, играя в игру, без прогулок по коридорам не обойдешься. Но согласитесь, более важно иметь высокий FPS в ответственные моменты, когда нападают враги, а уж «на коридоры» мощности видеокарты точно хватит. То есть, с точки зрения игрока, для получения FPS, адекватного типичному геймплею данной игры, из встроенного теста следует взять только сцену перестрелки. Тогда в нашем случае средний FPS был бы равен 42,8. Сравните это число со средним значением 59, выдаваемым встроенным тестом, и почувствуйте разницу.

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

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

Физический смысл данного представления прост - высота столбца показывает, сколько времени (в данном случае в секундах) значение FPS находилось в пределах данного диапазона. Как видим, полученная картина распределения FPS весьма неравномерна. Большинство значений FPS расположены в диапазоне от 30 до 70 FPS, а оставшаяся часть образует «хвосты». Говоря обычным языком - большую часть времени теста значение FPS колеблется от 30 до 70, и относительно редко «выстреливает» выше. На диаграмме также отображены две вертикальные линии. Синяя линия соответствует среднему значению FPS, выдаваемому встроенным тестом, красная соответствует среднему значению FPS для сцены «перестрелка».

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

Какой нам прок от такого вида представления данных, мы расскажем чуть ниже, но сначала необходимо сделать лирическое отступление, и вспомнить некоторые моменты из раздела прикладной статистики. Давайте еще раз взглянем на диаграмму распределения FPS и поразмышляем - каков мог бы быть «идеальный» вид данной диаграммы? В качестве исходных данных мы имеем множество значений FPS. Как они должны распределяться в идеальном случае? Понятно, что в жизни мы вряд ли получим на диаграмме тонкую вертикальную линию, точно соответствующую какому-либо одному значению FPS. Ситуация в игре постоянно меняется, тут выстрелы, там взрывы, враги бегают по уровню и строят козни. Скорее всего значения FPS будут находиться в некотором диапазоне. При этом нам, как игрокам, хочется, чтобы этот диапазон (то есть разброс FPS) был бы не очень большим, иначе при очень низких значениях FPS будут наблюдаться «лаги». Слишком высокие значения FPS нам тоже не особо нужны. Даже профессиональные геймеры не в состоянии увидеть больше 100 FPS, поэтому что 100, что 200, что 500 FPS - разницы мы не увидим. Поскольку ситуация в игровой сцене может меняться случайным образом, разумно будет предположить, что диаграмма распределения FPS в идеале должна быть симметричной.

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

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

Вы, наверное, разочарованы? Ведь полученная нами диаграмма распределения FPS выглядит куда «топорнее» и совсем не похожа на гладкую линию графика распределения Гаусса. На самом деле ничего страшного. Просто у нас очень мало значений FPS, поэтому и статистические методы на таком малом множестве значений работают неохотно. Где же нам взять еще значений? Увеличить время тестирования? Есть метод лучше. Вот мы наконец и подобрались к ключевому моменту нашего повествования.

В чем таится мощь FRAPS

Сейчас мы покажем вам, где искать необходимое нам количество значений FPS. По завершении тестирования замечательная утилита FRAPS создает еще один файл - « … frametimes.csv».

Здесь все просто. Числа слева - порядковый номер кадра, справа - время в миллисекундах, прошедшее с начала теста. Именно здесь и кроется самое важное! Чтобы было понятно, дополним эти столбцы еще двумя, как показано ниже.

Два столбца слева мы оставили в прежнем виде. А вот насчет двух других стоит поговорить поподробнее. Столбец frametime получен из столбца time следующим образом - для каждого кадра (строки в таблице) мы из текущего значения времени вычли предыдущее. Таким образом, значения в столбце frametime показывают, сколько времени рендерился (рисовался) каждый кадр. Ну а дальше просто, осталось только преобразовать это в привычные значения FPS. Из времени рендеринга кадра легко получить мгновенное значение FPS - для каждого frametime в таблице надо взять обратную величину, и умножить ее на 1000 (поскольку время у нас в миллисекундах). Таким образом, получаем четвертый столбец, содержащий мгновенные значения FPS для каждого кадра!

Вернемся к нашим тестам F.E.A.R. Как легко подсчитать, использование в качестве источника данных файла « … frametimes.csv» дает уже не 53 отсчета значений FPS, а уже порядка 3000 отсчетов (продолжительность теста в секундах умножить на средний FPS). А с таким объемом данных работать уже интереснее.

Посмотрите, как преобразился первоначальный график зависимости FPS, вся его «тонкая структура» прекрасно проявилась. Видны как резкие взлеты мгновенных значений FPS, так и провалы. Давайте попробуем вычислить минимальное и среднее значение FPS на обновленном объеме данных. В итоге средний FPS получается равным не 59, как показывает встроенный тест, а даже 75.36. Приятно видеть возросший FPS, но ведь условия тестирования не изменились! С минимальным FPS все ровно наоборот. Вместо 30, как было, мы имеем всего лишь 11,97 FPS. А это значит, что будут «лаги».

Ну а что покажет диаграмма распределения FPS?

Вид диаграммы изменился не так разительно, разве что она стала немного «плотнее» и детальнее. Видно, что основная масса мгновенных значений FPS все так же расположена в диапазоне от 30 до 70 и образует «основной колокол», а вообще все это напоминает спектр радиосигнала - несущая частота с полезным сигналом (определенной ширины) плюс более высокие гармоники. Конечно, «колокол» распределения далеко не идеальный, но уже что-то. Кстати, если отбросить все значения FPS выше 70-ти и подсчитать среднее, то получим, что средний FPS будет равен 45.1, что довольно близко к предыдущему значению 42.8.

Как видите, даже встроенный тест FEAR оказывается далеко неоднозначным к способу вычисления итогового результата. Какой же из них «достовернее» - 42.8, 45.1, 59 или 75 FPS? Мне лично кажется, более достоверным является значение 42,8 FPS. Такое оно, без самообмана.

А теперь давайте посмотрим, что же будет, если мы по такой же методике попробуем обработать результаты в NFS Most Wanted.

Тестирование в NFS Most Wanted с помощью FRAPS

Тестовый стенд и видеокарта все те же. Мы выбрали кольцевую трассу «Ironwood», ехали по ней два круга, при этом соперников было трое, дорожный трафик - максимальный. То есть, условия игры вполне реальные, и совершенно непредсказуемые с точки зрения повторяемости. И дождь идет, и темнеет-светлеет, да и соперники ведут себя на трассе совершенно по-хулигански. Теперь возьмем файл результатов « … frametimes.csv» и построим сначала график мгновенных значений FPS, а затем диаграмму распределения.

Как видите, значения FPS довольно равномерно распределены вокруг уровня около 60 FPS. Если быть точнее, среднее значение равно 59.2 FPS.

Вид диаграммы распределения более похож на «колокол», чем в тесте F.E.A.R., причем без всякого отбрасывания «лишних гармоник». Вертикальная красная линия, как и прежде, отмечает среднее значение FPS и, находится практически посередине нашего воображаемого «колокола». А значит можно сказать, что полученное среднее значение FPS вполне достоверно, и отражает реальную производительность видеокарты в данной игре.

Вернемся к графику FPS и его разбиению на четыре части. Мы сделали это для того, чтобы прояснить следующий вопрос - как долго нужно гонять по трассе, чтобы получился нормальный «колокол». Другими словами - Как форма диаграммы и среднее значение FPS, получаемое с помощью FRAPS, зависит от времени тестирования.

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

Первая четверть. Время тестирования равно 42 с, среднее значение равно 56,5 FPS. Диаграмма распределения совершенно непохожа на «колокол».

Две четверти (первый круг). Время тестирования равно 84 с, среднее значение равно 59,9 FPS. На диаграмме потихоньку вырисовывается искомый «колокол».

Три четверти. Время тестирования равно 126 с, среднее значение равно 58,8 FPS. Принципиальных отличий от предыдущей диаграммы нет. «Колокол» становится более вытянутым, но его форма практически не меняется.

Четыре четверти (два полных круга). Время тестирования равно 169 с, среднее значение равно 59,2 FPS.

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

Итоговый ряд средних значений FPS для каждого отрезка выглядит так - 56.5, 59.9, 58.8, 59.2. Как видите, только значение для первой четверти сильно отличается от трех остальных. Если его отбросить (согласно сформулированному критерию) и найти среднее из средних для каждого участка, получим - 59,3 FPS. При этом отклонение составляет около 0,6 FPS в каждую сторону, то есть, всего ± 1% !

В нашем случае, при тестировании NFS Most Wanted достаточно «проехать» один круг по трассе (84 сек времени тестирования) или полтора круга (126 сек времени тестирования). Зная время тестирования и среднее значение FPS, можно приблизительно оценить общее количество отсчетов по следующей формуле - «время тестирования умножить на среднее значение FPS». Таким образом, необходимое число отсчетов, когда начинает работать статистический метод, равно 5000-7000. Мы неслучайно обращаем ваше внимание на данный момент. Если взять достаточно слабую видеокарту, средний FPS будет гораздо ниже, следовательно, уменьшится и суммарное число отсчетов, если время тестирования остается неизменным. Поэтому при тестировании «слабых» видеокарт время тестирования желательно увеличивать.

Выводы

Утилита FRAPS является мощным и точным инструментом исследования производительности видеокарт. Чтобы получить достоверные данные, необходимо:

• выбрать демо-сцену, адекватную типичному геймплею
• проводить тест в течении достаточного времени
• использовать файл результатов FRAPS вида « … frametimes.csv»
• после преобразования исходных данных файла « … frametimes.csv» вычислять искомые значения среднего FPS и, при желании, минимального и максимального FPS.

Заключение

С помощью вышеописанного метода тестирования с использованием FRAPS и последующей обработки данных можно получить весьма точные и адекватные значения производительности видеокарт в играх, не имеющих встроенного бенчмарка. Более того. Указанным способом можно проанализировать «качество» демо-сцен во встроенных в игры бенчмарков, а также получить представление о характере игрового «движка».

К сожалению, за рамками данного материала пришлось оставить один весьма животрепещущий вопрос - что же считать минимальным значением FPS. Как вы видели на примере встроенного теста F.E.A.R., значения минимального FPS, показываемые встроенным бенчмарком, могут сильно расходиться с действительностью. Поверьте, это только вершина айсберга. Вопрос требует тщательного исследования. Но об этом мы расскажем в следующий раз.

Источник: 3dnews.ru