Измерение производительности видеосистемы: теория

24 августа 2013, суббота 00:00
для раздела Лаборатория

Оглавление

Вступление

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

Впрочем, я несколько увлекся, пока что никаких проблем нет – чем выше FPS, тем лучше работает графическая система! Теперь возьмемся за «варианты».

FRAPS, что может быть проще?

Замерить производительность довольно просто – достаточно воспользоваться одной из программ, которые обеспечивают вывод количества кадров в секунду. Ранее существовали лишь FRAPS, D3DGear и некоторые другие, впоследствии парк средств значительно расширился... но суть их работы примерно одинакова и, в достаточной мере, повторяет смысл функционирования FRAPS, поэтому стоит ограничиться только этой программой, имея в виду и все другие.

Комплект FRAPS состоит из модуля «fraps.exe», который является основной исполнительной программой, и нескольких библиотек «fraps**.dll». Смысл последних – прицепляться к запущенным процессам для получения доступа к функциям графического вывода. Эти библиотеки перехватывают выполнение некоторых команд API OpenGL/DirectDraw/Didect3D.

Кроме перехвата, в процессе своей деятельности они активно вызывают другие графические функции, например, при выводе текста и примитивов на экран. Как следствие, любая программа типа FRAPS неизбежно внесет дополнительную нагрузку на процессор/видеокарту и создаст искажения в получаемых результатах. Впрочем, эпоха «Riva TnT» давно канула в лету, поэтому особо сильного влияния ждать не приходится.





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

Fraps-Calc

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

450x596  55 KB

Программа формирует несколько графических представлений исходных данных и выполняет простейшую обработку.

  • Верхний график – «виртуальный» перевод данных лога к потоку вывода на монитор;
  • Средний график – поток кадров лога с учетом вероятности появления, которая отражается в цвете и яркости точек. По правой границе приводится градуировка;
  • Нижний график – спектр распределения кадров.

В средней части размещаются результаты анализа по отдельным типам.

Раздел «Statistic»:

  • «Avg» – средняя скорость кадров. Первое значение вычисляется традиционным способом, получаемый результат не отличается от итоговых значений других программ. Второе – с учетом игнорирования слишком коротких кадров (зависит от настроек);
  • «Max» – максимальная скорость кадра. Первое значение «пиковое», второе – после временной фильтрации, что дает более адекватные результаты;
  • «Min» – минимальная скорость кадра. Принцип работы аналогичен предыдущему параметру;
  • «FPS > 2/3 AVG» – мера стабильности, как долго скорость кадра не опускалась ниже среднего значения (точнее, двух третей). Чем стабильнее игра, тем более этот параметр приближается к 100%;
  • «Stable Average FPS» – мера того, насколько стабильно удерживается среднее значение скорости кадров, без учета каких-либо границ (в отличие от предыдущего параметра). Отчасти повторяет «FPS > 2/3 AVG», но лишь «отчасти»;
  • «Stable ***» (Near, 40ms,…) – уровень стабильности формирования кадров с заданным временным периодом. «Near» – соседние кадры, «40ms» – для функции вывода кадров с периодом 40 мс (25 Гц) и так далее.

Раздел «Stable FPS» содержит таблицу подсчета стабильности построения кадров по критерию времени периода. Фактически, выходит спектр устойчивости получаемого потока кадров. Левый столбец означает относительную устойчивость по входным данным лога, «правый» повторяет «левый», но выполняет нормирование к образцовой частоте кадров 60 к/с. Последнее нужно для объективного сравнения результатов видеокарт с различной производительностью.

Раздел «Freeze» определяет наличие «остановок» и минимальную/максимальную скорость потока кадров из анализа спектра. Использование фильтрации «шума» при построении спектра позволяет исключить случайные «проколы», что улучшает определение минимальных и максимальных значений. На этом и завершим экскурс по программе.

Особенности работы многопроцессорных конфигураций





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

Название технологий у фирм NVIDIA и ATI, извините, AMD, различается – «SLI» и «CrossFireX», но суть остается схожей – вместо одной-единственной видеокарты устанавливается несколько штук (чаще две), которые работают совместно. Здесь применяется способ поочередного расчета, когда четные кадры обрабатывает одна видеокарта, а нечетные другая. Коль скоро в сборках используются две одинаковые модели, то и расхождений в работе быть не должно (бы).

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

