Содержание

• Введение
• Проблемы измерения 3D-производительности
• Аппаратная конфигурация и системные требования
• Тестовый набор и методика тестирования
• Результаты экспресс-тестирования
• Выводы

Введение

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

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

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

Неравномерность FPS очень сильно влияет на восприятие видеоряда человеком, и она заметна даже при высокой частоте кадров. Даже при стабильных 25-30 кадрах в секунду в большинстве игр, не требующих молниеносной реакции, как некоторые сетевые игры, комфортность игры будет вполне достаточной. И наоборот, даже при частоте кадров выше 60, но при неравномерной их отрисовке, если один кадр будет рисоваться 10 мс, а следующий — 30 мс, такие рывки FPS будут хорошо чувствоваться.

Именно FRAPS тогда помог идентифицировать и разобраться в проблемах с плавностью рендеринга на многочиповых видеосистемах. Этот феномен с высоким FPS, но недостаточной плавностью в виде неприятных рывков, был назван «microstutter» — он проявляется в виде мелких и противных рывков в смене кадров при, казалось бы, высоком FPS. Уже тогда стало понятно, что некоторые многочиповые системы страдают от проблемы больше других, но она присуща почти всем из них. Мы неоднократно писали и об этом, хотя до детального исследования проблем многочипового рендеринга дело тогда так и не дошло.

И вот недавно появилась еще одна возможность еще более точного определения 3D-производительности в виде частоты кадров в секунду, максимально приближенная к тому, что человеческий глаз видит на экране монитора. И сегодня мы расскажем о новейшем методе исследования производительности рендеринга в играх — пакете Frame Capture Analysis Tool (FCAT) компании Nvidia, который служит для анализа захваченных кадров, полученных на системах с одночиповыми и многочиповыми видеосистемами.

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

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

В случае FCAT же используется метод анализа кадров (измерения количества кадров в секунду), которые реально дошли до вывода на экран. Одними лишь программными методами обойтись в данном случае сложно, поэтому для FCAT используются программно-аппаратные решения. В качестве аппаратной части используется высокопроизводительная карта захвата изображения, а программная заключается в добавлении к изображению специального «оверлея» — цветной полоски в левой части кадра, который отмечает границы отрисованных кадров. Комплектные утилиты FCAT анализируют эти цветные полоски и их размер и определяют время, занятое отрисовкой каждого из кадров, выделяя никогда не показанные на экране. Специальные скрипты анализируют собранные данные и выводят их в виде диаграмм и таблиц.

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

Чтобы читатели понимали, зачем понадобилась разработка такого пакета как FCAT, необходимо подробно рассказать о том, как проходит тестирование и на каких этапах возможно измерение 3D-производительности. И начнем мы с рассмотрения того, как работает вся цепочка от игрового движка до монитора. Главная проблема заключается в том, что графические чипы и дисплеи работают с разной скоростью вывода кадров, кроме случая с форсированной вертикальной синхронизацией, когда частота приводится к единой.

В случае с выключенным VSync, а именно таким образом измеряется 3D-производительность, графический(-ие) чип(-ы) отрисовывает кадры так быстро, насколько это возможно, и отправляет их на дисплей, который показывает их с фиксированной частотой (обычно 60 раз в секунду). Так получается потому, что GPU в разные моменты времени тратят на рендеринг каждого кадра разное время — в зависимости от сложности сцены. То есть, видеочип может отрисовывать кадры с частотой 20, 50 или даже 100 кадров в секунду, независимо от частоты обновления дисплея. Но устройство вывода всегда работает на фиксированной частоте, в большинстве случаев отрисовывая каждый кадр за 16 мс, что дает 60 кадров в секунду, отсюда и возникают проблемы с синхронизацией двух разных частот.

Программные средства измерения 3D-производительности, вроде уже упомянутого FRAPS, получают информацию о кадрах, выходящих из игрового движка в виде команд графического API. Но получаемая при помощи таких утилит цифра не всегда соответствует действительности, и дисплей может показывать меньше кадров, чем выходит из GPU. А FCAT замеряет частоту кадров в секунду, именно выводящуюся на дисплей, а не отрисованную в кадровом буфере, так как для захвата реально показанных на дисплее кадров используется аппаратная плата видеозахвата. Давайте разберемся с этим подробнее:

Параметр t_game — это время, которое игровой движок тратит на внутренние расчеты (искусственный интеллект, пользовательский интерфейс, физические расчеты и т.д.). t_present — это момент, в который игровой движок передает данные о кадре в графический API (чаще всего DirectX), и именно в это время чисто программные методы измерения 3D-производительности, вроде FRAPS, и снимают свои показатели, считая, что кадр в любом случае появится на дисплее.

Но после этой точки еще много чего происходит — DirectX передает данные графическому драйверу, тот обрабатывает вызовы API и отправляет их в аппаратно-специфичном виде на GPU (в единственном или множественном числе), который производит рендеринг кадра и только затем он выводится тем же видеочипом на дисплей. t_render — это момент уже после того, как кадр отрисован и готов к отсылке на дисплей, ну а t_display — время, когда кадр отображен на дисплее полностью (с включенной вертикальной синхронизацией) или частично. И на рисунке хорошо видна разница между отрезками, которые используют в своей работе FRAPS и FCAT. Пакет Nvidia, который мы сегодня рассматриваем, берет данные об отрисованных кадрах в самый последний момент, когда они уже точно обработаны целиком — и графическим API и драйвером и GPU.

На рисунке показано, что программные методы (в виде FRAPS) измеряют FPS не совсем корректно — не частоту выведенных на экран кадров, а частоту отданных на отрисовку видеодрайверу. FRAPS захватывает вызовы функций Direct3D из игрового движка еще до того, как данные и команды реально доходят до GPU. Эти операции могут занимать разное количество времени, в зависимости от сложности сцены в кадре, и анализ реально выведенных на дисплей кадров может давать иные цифры производительности.

Для плавной смены частоты кадров, в идеале они должны показываться с одной частотой, т.е. время на вывод каждого из них должно быть одинаковым (как в случае с VSync и достаточно высокой производительности GPU). Но в реальности при отключенном VSync такое практически невозможно, и кадры отрисовываются за разное время. На следующем рисунке показаны кадры, полученные при помощи FCAT, следующие по порядку и примерно равного размера:

В процессе разработки FCAT, в Nvidia обнаружили, что программные методы определения 3D-производительности (измерения времени построения кадров) имеют недостатки, считая некоторые из не отрисованных на экране кадров. Такие программы как FRAPS, измеряют время отрисовки тех кадров, которые переданы от игрового движка к DirectX API, но не тех, которые реально были рассчитаны и выведены на экран. Программные методы упускают два типа важных недостатков с точки зрения плавности видеоряда — «отброшенные» кадры (drop frames) и «неполноценные» кадры (runt frames) - кадры со слишком малой длительностью.

Чтобы их было легко выделить, оверлей FCAT добавляет в кадре слева цветную полоску, где каждый отрендеренный кадр имеет свой цвет, и порядок следования этих цветов — строгий. Каждый отрисованный на дисплее кадр сопровождается полоской одного из 16 основных цветов, следующих по порядку. При анализе захваченного по DVI видеоряда, проверяется соответствие порядка цветов (отброшенный кадр) и определяются неполноценные кадры — по сверхмалой длительности. Вот так выглядит обработанный оверлеем FCAT кадр, где все кадры, полученные от GPU, были отрисованы в реальности (по порядку — фиолетовый, оливковый, серый и пурпурный.

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

Такое ПО как FRAPS, никогда не узнает о том, что какие-то кадры не были полностью обработаны в GPU и не выведены на экран, он их считает отрисованными полностью. И в случаях, когда таких кадров было отброшено значительное количество, FRAPS завышает производительность в кадрах в секунду, не учитывая эти не рассчитанные GPU и не показанные на экране кадры.

Вот как выглядит отброшенный кадр на экране после обработки FCAT — мы видим, что второй кадр попросту не был выведен на экран, так как полоски с оливковым цветом нет в левой части кадра между серой и пурпурной.

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

В случае FCAT, за неполноценные кадры принимаются те кадры, длительность отрисовки которых составляет 20 линий и менее — то есть, длина полоски оверлея FCAT не превышает 20 пикселей и очень слабо различима даже на FullHD устройствах, не говоря уже о дисплеях более высокого разрешения, вроде 2560×1440(1600). Программными методами, вроде FRAPS, такие кадры также считаются полностью отрисованными и показанными пользователю, и в некоторых случаях доля неполноценных кадров в общем потоке довольно велика.

На следующей иллюстрации показан такой неполноценный кадр — между полосками серого и фиолетового цвета заметна маленькая область оливкового цвета — это и есть кадр со сверхмалым временем отрисовки.

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

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

Конечно, в идеале нужно знать «внутренний FPS» игры, и сравнивать его с тем, что получается на DVI-выходе (FCAT) — разница в этих показателях помогла бы опознать проблемы с плавностью, но доступа к этой информации игровые разработчики не дают. Но и то, что дает тестерам FCAT, уже намного точнее, чем полученные значения средней частоты кадров на выходе из игрового движка.

Аппаратная конфигурация и системные требования

Захват выводимых на цифровые порты (к примеру, DVI) кадров довольно сложен. Хотя для анализа решений одного производителя (в нашем случае — Nvidia) можно было бы обойтись чисто программными методами, так как драйвер может выдать информацию и о выведенных на экран кадрах. Но программные методы могут быть довольно легко обмануты модификациями в драйверах, которые скроют проблемные места при захвате, поэтому желателен метод, который анализирует именно реально выведенные на DVI-разъем кадры, и для этого нужна аппаратная карта захвата, установленная еще и на отдельном ПК.

Так что для анализа производительности методом FCAT нужно два ПК — основная игровая система и система захвата. В качестве игровой может использоваться обычный тестовый ПК, используемый для тестов одночиповых и многочиповых конфигураций видеосистем. А вот к системе захвата есть несколько специфических требований. Главное требование — установка карты захвата (о ней см. ниже) в свободный PCI-Express x16 слот.

К центральному процессору и чипсету нет особых требований, но рекомендуется применение CPU компании Intel семейства Ivy Bridge и чипсет Intel Z77. Причем скорость CPU не важна, а вот проблемы совместимости карты захвата с некоторыми чипсетами имеются. К примеру, карта захвата VisionDVI-DL не всегда корректно работает на системных платах, основанных на чипсете Intel X79, и требуется использовать последнюю версию BIOS, а также, возможно, даже отключить неиспользуемые при работе FCAT возможности вроде USB 3.0, второго Ethernet-контроллера и т.д.

Но самым серьезным является требование к скорости записи захваченного видео на накопитель. Понятно, что в несжатом виде генерируется просто гигантское количество данных на скорости до 650 мегабайт в секунду (в случае разрешения 5760×1440). И поэтому в системе захвата должна использоваться и высокопроизводительная система хранения данных — на основе нескольких SSD-накопителей, работающих в RAID. Реально необходимый поток данных в разрешении 2560×1440 на 60 Гц составляет порядка 500 МБ/с, поэтому при работе понадобится весьма высокопроизводительная система хранения данных.

Рекомендуется использовать не просто очень быстрые твердотельные накопители, но от двух до четырех дисков объединить в конфигурации RAID 0, чтобы обеспечить требуемую пропускную способность. Четыре быстрых твердотельных накопителя способны дать скорости до 1 ГБ/с, так что на практике во многих случаях хватит и двух топовых SSD-дисков, объединенных в RAID 0. Кроме высокой скорости записи накопителей, понадобятся и приличные объемы для промежуточного хранения захваченных видеоданных — записанный AVI-файл для каждой минуты видео в разрешении 2560×1440 содержит примерно 25 ГБ несжатых данных.

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

Для захвата изображения с разъема DVI компания Nvidia предлагает использовать высокоскоростную плату, установленную в отдельной системе. Карта захвата DataPath VisionDVI-DL считывает кадры, поступающие на DVI порт в высоком разрешении и на частоте в 60 кадров в секунду, что является самой распространенной частотой обновления для устройств отображения — мониторов и телевизоров. Карта захвата VisionDVI-DL работает как обычный монитор и для системы выглядит еще одним дисплеем, корректно отдающим видеокарте данные о своих возможностях (EDID — extended display identification data). В драйвере карты захвата можно эмулировать любой монитор с разрешением до 2560×1440 при частоте обновления, равной 60 Гц.

Карта захвата DataPath имеет достаточную пропускную способность, чтобы обеспечить работу в разрешениях 1920×1080, 1920×1200 и 2560×1440. Более высокие разрешения, вроде 2560×1600 и 5760×1600 требуют большей пропускной способности и такое изображение не может быть захвачено с использованием VisionDVI-DL карты. Впрочем, для технологий Nvidia Surround и AMD Eyefinity остается разрешение 5760×1080, в котором изображение может быть захвачено — суть в том, что для анализа и тестирования нужно изображение с разрешением 1920×1080 только с левого монитора в тройке, ведь именно оно содержит необходимую для анализа информацию в виде цветных полосок.

Ну и последним аппаратным устройством, необходимым для работы FCAT, является DVI-разветвитель. Он нужен только для захвата видео с многочиповых видеосистем производства компании AMD, так как Nvidia в режиме SLI позволяет выводить одинаковое изображение на два DVI-разъема в режиме клонирования, а AMD CrossFire такой возможности не имеет. Так что DVI-разветвитель не нужен для захвата со всех решений Nvidia, и одночиповых и многочиповых.

В качестве разветвителя Nvidia рекомендует использовать Gefen DVI DL Splitter, содержащий три DVI разъема: один входной и два выходных. Разветвитель позволяет вывести данные, полученные по одному Dual Link DVI разъему на два разъема одновременно. Соединение кабелей в тестовой FCAT системе выглядит так. Игровая система соединена с входным разъемом разделителя кабелем Dual Link DVI. Первый выходной порт соединяется с монитором игровой системы, а второй — с картой захвата VisionDVI-DL, установленной в системе захвата. Так что всего потребуется три Dual-Link DVI кабеля, причем они должны поддерживать передачу изображения в высоком разрешении (выше FullHD).

Тестовый набор и методика тестирования

Пакет утилит FCAT может использоваться всеми желающими, но Nvidia пока что не выложила его на своём сайте. Текущую версию пакета на момент публикации материала можно скачать с нашего сайта — FCAT 1.6, но работа над усовершенствованием инструментов сотрудниками компании всё ещё ведётся, так что это ещё не финальная версия.

А чтобы наши читатели смогли повторить процесс самостоятельно (при наличии соответствующего оборудования) и у них не оставалось вопросов о принципе работы набора FCAT, мы постарались подробно описать процесс тестирования. В состав комплекта программного обеспечения FCAT входят следующие утилиты:

• Overlay (EnableOverlay.exe и DXFrameOverlay.dll) — небольшая утилита, добавляющая к отрендеренному изображению последовательность цветных полосок, отражающую процесс формирования изображения из нескольких кадров;
• Extractor (Extractor.exe) — утилита, анализирующая захваченную последовательность кадров в виде AVI-файла, выводящая результат в виде XLS-таблицы;
• Пакетные (batch) файлы для запуска Perl-скриптов для анализа;
• Perl-скрипты (fcat.pl, gen_percentiles.pl, pivot.pl) — анализируют полученные результаты, идентифицируют пропущенные кадры, генерируют результирующие CSV-файлы и диаграммы, удобные для сравнения нескольких решений.

Эта утилита — единственная, которая запускается на игровой системе FCAT. Она просто добавляет в левой части кадра к отрисованному игровым движком кадру специальные цветные полоски из 16-цветного набора, указывающие на длительность игровых кадров, сгенерированных графическими чипами в пределах изображения на дисплее.

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

Запуск этой утилиты — самое первое действие, которое нужно сделать перед измерениями производительности. Интерфейса у утилиты Overlay нет, она работает в фоне и показывает единственное текстовое окно, на котором отображается одна строчка текста. Это окно можно минимизировать или перетащить в другое место. Важно, что включение оверлея на игровой тестовой системе практически не сказывается на итоговой производительности.

Теоретически, Overlay работает совместно с FPAPS, но не всегда. Для корректной совместной работы этих утилит, нужно запускать сначала FRAPS, а затем FCAT. Если в Windows 7 никаких проблем с такой сдвоенной конфигурацией нет, то в Windows 8 эта связка ПО работает некорректно. Захват видео при помощи VirtualDub

VirtualDub — свободная утилита для захвата и монтажа видео, лицензированная на условиях GPL, удобная для использования в рамках тестирования с применением FCAT (хотя можно попробовать использовать и другое ПО). Для корректной работы в VirtualDub нужно сконфигурировать захват, выключить запись звука, установить частоту кадров в 60 кадров в секунду, выбрать верное разрешение захвата, выключить отображение захватываемого видео на экране (оно сильно замедляет захват, пропуская некоторые кадры), выбрать устройство Datapath VisionDVI-DL Video 01 (DirectShow):

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

Главное, в чем нужно убедиться перед работой — что кадры захватываются без пропусков и записываются на достаточно быстрый RAID-массив из SSD-накопителей или виртуальный диск в ОЗУ. Хотя, если нет задачи оценивать качество захваченного изображения, то можно сильно снизить требования к скорости накопителя, если записывать на него не кадры в полном разрешении, а только полоску изображения в несколько пикселей, задав обрезку лишнего справа от цветной полосы, вставленной оверлеем FCAT. Замер частоты кадров при помощи утилиты Extractor

Для начала можно проверить захваченное и записанное видео на предмет отброшенных (dropped) кадров утилитой VirtualDub. А уж затем, если все хорошо, приступать к дальнейшему анализу. Утилита для анализа называется Extractor, она служит для исследования записанных ранее видеоданных и анализа цветной полосы, помещенной на изображение утилитой Overlay. Extractor определяет, какое время было потрачено на рендеринг каждого кадра и не были ли пропущены какие-либо из них.

Так как объем видеороликов получается довольно большой, то и скорость чтения с накопителя очень важна — чем быстрее накопитель, тем меньше времени работает утилита. Данные анализа записываются в виде электронной таблицы формата Microsoft Excel (*.xls), и используются при дальнейшем исследовании при помощи скриптов FCAT.

Утилита Extractor имеет очень простой интерфейс и всего лишь три элемента управления. Кнопка «Load Video File» служит для выбора видеофайла с захваченным при помощи VirtualDub изображением. После выбора файла срабатывает автозапуск проигрывания и анализа видеоролика, а после окончания процесса утилита предложит сохранить сгенерированную Excel-таблицу в файл на диске.

Опция Postprocessing не используется в данный момент (нужно выбрать «No postprocessing»), так как для последующего анализа используются Perl-скрипты, а настройка «Column to Analyze» указывает, какое количество пикселей по ширине программа будет анализировать, так как в некоторых случаях с захватом изображения на видеокартах не с чипами Nvidia, цвета пикселей на полоске искажаются. Создание таблиц и диаграмм при помощи Perl-скриптов

Сотрудники компании Nvidia написали несколько скриптов на языке Perl, которые входят в состав FCAT. Они берут в качестве входного XLS-файл, полученный после работы утилиты Extractor, анализируют полученные данные и рисуют несколько диаграмм и таблиц.

Запуск скриптов FCAT на Perl осуществляется из набора пакетных файлов (run_doall.bat, run_doall_extract.bat, run_doall_filter.bat, run_doall_run.bat), но скрипты написаны на языке Perl, поэтому требуют установки дополнительного ПО, в виде интерпретатора самого языка (к примеру, Strawberry Perl) и дополнительных инструментов в виде ПО для создания диаграмм — GNU Plot.

• fcat.pl — скрипт, подсчитывающий время рендеринга каждого кадра и определяющий отброшенные и неполноценные кадры, выводит файл в формате CSV для времени построения кадров (frametime, аналогично FRAPS), и CSV-файл со значениями FPS в двух разных вариантах и количестве отброшенных и неполноценных кадров;
• gen_percentiles.pl — скрипт, генерирующий 95%- и 99%-ные перцентили;
• pivot.pl — скрипт, выводящий данные в CSV для всех решений, участвующих в сравнении в виде, удобном для создания pivot в Excel;
• doall.pl — вспомогательный скрипт, предназначение которого понятно из названия — он генерирует большой файл для обработки всех данных.

Структура файлов для FCAT предусматривается такой, что в папке C:FCAT должны содержаться три подкаталога: Analysis, Extractor и Overlay — именно такая структура подразумевается в пакетных файлах, выполняющих скрипты. А папка с захваченными видеоданными для анализа и Excel-файлами, которые записывает Extractor, должна иметь имя C:Capture (это настраивается в пакетных файлах) и содержать данные в такой структуре:

Запуск скриптов осуществляется при помощи пакетных файлов run_doall в папке C:FCATAnalysis. В них главное — правильно указать параметр --tooldir, указывающий на каталог FCAT и --indir, указывающий на папку с файлами захваченных видеоданных на RAID-массиве из твердотельных накопителей. Параметр --outdir указывает папку, в которую будут генерироваться все выходные файлы.

Если для всех AVI-файлов уже есть сгенерированные Excel-таблицы при помощи утилиты Extractor, то нужно сначала запустить пакетный файл run_doall.bat, а затем вручную запустить run_fcat.bat, содержащийся в созданной папке. В процессе исполнения Perl-скриптов сгенерируются все необходимые файлы в виде таблиц и диаграмм.

После того, как последний скрипт FCAT завершит работу, можно начинать анализ полученных результатов. В папке C:FCATAnalysisNV (по умолчанию, можно изменить параметром --outdir) создаются подкаталоги для каждой из протестированных игр, данные для анализа которых есть в папке C:CaptureData. В подкаталогах каждой игры создаются две важные диаграммы, содержащие тестовые результаты для всех протестированных видеокарт.

Диаграмма PLOT — основной график, показывающий время построения кадров в захваченном и проанализированном видеоряде. По горизонтали указаны секунды видеозаписи, а по вертикали — время в миллисекундах, в течение которого каждый кадр показывался на экране. Тонкие линии означают довольно плавный видеоряд со стабильным FPS, а толстые линии в виде «лесенки» с пиками и провалами или «пилы» — дерганую смену кадров с большим количеством неполноценных кадров.

График аналогичен тому, что мы можем получить от FRAPS, но с учетом реального времени отображения кадров. Посмотрите на пример графика из игры Battlefield 3 для двух Radeon HD 7970, работающих в CrossFire-конфигурации, подробное исследование которых будет в следующем разделе материала.

Следующая диаграмма PER (от percentile) показывает на равномерность частоты кадров в секунду — минимальную частоту кадров в соответствующую долю (выраженную в процентах) времени в течение всего тестового видеоролика. 50-й перцентиль близок к средней частоте кадров в секунду, а чем ближе перцентиль к 100%, тем ниже значение минимального FPS. Чем ближе эта линия к параллели с горизонтальной осью (в идеале она будет равноудалена от нее, как в случае с включенной вертикальной синхронизацией), тем плавнее смена частоты кадров и комфортнее для зрителя будет игра.

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

Но и это еще не все — в каждой папке с игрой создается еще несколько файлов с дополнительными данными для каждого из протестированных GPU. Кроме двух графиков, показывающих сравнительные результаты сразу для нескольких решений, график RUN показывает то, что происходило на экране при рендеринге на каждом GPU отдельно. К примеру, вот диаграмма FPS для двух AMD Radeon HD 7970 в CrossFire в той же игре Battlefield 3:

Это файл run.stats.png, который выводит две линии на диаграмме. Черная линия называется FRAPS — она показывает, сколько кадров в секунду измерила бы одноименная утилита, а синяя линия (FPS) показывает, сколько кадров в секунду было реально послано на монитор по DVI. То есть, линия FRAPS показывает число кадров, которые были посланы на отработку в DirectX, без учета отброшенных и лишь частично отрисованных (неполноценных), которые пользователь даже не увидел, а линия FPS показывает количество кадров в секунду уже с учетом таких кадров. Также на диаграмме закрашиваются области с отброшенными (красным) и неполноценными кадрами (оранжевым).

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

Ну а последним полезным файлом для анализа является файл PIVOT.csv, который можно использовать в дальнейшем для удобного создания различных диаграмм для всех протестированных решений во всех протестированных играх. Эта таблица делает удобнее визуальное представление большого количества полученных при помощи FCAT данных.

Результаты экспресс-тестирования

К сожалению, наши возможности по тестированию 3D-производительности с применением FCAT были сильно ограничены — так как тестовый комплект из карты захвата и разветвителя на всю Россию у Nvidia пока что есть лишь один, то мы просто решили протестировать несколько видеокарт в небольшом наборе игр при помощи Nvidia, воспользовавшись любезным приглашением сотрудников из московского офиса компании. Но вы можете быть уверены в том, что все снятые показатели соответствуют действительности и никакого обмана тут нет — мы это специально проконтролировали и самостоятельно делали все тесты.

Так как выбор игровых приложений и видеокарт для тестов был ограничен из-за недостатка времени, то мы выбрали три наиболее интересные видеосистемы и пять игр для нашего небольшого тестирования. Большинство из игр довольно новые, а другие интересны по тем или иным соображениям. Мы проверили скорость 3D-рендеринга для следующих видеосистем: одиночной видеокарты Nvidia Geforce GTX Titan, двухчиповой платы Geforce GTX 690, а также связки из двух видеокарт AMD Radeon HD 7970. Эти решения были выбраны потому что GTX 690 и пара HD 7970, работающих в CrossFire-конфигурации (к слову, эта связка примерно соответствует двухчиповой Radeon HD 7990, вышедшей совсем недавно) приблизительно равны по производительности и обе имеют по два GPU, а GTX Titan является быстрейшей из одночиповых видеокарт и будет интересно сравнить ее с двухчиповыми решениями.

В набор тестовых игр вошли в основном проекты, не имеющие возможностей по автоматизированному тестированию производительности, поэтому нам пришлось просто повторять определенный кусок игрового процесса на каждой из тестовых видеокарт. Разрешение тестирования выбрано самое большое, возможное для используемой карты захвата — 2560×1440, также в настройках игр включалось полноэкранное сглаживание методом мультисэмплинга (MSAA) там, где это возможно. Итак, давайте перейдем с самим тестам. Battlefield 3

Первой игрой экспресс-теста стала Battlefield 3 — она хоть и не новая, но является одной из наиболее технологичных ПК-игр с точки зрения графических технологий и до сих пор довольно тяжела даже для топовых GPU при условии максимальных настроек. Рассмотрим сначала основной график, показывающий время отображения кадров на дисплее для тестового ролика:

Первая же диаграмма показывает прелюбопытнейшие результаты! Первое, что просто бросается в глаза — просто дикая (иначе и не скажешь) неравномерность во времени рендеринга последовательности кадров на связке из двух Radeon HD 7970. Да, среднее время отображения кадров явно быстрее, чем у обеих видеосистем Nvidia, но какой ценой это было достигнуто — на графике HD 7970 CF четко видна «пила», говорящая о том, что за показанным на протяжении очень короткого времени кадром идет «длинный» кадр, и так почти все время. Иными словами, несмотря на то, что средняя цифра смены кадров в секунду у двух видеокарт AMD высокая, но комфортность при просмотре отрисованного изображения будет очень плохой — временами (середина графика) даже хуже, чем у одной Titan.

Что касается видеокарт Nvidia, то Titan показывает хоть и меньшую производительность, но явно более равномерную частоту кадров, что говорит о более высоком комфорте и плавности геймплея для игрока, несмотря на более высокий FPS у двухчиповых решений. Впрочем, Geforce GTX 690 справляется с работой явно лучше своего конкурента в виде двух Radeon HD 7970 — некоторое «дрожание» времени отображения кадров на дисплее (а вместе с ним и FPS) есть, но оно совсем не такое большое, как у видеоплат соперника. Посмотрим, что получится на диаграмме перцентилей.

Диаграмма полностью подтверждает все наши выводы, написанные выше — наиболее пологая линия у Geforce GTX Titan (даже в самой правой части графика, что говорит об очень равномерной смене кадров), затем идет двухчиповая GTX 690, которая лишь чуть уступает одночиповой Titan в правой части диаграммы, ну а две Radeon HD 7970 в CrossFire отличаются крайне неравномерной частотой кадров, что выразилось в линии графика, которая значительно снижается в правой части. Рассмотрим графики FPS, отдельные для каждой из протестированных видеокарт:

Собственно, ничего удивительного на них мы не обнаруживаем, данные диаграммы просто несколько удобнее в восприятии, так как содержат отдельные результаты всех видеосистем. Самое интересное тут — сопоставление линии FRAPS и FPS (напомним, первая означает число FPS, замеренное чисто программными методами 3D-тестирования, а второе — что показывает FCAT). И если для обеих видеокарт на графических процессорах Nvidia эти линии на графике сливаются (отброшенных и неполноценных кадров просто нет), то для связки из пары Radeon HD 7970 все намного хуже — есть и вовсе не показанные на экране кадры (красная заливка) и неполноценные (желтая заливка), показанные пользователю на минимальное время и поэтому практически незаметные.

Также хорошо видно, что минимальная реальная частота кадров (синяя линия — FPS) для пары Radeon HD 7970 почти равна минимальному FPS для одночиповой Geforce GTX Titan. То есть, по сути, никакого реального преимущества в комфорте у владельца мощнейшей двухчиповой видеосистемы AMD перед Titan просто не будет, хотя преимущество по средней частоте кадров явно имеется. Контрастирует с ней GTX 690, которая явно не просаживается в производительности и даже лучше по комфорту, по сравнению с одночиповой. Посмотрим на средние цифры FPS на отдельной диаграмме:

Сразу же отметим, что обе Geforce не имеют потерь от отброшенных и неполноценных кадров, так как оба значения (замеренные при помощи FRAPS и FCAT, соответственно) равны. А вот Radeon HD 7970 CrossFire теряет около 8% на таких кадрах. Но даже несмотря на это, средняя цифра FPS у них все равно выше, чем у GTX 690, хотя по графику времени рендеринга кадров видно, что средняя цифра явно не показательна — плавности смены кадров на системе CrossFire просто нет. Crysis 3

Вторая игра в тесте — Crysis 3, которая является одной из самых тяжелых для графических процессоров на данный момент, и точно наиболее технологически продвинутой по примененным технологиям. Ну что же, давайте посмотрим, как выступят протестированные решения в этой игре:

График несколько отличается от предыдущего, но общие выводы относятся к нему примерно в той же мере. Точно так же две Radeon HD 7970 показали менее равномерную смену кадров в тестовом прогоне, и хотя в среднем время рендеринга кадров на видеосистеме из двух видеокарт AMD ниже (то есть, средняя частота кадров выше), но экстремумы на этом решении явно хуже, чем у конкурентов, да и на графике мы видим все ту же «пилу», говорящую о плохой синхронизации работы двух GPU. Что выльется на практике в microstuttering и недостаток комфорта.

Что касается решений Nvidia, то одночиповая Titan явно все так же обеспечивает меньший средний FPS, но отличается более плавной сменой кадров — высокой равномерностью времени их показа на экране. Впрочем, Geforce GTX 690 в этот раз отличается от нее даже еще меньше, обеспечивая довольно плавный график. Посмотрим, как это выглядит в виде перцентилей.

В целом, линии очень похожи на перцентили в Battlefield 3, связка из пары Radeon показывает более высокий средний FPS (50-й перцентиль), но из-за меньшей равномерности FPS, линия графика очень сильно снижается к правой стороне, что говорит о низких значениях минимальной частоты кадров и частом ее падении. Линия Titan самая пологая — одночиповая карта Nvidia остается лучшей по плавности видеоряда, но GTX 690 мало в чем ей уступает, показывая более высокую частоту кадров. По сути, как раз только GTX 690 и обеспечивает в этих условиях комфортную игру, не просаживаясь ниже 30 кадров в секунду. Давайте еще раз убедимся в этом.

Так и есть. Если Titan обеспечивает равномерную смену кадров в районе 30 FPS, то GTX 690 дает еще больше — около 40 FPS, и лишь несколько кадров выпадают как отброшенные или неполноценные. Резко контрастирует (снова) с ними диаграмма для двух Radeon HD 7970, которые явно проваливаются чуть дальше середины тестового прогона и немного в самом начале. В эти моменты минимальный реальный FPS падает ниже 30 FPS, хотя FRAPS в таких условиях покажет почти 50 кадров в секунду — вот и польза от FCAT. Посмотрим на средние значения FPS:

Для GTX Titan значения средней частоты кадров, полученные при помощи FRAPS и FCAT, полностью совпадают, так как неполноценных и отброшенных кадров нет, в случае GTX 690 их несколько все-таки было, но это почти не сказалось на среднем значении FPS. А вот для двух Radeon падение среднего FPS при сравнении скорости рендеринга при помощи разных методов составляет целых 10%.

И посмотрите — если сравнивать GTX 690 и HD 7970 CF по методу FRAPS, то явно выигрывает видеосистема на платах AMD, а если принять во внимание цифры FCAT, измеряющие то, что в реальности происходит на экране, то тут уже эти конкуренты будут равны. Ну а если посмотреть еще и на график FPS (frametime), то преимущество смело можно отдавать GTX 690 — многочиповый рендеринг SLI явно работает корректнее, чем CrossFire. Far Cry 3

Очередным игровым проектом, который мы использовали, является весьма популярная игра Far Cry 3. Пусть она не так требовательна к мощности GPU, как предыдущая, но она довольно технологичная и современная. Итак, рассмотрим сначала диаграмму со временами показа кадров из выбранной тестовой последовательности:

При взгляде на очередной график производительности, полученный при помощи FCAT, можно лишь в очередной раз подтвердить все те же выводы, уже сделанные нами ранее. Несмотря на то, что время рендеринга и показа кадров в среднем у пары Radeon HD 7970 явно выше, чем у GTX 690, равномерность видеоряда явно снова очень сильно страдает — особенно к концу тестового ролика.

Кроме того, что две платы AMD снова показывают «пилу» на графике, сильно удивляют экстремальные пики с очень высоким временем отображения кадров — до 60 мс, и это — при средних значениях ниже 20 мс! Можете себе представить, мгновенная частота кадров в одном случае составляет 17 FPS, а в другом — 50 FPS. У обоих решений Nvidia ничего такого не отмечается, хотя GTX 690, работающая по технологии SLI, также не может обеспечить столь же плавный видеоряд, что и Titan, но ее график намного лучше, чем у пары Radeon HD 7970. Убеждаемся в правильности своих выводов:

Все так и есть — средний FPS у двух HD 7970 в CrossFire в этой игре очень высок — почти 60 FPS, но увы — зато минимальный ниже, чем у Titan и GTX 690. То есть, высокая средняя частота кадров получается за счет больших пиков с высокими мгновенными значениями FPS, зато комфортность для игрока будет крайне низкой. И хотя GTX 690 также немного сдает позиции в правой части графика, так как не обеспечивает столь же плавную частоту кадров, что и Titan, но линия ее графика гораздо ближе к горизонтали.

И тут мы снова видим примерно то же самое, что и в прошлых играх. То есть, у обеих плат Geforce графики FRAPS и FPS (FCAT) полностью совпадают, что означает полное отсутствие отброшенных и неполноценных кадров. Одночиповая Titan обеспечивает почти 40 равномерных FPS, GTX 690 — около 50 FPS. Средняя частота кадров для связки из пары Radeon явно выше этого значения, но всю картину портит конец тестового прогона с неполноценными кадрами (желтая заливка на диаграмме), поэтому и минимальная частота кадров лишь чуть больше 30 кадров в секунду, что явно хуже, чем даже у одночиповой Titan.

Но на диаграмме со средними цифрами FPS особенных проблем у Radeon HD 7970 CF не видно, что лишь в очередной раз говорит о важности измерения как минимальной частоты кадров, так и использования таких методов измерения 3D-производительности, как FCAT — только этот пакет утилит позволяет измерить то, что нужно — реально отображаемое на дисплее. Bioshock Infinite

Четвертая игра сравнения может похвастаться сравнительной новизной, хотя она основана на довольно старом игровом движке — Unreal Engine 3. Впрочем, разработчики игры утверждают, что он был изрядно модернизирован и оптимизирован и в нем используются некоторые современные возможности. Посмотрим, что покажет нам эта игра.

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

У пары Radeon HD 7970 частота смены кадров напоминает «пилу», когда быстрые кадры сменяются медленными, в среднем две платы AMD показывают больший FPS, но это нивелируется неравномерностью видеоряда. А вот странные экстремумы и просадки производительности в этой игре есть у всех решений, даже Titan. Природа этих кратковременных «тормозов» явно не в скорости 3D-рендеринга, поэтому для нас они не интересны. Рассмотрим диаграмму перцентилей:

Данный график лишь подтверждает неграфическую природу просадок в частоте кадров — посмотрите, минимальные значения в правой части практически совпадают, хотя средние в левой части явно отличаются и идут по строгому соответствию в среднем FPS — лучшая тут пара Radeon HD 7970, затем GTX 690 и, наконец, GTX Titan. Правда, в случае одночиповой платы Nvidia есть еще и странная впадина в середине графика, но в игре с таким странным поведением FPS уже ничего не может удивлять. Посмотрим графики FPS отдельно для всех систем:

Удивительно, но даже с учетом хорошо заметных экстремальных пиков на всех решениях, именно пара Radeon HD 7970 в CrossFire показала большее количество отброшенных кадров. Впрочем, они лишь снижают реальную среднюю частоту кадров, а минимальная остается на приемлемом уровне. Платы производства Nvidia в этой игре показали себя совсем чуть-чуть хуже, чем в предыдущих. Отброшенные кадры нашлись даже в случае одночиповой Titan, хотя на ее диаграмме они почти незаметны. Посмотрим, что покажут средние цифры FPS:

Во-первых, отметим, что средняя частота кадров для всех решений явно излишне высокая — игра Bioshock Infinite не настолько требовательна, как предыдущие протестированные проекты. С другой стороны, именно в ней наблюдались какие-то странности с равномерностью FPS даже на одночиповой карте. В итоге, реальный FPS даже на Titan немного отличается от той цифры, которую бы измерил FRAPS. Но падение в случае плат Nvidia почти незаметное, да и для пары Radeon в этой игре разница не превышает 4%. Fallout New Vegas

Ну и последней игрой нашего быстрого теста стал совсем не новый игровой проект серии Fallout, основанный на движке Gamebryo. Объяснение его включения в состав теста простое — именно на неравномерность частоты кадров, рывки и microstuttering ругаются некоторые пользователи, играющие в проекты, основанные на этом движке. Посмотрим, что получается на графике времени отображения кадров:

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

И она показала, как ни странно. Удивительно, но факт — в этот раз уже GTX Titan показал на дисплее видеоряд теста с меньшей плавностью, а линии перцентилей для обеих двухчиповых плат почти полностью совпали по той причине, что производительность явно ограничена движком или остальной аппаратной конфигурацией игровой системы (CPU, скорость ОЗУ и т.д.). Но, скорее всего, движок просто недостаточно хорошо оптимизирован. Рассмотрим отдельные графики FPS:

А тут вообще никакой разницы между всеми решениями не наблюдается, что еще раз говорит в пользу упора в CPU или возможности неоптимизированного движка. У всех видеосистем есть небольшое количество отброшенных и/или неполноценных кадров, но все они показывают среднюю частоту кадров примерно на одном уровне.

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

Выводы

Метод измерения 3D-производительности с использованием пакета FCAT компании Nvidia довольно серьезно меняет подход к тестированию и анализу результатов. С выходом этого программно-аппаратного пакета в публичное использование, у тестеров видеокарт во всем мире появилось средство для более точного измерения производительности GPU, по сравнению с чисто программными методами. FCAT помогает найти и показать те проблемы 3D-рендеринга, которые незаметны при проведении тестов более распространенными и привычными программными методами вроде FRAPS, которые не берут в расчет многие стадии конвейера по выводу игровых кадров на дисплей.

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

Подводя итоги нашего экпресс-тестирования, можно отметить, что на одночиповых конфигурациях производительность, полученная по методу с применением FCAT, примерно соответствует полученной с применением чисто программных средств, вроде FRAPS. Если резкий пик или падение FPS отмечается одним из методов, то и второй покажет его примерно в том же месте. Хотя из видеосистем на базе единственного GPU мы протестировали только Geforce GTX Titan, такое же поведение отмечено и у других одночиповых решений. А именно — небольшая разница во времени построения соседних кадров, почти полное отсутствие отброшенных и неполноценных кадров, а следовательно и плавная смена кадров и высокий уровень комфорта для игроков.

Чего нельзя сказать о двухчиповых видеосистемах, причем разница в поведении двухчиповых систем AMD и Nvidia довольно велика. Начнем со связки из двух видеокарт Radeon HD 7970, совместно работающих по технологии CrossFire. Судя по полученным нами результатам, многочиповые конфигурации на решениях AMD явно имеют значительные проблемы с поддержанием плавной смены видеоряда. Практически во всех исследованных играх, пара Radeon HD 7970 показывает значительно худшие результаты по этому показателю (не путайте со средней частотой кадров), по сравнению с аналогичной системой Nvidia в виде двухчиповой видеокарты Geforce GTX 690.

По сути, добавление второй видеокарты в связку к первой, почти не вызывает улучшения производительности, если целью является не только высокая средняя частота кадров, но и поддержание плавной смены кадров. Более того, иногда положение может даже стать хуже, так как разница во времени отрисовки соседних кадров ведет к тому, что называется microstuttering. Достаточно посмотреть на графики с frametime, где у пары Radeon HD 7970 почти всегда не плавная линия, а «пила». То же самое касается и диаграмм с количеством отброшенных и неполноценных кадров, а также со сравнением результатов FRAPS и FCAT — разница между ними достаточно велика.

Так что AMD явно есть над чем поработать, так как улучшение производительности от добавления второго GPU (так нахваливаемая отличная масштабируемость CrossFire) выражается только в повышении средней частоты кадров, но не в реальном улучшении комфорта для игроков. Даже если просто вычесть отброшенные и неполноценные кадры из учета, то реальный средний FPS получается примерно на 10% ниже того, что замеряет FRAPS. Но дело даже не в отброшенных и неполноценных кадрах, а в том, что связка из двух видеокарт в CrossFire обеспечивает большую разницу во времени отображения на экране для соседних кадров, что ведет к противному дрожанию и отсутствию плавности в анимации. В общем, налицо явные проблемы с синхронизацией работы двух графических чипов Radeon. Надеемся, что AMD поправит положение без больших потерь в средней частоте кадров, выпустив новые версии драйверов. Бета-версия Catalyst с частью решенных проблем уже существует, но она была выпущена позже нашего экспресс-тестирования.

С другой стороны, производительность двухчиповой видеокарты Nvidia Geforce GTX 690, которая использует технологию SLI, нас приятно удивила. Мы много раз писали о том, что двухчиповые решения не обеспечивают той плавности, что дают одночиповые видеокарты, но если кто и приблизился к этому, то это Nvidia. Технология SLI работает на данный момент гораздо лучше, чем AMD CrossFire, но не в плане высокой средней частоты кадров, а плавного геймплея, что и нужно игрокам, а не тем, кто просто стремится ставить рекорды в бенчмарках. SLI работает именно так, как и должна работать хорошая технология многочипового рендеринга, и это не пустые слова — Nvidia долго работала над улучшением плавности, вводя не только программные, но и аппаратные модификации, вроде аппаратного анализа времени построения кадров.

Хотя GPU в Geforce GTX 690 в одночиповой конфигурации работают несколько медленнее, чем Radeon HD 7970, но в режиме многочипового рендеринга все совершенно иначе. Нет, измеренная частота кадров у пары Radeon остается выше, даже с учетом отброшенных и неполноценных кадров (а значит — более заметных разрывов в изображении на дисплее), но у Nvidia SLI их вовсе почти нет. Но самое важное — с поддержанием задачи максимально плавной смены кадров SLI (в виде Geforce GTX 690) справляется гораздо лучше, чем CrossFire (в виде пары Radeon HD 7970). Да, GTX 690 не обеспечивает такой же плавности, как GTX Titan, но она намного ближе к ней, чем конкурирующая связка AMD. Итоговая плавность и комфорт при игре на GTX 690 будут почти такими же, что и на GTX Titan, что является лучшей похвалой многочиповой видеосистеме.

Секрет успешного выступления Nvidia SLI в тестах многочиповых конфигураций заключается в том, что, кроме программных методов синхронизации работы двух GPU, они с самого начала используют и аппаратные возможности, контролирующие время отрисовки кадров и их плавную смену. Собственно, Nvidia давно идет по пути не тупого повышения средней частоты кадров, но повышения комфорта игроков — достаточно вспомнить адаптивный VSync и ограничитель частоты кадров, которые обеспечивают постоянный FPS без падений и пиков. Именно комбинация программно-аппаратных решений и привела к тому, что вывод кадров на экран в случае SLI-систем гораздо более плавный, по сравнению с конкурирующими решениями. Даже в ущерб средней частоты смены кадров. Ведь плавность смены кадров и отсутствие пиков во временах отображения кадров на дисплее гораздо важнее цифр.

Да, можно сказать, что AMD лишь делает то, что требуется от них — максимально быстро выполняет рендеринг и отображение кадров, не вмешиваясь в процесс оптимизации видеоряда. Однако, ни игровой движок, ни графический API просто не могут повлиять на улучшение плавности FPS, так как последним звеном в цепи (вспоминаем схему из середины статьи) является именно графический процессор. И без возможности синхронизации и поддержания баланса между рендерингом кадров несколькими чипами, указанные проблемы с плавностью, пропущенными и неполноценными кадрами просто неизбежны. Вероятно, более высокий средний FPS (вместе с «пилой» на графиках) можно получить и на Nvidia, отключив возможности по синхронизации работы видеочипов в SLI.

Еще один интересный факт, подмеченный нами при тестировании. В некоторых играх, таких как Fallout New Vegas, все решения работают очень плохо, и видеоряд всегда сопровождается рывками и просадками FPS, даже с использованием одночиповой Geforce GTX Titan. Это лишь говорит о том, что графический движок таких игр не имеет внутренних оптимизаций, направленных на улучшение плавности. Скорее всего, в этом случае мы наблюдаем недостатки плохо оптимизированного кода, который выражен в скачкообразном изменении времени отрисовки кадров на всех видеосистемах. В таких случаях поможет только искусственный ограничитель производительности и/или включение вертикальной синхронизации. Которые также есть у Nvidia в виде адаптивного VSync и лимитатора FPS.

Судя по нашему небольшому тесту, использование FCAT может помочь найти случаи, когда частота кадров высока, но требуемого комфорта игроки не получают. Тем не менее, без недостатков у метода не обошлось, как всегда бывает. Во-первых, метод значительно более трудоемок, чем даже простое использование FRAPS. При отсутствии удобной автоматизации, с FCAT приходится довольно много работать, постоянно настраивая и перенастраивая ПО для захвата (VirtualDub), многократно повторяя одни и те же операции по запуску утилиты Extractor и командных файлов, запускающих Perl-скрипты (к тому же — их несколько). Явно не хватает FCAT простоты и автоматизации. Будем надеяться, что и Nvidia будет улучшать свой несомненно интересный пакет, да и сообщество 3D-энтузиастов не останется в стороне, предложив новые решения по автоматизации процесса тестирования.

Вторым недостатком метода мы считаем высокие системные требования к аппаратной платформе для системы захвата, и речь тут вовсе не о мощности центрального процессора. Мало того, что для тестов с FCAT нужны два ПК, но для тестирования потребуется высокопроизводительная и весьма дорогостоящая карта захвата по DVI, качественный разветвитель DVI-сигнала и очень мощная система хранения данных с 2-4 производительными твердотельными накопителями, работающими в режиме RAID 0, да еще и не на любом контроллере. Все это серьезно ограничивает круг тестеров, которые могут себе позволить применять такую методику.

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

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