Измерение производительности видеосистемы: теория (страница 5)

Возвращаемся к Vsync.

Когда измеряют производительность, то кадровую синхронизацию отключают. Это правильно, иначе получали бы нечто несуразное. Но анализ кадров не представляет главного – как именно (точнее «что именно») мы получаем на мониторе. Есть логи, может возможно провести «обратное преобразование» и получить информацию по формированию изображения? Увы, FRAPS не представляет отсчетов кадровой синхронизации, да и команды «Present» не очень жестко отождествляют состояние выходного кадра, но попробовать-то можно?

Вполне очевидно, что происходит с кадром, когда он попадает в буфер вывода – он будет выдаваться на экран до тех пор, пока его не сменит другой кадр. Если включена вертикальная синхронизация, то переключение произойдет во время «обратного хода луча» (устаревшее понятие), то есть при активном состоянии сигнала Vsync. Если синхронизация отключена, то в любой момент, как только кадр поступит.

Попробуем решить непосильную задачу – можно ли, и как, перевести лог FRAPS в то, что показывается на экране. Если синхронизация включена, то перевод очень прост... но, скажите на милость, кто будет снимать лог производительности при включенном Vsync? Вариант отпадает, да и какой-то он нежизненный – мало кто включает кадровую синхронизацию, очень уж велики потери.

Остается случай с отключенной синхронизацией, и здесь большое поле для догадок. Влияние буфера «pre-rendered» очевидно и легко учитывается. То же относится к двойной и тройной буферизации на выходных кадрах построения, но как учесть переменное время выполнения на конвейере графического процессора? Увы, только «в первом приближении», FRAPS сильно обрезает полученную информацию. Можно воспользоваться собственной программой мониторинга, но это будет, как сказано в одном известном советском мультфильме, «совсем другая история» («Падал прошлогодний снег»).

• Предположение номер один – считать, что на экран будет выведен новый кадр, если за время интервала между двумя сигналами Vsync поступил хотя бы один кадр из графического процессора.
• Предположение номер два – если за отведенный интервал времени ни одного кадра GPU не представил, то засчитывается «пропуск кадра».

Для проверки правильности применим данные предположения на реальных логах.

Интерес представляет число красного цвета на верхнем графике и «Avg» в статистике. Народ, просыпайтесь.

В данном случае это 26.5 и 26.6 – цифры довольно близки. Другой вариант:

Приложение не совсем игровое, но тоже использует DirectX – просмотр фильма с частотой кадров 29.975 Гц. Среднее число по логу FRAPS возвращает 29.9 Гц, пересчет в кадры - 29.8, результат совпадает. Еще вариант:

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

Поговорим несколько об ином – числовой оценке качества получаемого изображения. В качестве этого критерия используется «FPS» (число кадров в секунду). С одной стороны, это логично, чем выше количество кадров, тем быстрее обновляется изображение и тем меньше задержка вывода – отсюда «легкость» управления. «Задержка формирования изображения» выходит за рамки данной статьи, ограничимся лишь первой характеристикой – FPS. Выше равно лучше, откуда сомнения? Но, увы, не существует настолько мощных 3D-ускорителей и центральных процессоров, способных обеспечивать высокий и стабильный Frame Rate.

Скорость поставки кадров, которая может не совпадать со скоростью вывода (из-за выключенной кадровой синхронизации), меняется во времени. Чем резче происходят изменения, тем сильнее ломается моторика управления в игре. Другой типичный дефект – видеокарта не успевает сформировать кадр перед началом вывода кадра и он пропускается. Картинка на мониторе совсем не «лампочка» и нормальное состояние или «пропуск кадра» вовсе не соответствуют включенному или выключенному источнику света.

Возьмем два крайних случая:

• Картинка полностью статична, изменений между кадрами нет. «Пропуск кадра» может фиксироваться только мониторингом, глаз ничего не заметит;
• Полная динамика, между кадрами меняется весь кадр. Отсутствие кадра будет отмечено, но мера заметности зависит от того, как менялось изображение.

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

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

Но, повторюсь, если синхронизация отключена, приход нового кадра означает его переписывание в буфер вывода. Здесь, опять же, есть условия и ограничения, но подобная ситуация вполне реальна. Если кадр задержался немного, то успеет вывестись на монитор небольшая часть старого кадра, после чего последует новый. Другими словами, «пропуск кадра» будет не на весь кадр, а лишь на небольшую часть, что позволяет говорить об «эффективном» пропуске, который меньше измеренного по скорости кадров лога FRAPS обратно пропорционально задержке появления нового кадра. Грубо говоря, если кадр не успел совсем чуть-чуть, то его необходимо засчитывать почти как полноценный кадр, а если пришел к самому концу интервала Vsync, то как почти полный пропуск кадра.

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

Зачем эти премудрости? Скорость потока кадров, FPS, принято использовать как меру производительности видеокарты и/или какой-то конкретной игры, но только она мало что значит, если к ней не добавлять описание «качество» изображения. Две парные характеристики уже представляют нечто осмысленное, вот только как производить оценку двумерных величин? Одна игра (видеокарта) дает 40 FPS при качестве 90 процентов, другая – 60 FPS при 40%, и как их сравнивать? Наиболее логично перевести описание свойств в одно число, «эффективные» FPS, только...

Да нет, проблемы не в формуле пересчета, а в результате, причем трудности психологические – после перевода от измеренных FPS (естественно, речь идет только об average FPS) к «эффективным» число может возрасти. Вот отсюда и «...».

Для пояснения действия возьмем что-нибудь определенное, например просмотр фильма (25 Гц):

Интерес представляет только верхний график.