Режим работы с разделением выполняемого потока на два графических процессора с поочередным формированием кадров является самым популярным – при нем требуется минимум дополнительных затрат, надо лишь перераспределять запросы обслуживания из общего потока на два устройства. Обе видеокарты работают одновременно и независимо, получаемая картинка передается через мостики, устанавливаемые между платами. Существует способ передачи информации без дополнительных аксессуаров, через шину PCI -Express, но этот прием увеличивает задержки и дополнительно загружает шину PCI-Express, которая и так весьма интенсивно используется для управления и передачи данных к видеокарте, а потому в производительных решениях не применяется.

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

Итак, совместная работа двух видеокарт (точнее двух GPU, в пределах платы количество графических процессоров может быть больше одного) базируется на работе двух независимых видеокарт, каждая из которых участвует в формировании картинки, только одна из них обрабатывает четные кадры, а другая – нечетные. Все логично, но где же подвох? Какой смысл постоянно повторять одно и то же, если оно очевидно? Увы, нет, смотрите сами – каждая видеокарта является независимым исполнительным устройством, в которую (уж извините за избитое сравнение с «бассейном») в одну трубу вливается «задание» от драйвера (через PCI-Express), а из другой (мостик между платами) выливается полученный кадр. Сложность современных игр, а ведь именно для них чаще всего и используются 3D-ускорители, всегда опережает возможности этих устройств, что означает их полную «занятость», видеокарты никогда не простаивают.

При сильном утрировании графический ускоритель можно представить в виде мотора, который крутит диск. Чем быстрее мотор (производительность 3D-ускорителя) и легче диск (сложность картинки), тем быстрее оборот диска (время обработки). При этом кадр считается сформированным только после полного оборота (выполнены все фазы обработки картинки). Теперь берем второй «мотор» и запускаем его рядом. Диски будут крутиться с той же скоростью и общее количество оборотов повысится в два раза. Положим, что подаваемая «мощность» моторов и другие характеристики одинаковы. Пока логично, ничего не забыли? Забыли, фазу. Даже при полностью одинаковых условиях работы и, как следствие, скорости, «фаза» вращения двух дисков не обязательно будет одинаковой.

Рассмотрим два случая. Вариант с удачным соотношением фаз:

450x50  13 KB

Расстояние (то есть время) между построенными кадрами одинаково. В случае расхождения фаз картинка несколько изменится:





450x50  14 KB

Теперь расстояние между соседними кадрами не одинаково, хотя производительность обеих видеокарт не изменилась.

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

Рассмотрим два случая, оба на «парной» видеокарте AMD Radeon HD 6990 (с двумя графическими процессорами). В качестве иллюстративного материала будут использоваться собственные логи и информация, любезно представленная в статье «AMD CrossFireX под микроскопом. На примере Club3D HD 6990». При возникновении вопросов по полученным данным рекомендуется изучить приведенный цикл статей. Хотя их будет интересно почитать и «просто так».

Возвращаемся к нашим проблемам, игра F1:

450x240  22 KB

Вполне адекватный график, теперь несколько иной ракурс:

450x240  26 KB

Игра та же, как и схожие условия тестирования, но внешний вид претерпел существенные изменения. Взглянем поближе:

450x596  29 KB





Налицо кадры разной продолжительности. В получаемом спектре прослеживаются две четкие составляющие 75 и 150 к/с, и напрашивается вывод о разной производительности видеокарт, ведь время формирования кадра отличается почти в два раза. Кстати, подобная «чехарда» охватывает лишь соседние отсчеты или затрагивает и более продолжительное время? Попробуем сконвертировать данные таким образом, что будет эмулироваться поток одиночной видеокарты – просто усреднив время построения соседних кадров. Получится следующее:

450x240  11 KB

А что, весьма неплохой график. Отсюда вывод – «шум» на графиках вызван работой многопроцессорной графической системы. Предположение об изменении производительности одной из видеокарт оказалось ложным, и вот почему – программа сбора статистики (лог снимался с помощью FRAPS) получает данные в точке передачи заданий на исполнение в API Direct3D и ничего не подозревает о каких-либо «особенностях» реализации системы. При работе видеокарты HD 6990 (с двумя графическими процессорами) поток исполнения разделяется пополам – для первого и второго устройства, каждое из которых обсчитывает свои кадры.

Ранее я приводил сравнение с двумя моторами и здесь именно такой случай: оба GPU формируют кадры, причем с одинаковой производительностью, вот только фаза одного немного сдвинута относительно другого. Если бы они работали синхронно и со сдвигом фазы в 180 градусов (половина оборота), то выходные кадры формировались строго с одним и тем же периодом.

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

Является ли это «дефектом» и стоит ли на него обращать внимание – вот с этим и необходимо разобраться.

Страница 1 из 5
Оценитe материал

Комментарии 40 Правила

Возможно вас заинтересует

Популярные новости

Сейчас обсуждают