Методика тестирования видеокарт 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, поэтому и статистические методы на таком малом множестве значений работают неохотно. Где же нам взять еще значений? Увеличить время тестирования? Есть метод лучше. Вот мы наконец и подобрались к ключевому моменту нашего повествования.