• Белые «ступеньки» – поступающие кадры. Верхнее положение – (новый) кадр есть, ниже – кадр отсутствует один и более (линия ниже) интервалов. Зеленый график объединяет все отсчеты;
• Красные – кадр засчитывать или нет;
• Желтые, в пару к красным – добавок от степени раннего прихода нового кадра.

Зеленый график предсказуем, при формировании 25 кадров в секунду на мониторе с частотой кадровой синхронизации 60 Гц вполне очевидно дает постоянный пропуск 1-2 кадров. Данные прямого подсчета кадров по Vsync (красный график, 24.9) практически совпадает с реальными (фильм 25 Гц).

В данном случае больший интерес представляет «желтый» график. Довольно наглядно видно, что задержка появления нового кадра от начала интервала Vsync не одинакова. Природа этого явления заключается в «не кратности» частоты развертки (60 Гц) и фильма (25 Гц). Если взять фильм 30 Гц, картинка изменится:

Программа зачем-то впихнула лишний пропуск в начало, поэтому результат несколько меньше ожидаемых 30 Гц, но это не важно – отчетливо видно, что новый кадр всегда приходит в одно и то же время, перед приходом каждого второго Vsync.

Посмотрим некоторые игры для одиночных видеокарт и SLI/CF, при этом расширив номенклатуру мониторов другим типичным значением частоты кадровой синхронизации 120 Гц.

NVIDIA GeForce GTX 570

AMD Radeon HD 5850

AMD Radeon HD 6970 / HD 6990

Интересно, хоть кто-нибудь попробует посмотреть эти таблицы? Вряд ли, ну да ладно.

К сожалению, при съеме информации автор статьи «AMD CrossFireX под микроскопом. На примере Club3D HD 6990» очень ответственно подошел к настройкам в тестируемых играх, поэтому данные для обычного монитора с частотой развертки 60 Гц особого смысла не несут, ведь большую часть времени поток кадров оказывался выше критической величины и обязательно наступит «насыщение».

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

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

Усредненная характеристика по всем играм при эмуляции монитора 120 Гц.

Возьмем среднюю величину по прибавке от раннего кадра для одиночных и SLI/CF решений:

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

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

Качество картинки на экране

В этом разделе будут использоваться данные измерений, снятые на одной-двух видеокартах AMD Radeon HD 6970.

Возьмем какую-нибудь игру и посмотрим поведение картинки при скорости потока кадров больше, чем частота кадровой развертки. Естественно, привязка к Vsync будет отключена.

Для получения качественных результатов, а не только «эстетических», в каждом кадре будет формироваться контрольный признак кадра (аналог его номера) – линия с левого края экрана, по всей его высоте. Положение (и цвет) линии определяется номером кадра. В результате на экране будет наблюдаться «движение» линии в некоторой начальной области, от его левого края. Метод вывода картинки на монитор заключается в последовательной передаче строк, поэтому визуальная картинка будет отражать длительность показа каждого кадра. Например, при удвоенной скорости формирования в пределах одного показанного кадра будет две части – от одного кадра и от второго, а длина цветных линий будет прямо пропорциональна длине этих частей.

Интерес представляет все, что выше 60 к/с и для удобства наблюдения выберу сцену с удвоенной скоростью кадров (120 Гц). Благодаря наличию маркеров я мог наблюдать соотношение длительности фрагментов и мог выбрать момент, когда их соотношение было примерно правильным (50/50%) с последующим плавным «уходом». Визуально трудно оценить соотношение длин маркеров, если они сами двигаются, поэтому, очень грубо, соотношение поменялось на что-то около 25/75. При этом снимался лог и на него взглянуть стоит:

Мониторинг зафиксировал именно то, что я видел глазами. В самом начале длительности «выровнялись» (что и должно происходить при соотношении 50/50), и затем плавно «разошлись» до 1.5:1. Что же, этот тест показывает логические предпосылки, использованные при построении анализатора – поток кадров по сигналу «Present», захватываемый программами типа FRAPS, отражает то, что происходит на экране, хотя бы «качественно». Конечно, по одному тесту довольно трудно сделать однозначный вывод, но факт практического подтверждения вселяет оптимизм. Впрочем, по результатам практической части статьи уровень оптимизма резко убудет.

И, увы, вынужден отметить крайне печальное наблюдение. При включении режима «Benchmark» в программе FRAPS линии мониторинга резко изменили картинку. Это означает, что в данном режиме программа FRAPS (использовалась версия 3.5.99) вносит дополнительную нагрузку, что вызывает искажение результатов.

Проведем простую проверку – включим формирование лога другой программой, а затем запустим «Benchmark» FRAPS. Условия те же, примерно 120 FPS.

На картинке отмечены три участка – начальный этап сбора статистики примерно 10 секунд, затем выполнялся захват FRAPS на 15 секунд. Эти события четко отождествляются по «странному» провалу скорости кадров, я их дополнительно отметил маркерами. Судя по логу, ошибки, создаваемые FRAPS, действуют не очень продолжительное время и эти фрагменты могут быть отброшены при последующем анализе. Но увы, эффект неожиданный и очевидно отрицательный.

Скорее всего, в момент включения/выключения выполняется какая-то сторонняя деятельность (вариант – файловые операции), которые загружают систему. Почему нельзя было выполнить буферизации измерений, неужели желание сэкономить память? Осадок неприятный и для тонких измерений FRAPS не очень подходит.

Заключение

На этом позвольте завершить теоретическую часть материала. Вопросы, оказавшиеся за кадром:

• Интересно, как работает вертикальная синхронизация в реализации SLI. Дело в том, что кадр формируется за два интервала Vsync. На мониторе 120 Гц картинка будет идти более плавно, даже при том же FPS. Но существуют ли вообще дисплеи с полноценными 120 Гц развертки без какого-либо жульничества а-ля «interleave»?

Продолжение следует…