Методика тестирования производительности видеокарт в 3D Studio Max и Maya

Введение

Тестированию игровой производительности видеокарт GeForce 2 – GeForce 3 – GeForce 4 уделено много внимания, и результаты таких тестов легко можно найти в Сети. Однако, технологии, заложенные в архитектуру этих видеокарт, позволяют с полным основанием предполагать, что они могут быть весьма полезны не только в играх, но и в пакетах трехмерного моделирования/анимации.
Количественное тестирование производительности видеокарт в профессиональных пакетах трехмерной графики до сих пор проводилось на тестовых сценах (например, на тестовых сценах из комплекта поставки 3D Studio Max) и измерялось количеством кадров в секунду. Хотя такое тестирование вполне может выявить отличия в производительности различных видеокарт, хотелось бы все-таки иметь результаты более применимые для конкретной практической ситуации. В частности, хотелось бы знать какая видеокарта с какой скоростью может обрабатывать геометрическую сцену заданной сложности. С другой стороны, хотелось бы иметь возможность тестировать любые, и прежде всего те сцены, с которыми приходится работать, а не только специальные тестовые. Учитывая все вышеперечисленное и была предпринята попытка разработать методику количественного тестирования производительности видеокарт сначала для двух пакетов: 3D Studio Max и Maya. Забегая вперед, скажу, что предлагаемая идеология тестирования вполне может быть перенесена и на другие пакеты, в частности – Newtek LightWave или Softimage XSI .
Итак, излагаемая ниже методика применяется для тестирования в 3D Studio Max 5.0 и Maya 4.5, а в качестве единиц измерения производительности выбрано количество обрабатываемых в секунду треугольников геометрии (тр./сек.).

Методика тестирования

Общая идея методики тестирования вытекает из наиболее типичных задач, которые возлагаются на видеокарту – ускорение отображения в видовых окнах трехмерных объектов разрабатываемой сцены при различных трансформациях видового окна (pan, zoom, rotate). Под геометрией понимается трехмерный объект, поверхность которого составлена из треугольников, т.н. mesh-объект. Эта оговорка существенна, поскольку в 3D-пакетах имеется несколько типов объектов, например NURBS или patch, которые нуждаются в дополнительной обработке перед передачей на отображение (например, тесселяция – один из видов такой обработки), и обсчет которых, естественно, медленнее, чем обсчет mesh’a.
Общая задача ускорения трансформаций в видовых окнах может быть разбита на три более частных – ускорение отображения в режиме “каркас” (wireframe), интенсивно используемом на этапе разработки модели; в режиме тонированной освещенной поверхности со сглаживанием (smooth&Highlight), полезной при постановке света, “шлифовке” взаимодействия трехмерной поверхности с освещением и редактировании текстурных координат; и в режиме отображения с текстурами, часто используемом при разработке сцены на финальных стадиях, и при анимации. Что касается аппаратуры, то в режиме отображения “каркас” нагружается блок аппаратных трансформаций без освещения; в режиме тонированной сглаженной поверхности – блок трансформаций и освещения и блок растеризации видеокарты; в режиме отображения с текстурами дополнительно задействуется блок текстурирования и тем самым – весь графический конвейер видеокарты. Таким образом, такие тесты имеют, с одной стороны, чисто практическое значение, с другой – тестируют наиболее интересные и новые технологии, заложенные в архитектуру современных видеокарт. Как я уже говорил, под трансформациями будут пониматься операции вращения, трансляции и масштабирования в видовом окне (соответствующие операции в max – rotate, pan и zoom).
Итак, что тестировать – понятно. Теперь – как тестировать. Для этой цели была написана скрипт-программа, имитирующая трансформации в перспективном видовом окне и измеряющая время выполнения одной такой трансформации, количество обрабатываемых треугольников в секунду и FPS – количество кадров (или что то же самое – количество трансформаций) в секунду. Для нас наиболее важным параметром является количество обрабатываемых треугольников в секунду, поскольку он непосредственно показывает насколько сложную модель можно обрабатывать в программе, и поскольку его можно напрямую сравнить с заявленной разработчиками производительностью видеокарты. Например, если видеокарта позволяет обрабатывать 25 миллионов треугольников в секунду, то мы вполне комфортно (скажем, на 5 FPS) сможем работать в видовом окне со сценой из 25/5= 5 миллионов треугольников.

В случае 3D Studio Max ключевая последовательность скриптовых команд выглядит приблизительно следующим образом:

time1= timeStamp() // время начала трансформации;
preRotateZ matras 10 // вычисляем матрицу трансформации (в данном случае поворота по оси Z на 10 градусов, для масштабирования – preScale matrix, для трансляции – preTranslate matrix) системы координат видового окна;
viewport.setTM (matras) // применяем матрицу вращения к системе координат видового окна;
forceCompleteRedraw // принудительно перерисовываем видовое окно;
time2= timeStamp() // время окончания трансформации;
time = time2 – time1 // время выполнения одной трансформации.

Следует оговориться, что в max операции трансформаций в видовом окне не анимируются, и более того, для них во встроенном скриптовом языке нет соответствующих команд. Поэтому приведенная последовательность команд только имитирует то, что происходит при интерактивном манипулировании видовым окном с помощью инструментов pan, zoom и rotate. В частности, мне не удалось установить, каким методом (скриптовой функцией) выполняется перерисовка видового окна при манипуляциях в max, поэтому я использовал forceCompleteRedraw. Эта функция гарантированно перерисовывает все в видовом окне и работает быстрее, чем другие функции перерисовки (которых имеется еще несколько – например, команда max views redraw и другие). Кроме того, имеются некоторые проблемы с измерением времени выполнения трансформаций, и связано это с тем, как работает движок max’а. В пакетном режиме, когда команды скрипта выполняются в цикле без принудительной прорисовки, max накапливает трансформации и выводит для отображения только результирующую трансформацию. Например, 10 поворотов на 10 градусов каждый в скриптовом цикле отображаются как один поворот на 100 градусов, таким образом время выполнения одной промежуточной операции нулевое, его нельзя измерить. Таких проблем нет, если скриптовая команда трансформации выполняется один раз (не в цикле), но взамен старых проблем появляются новые. В частности, минимальная единица времени при измерениях в max – тик, т.е. 1/1000 секунды. Поэтому, если тестовый объект состоит менее чем из 25 000 граней, при тестировании одной трансформации на видеокарте с теоретической (заявленной разработчиком) производительностью в 25 миллионов треугольников в секунду мы можем получить измеренное время трансформации равным 0 секунд. Причина заключается в том, что видеокарта обрабатывает за 1/1000 секунды 25 000 треугольников, и если тестовый объект состоит из, скажем, 20 000 треугольников, то время его трансформации меньше 0,001 секунды, т.е. неизмеряемо в 3D Studio Max. Выход из этой ситуации состоит в измерении времени выполнения циклов из десятков или даже сотен трансформаций или же в тестировании объектов, состоящих из большого количества полигонов (к слову, чтобы иметь возможность протестировать GeForce 4 Ti4600 нам потребуется объект из более чем 100 тысяч полигонов). Поэтому я счел использование команды принудительной перерисовки приемлемым компромиссом – она и время позволяет измерить и гарантирует, что мы меряем именно время прорисовки геометрии видеокартой, и позволяет использовать циклы трансформаций.
Принципиальным моментом тестирования является также манипулирование именно видовым окном, а не трансформация (вращение и др.) самого объекта или камеры. Поясню, почему. При трансформации самого объекта (камеры) меняются его мировые координаты, что неминуемо приводит к задействованию программного движка самого max’а, т.е. процессора, а не видеокарты. При трансформациях видового окна мы фактически меняем только матрицу преобразования мировых координат объектов сцены к координатам видового окна. Max запоминает эту матрицу (16 чисел) и передает ее на видеокарту для обсчета координат отображения. Таким образом, только манипуляции видовым окном позволяют корректно измерять производительность видеокарты.
После всех этих предварительных замечаний привожу полностью код скрипта, с помощью которого тестировалась производительность видеокарт. Скрипт работает только в окне перспективного вида и измеряет время выполнения трансформаций в циклах.

Тестовый скрипт:

(
local
matras
init_matr
start
end
stoka
my_vert
my_faces
my_tr_time
my_pc
my_vc
my_fps
cikl
)
matras = getViewTM()
init_matr = getViewTM()
cikl = 36--------------количество трансформаций в цикле
---------gomasselerate-----------
gw.querySupport #geomAccel
gw.querySupport #triStrips
gw.querySupport #wireframeStrips
stoka = newScript()
---------------------------------
--statistika objects---------
my_vert = 180345----количество вершин тестового объекта
my_faces = 334291---количество граней тестового объекта
-----------------------------
--START ROTATE TEST1---------------------------------------------------------------------------------
start = timeStamp()------время начала цикла трансформаций
for i = 1 to cikl do-------выполнение трансформаций в цикле
(
preRotateZ matras 10-----получаем матрицу 4х4 трансформации вращения на 10 градусов по оси Z
--возможно использование preRotateX или preRotateY – вращений по осям X или Y соответстенно или
--комбинации всех трех
viewport.setTM (matras)--новые координаты объекта в видовом окне в результате вращения
forceCompleteRedraw doDisabled:true---полная принудительная прорисовка видового окна
)------------------------завершение цикла трансформаций
end = timeStamp()--------время окончания цикла
-----poligon&vert count--считаем время одной трансформации и т.д.--------------------
my_tr_time =(end - start)/(cikl*1000.0)--время одной трансформации в секундах
my_vc = my_vert/my_tr_time---------------количество трансформируемых в секунду вершин
my_pc = my_faces/my_tr_time--------------количество трансформируемых в секунду граней
my_fps = 1.0 / my_tr_time----------------количество трансформаций в секунду
-----------------------------------------или fps - кадров в секунду
--------output--вывод результатов теста в отдельное окно -----------
format "Rotate vwp on 10dg \n" to:stoka
format " time= %s. \n" my_tr_time to:stoka
format " faces/s= % \n" my_pc to:stoka
format " vert/s= % \n" my_vc to:stoka
format " FPS= %\n" my_fps to:stoka
format "--------------------------------------- \n" to:stoka
sleep 0.4--------------------------------пауза перед следующим тестом
--END ROTATE TEST1----------------------------------------------------------------------------------
--------reset-------------------------
viewport.setTM (init_matr)
forceCompleteRedraw doDisabled:true
matras = getViewTM()
--------------------------------------
--START ROTATE TEST 2-------------------------------------------------------------------------------
start = timeStamp()
for i = 1 to cikl do
(
preRotateZ matras -10
viewport.setTM (matras)
forceCompleteRedraw doDisabled:true
)
end = timeStamp()
-----poligon&vert count--------------------
my_tr_time = (end - start)/(cikl*1000.0)
my_vc = my_vert/my_tr_time
my_pc = my_faces/my_tr_time
my_fps = 1/my_tr_time
-------------------------------------------
-------------output----------------------------------------------------
format "Rotate vwp on -10dg \n" my_tr_time to:stoka
format " time= %s. \n" my_tr_time to:stoka
format " faces/s= % \n" my_pc to:stoka
format " vert/s= % \n" my_vc to:stoka
format " FPS= %\n" my_fps to:stoka
format "--------------------------------------- \n" to:stoka
sleep 0.4
--END ROTATE TEST 2---------------------------------------------------------------------------------
--------reset-------------------------
viewport.setTM (init_matr)
forceCompleteRedraw doDisabled:true
matras = getViewTM()
--------------------------------------
--START SCALE TEST OUT----------------------------------------------------------------------------
start = timeStamp()
for i = 1 to cikl do
(
prescale matras [0.9, 0.9, 0.9] false
viewport.setTM (matras)
forceCompleteRedraw doDisabled:true
)
end = timeStamp()
-----poligon&vert count--------------------
my_tr_time = (end - start)/(cikl*1000.0)
my_vc = my_vert/my_tr_time
my_pc = my_faces/my_tr_time
my_fps = 1/my_tr_time
-------------------------------------------
-------------output----------------------------------------------------
format "Scale_out vwp \n" to:stoka
format " time= %s. \n" my_tr_time to:stoka
format " faces/s= % \n" my_pc to:stoka
format " vert/s= % \n" my_vc to:stoka
format " FPS= %\n" my_fps to:stoka
format "--------------------------------------- \n" to:stoka
sleep 0.4
-----------------------------------------------------------------------
--END SCALE TEST OUT-------------------------------------------------------------------------------
--START TEST SCALE IN--------------------------------------------------------------------------------
start = timeStamp()
for i = 1 to cikl do
(
prescale matras [1.1, 1.1, 1.1] false
viewport.setTM (matras)
forceCompleteRedraw doDisabled:true
)
end = timeStamp()
-----poligon&vert count--------------------
my_tr_time = (end - start)/(cikl*1000.0)
my_vc = my_vert/my_tr_time
my_pc = my_faces/my_tr_time
my_fps = 1/my_tr_time
-------------------------------------------
-------------output----------------------------------------------------
format "Scale_in vwp \n" to:stoka
format " time= %s. \n" my_tr_time to:stoka
format " faces/s= % \n" my_pc to:stoka
format " vert/s= % \n" my_vc to:stoka
format " FPS= %\n" my_fps to:stoka
format "--------------------------------------- \n" to:stoka
sleep 0.4
-----------------------------------------------------------------------
--END SCALE TEST IN-------------------------------------------------------------------------------
--------reset-------------------------
viewport.setTM (init_matr)
forceCompleteRedraw doDisabled:true
matras = getViewTM()
--------------------------------------
--STAR TRANSLATE TEST 1-------------------------------------------------------------------------
start = timeStamp()
for i = 1 to cikl do
(
preTranslate matras [-50, 0, 0]
viewport.setTM (matras)
forceCompleteRedraw doDisabled:true
)
end = timeStamp()
-----poligon&vert count--------------------
my_tr_time = (end - start)/(cikl*1000.0)
my_vc = my_vert/my_tr_time
my_pc = my_faces/my_tr_time
my_fps = 1/my_tr_time
-------------------------------------------
-------------output----------------------------------------------------
format "Translate 1 vwp \n" to:stoka
format " time= %s. \n" my_tr_time to:stoka
format " faces/s= % \n" my_pc to:stoka
format " vert/s= % \n" my_vc to:stoka
format " FPS= %\n" my_fps to:stoka
format "--------------------------------------- \n" to:stoka
sleep 0.4
--END TRANSLATE TEST1----------------------------------------------------------------------------
--START TRANSLATE TEST 2-------------------------------------------------------------------------
start = timeStamp()
for i = 1 to cikl do
(
preTranslate matras [50, 0, 0] --X
viewport.setTM (matras)
forceCompleteRedraw doDisabled:true
)
end = timeStamp()
-----poligon&vert count--------------------
my_tr_time = (end - start)/(cikl*1000.0)
my_vc = my_vert/my_tr_time
my_pc = my_faces/my_tr_time
my_fps = 1/my_tr_time
-------------------------------------------
-------------output----------------------------------------------------
format "Translate 2 vwp \n" to:stoka
format " time= %s. \n" my_tr_time to:stoka
format " faces/s= % \n" my_pc to:stoka
format " vert/s= % \n" my_vc to:stoka
format " FPS= %\n" my_fps to:stoka
format "--------------------------------------- \n" to:stoka
sleep 0.4
--END TRANSLATE TEST 2----------------------------------------------------------------------------
--------reset-------------------------
viewport.setTM (init_matr)
forceCompleteRedraw doDisabled:true
matras = getViewTM()
--------------------------------------
--END WHOLE TEST----------------------

Этот скрипт вводился в окне редактирования скриптов в max и запускался на выполнение нажатием комбинации клавиш Ctrl+E. Результаты выводятся в отдельное окно, откуда их можно сохранить в текстовый файл. Размер и положение окна вывода можно менять, max запомнит сделанные изменения и в следующий раз будет открывать новое окно такого же размера и в том же месте на экране.
Такова методика тестирования в 3D Studio Max, и измеренная таким образом производительность работы видеокарты хорошо согласуется с интуитивным ощущением производительности при реальных манипуляциях в видовом окне.
Для тестирования в Maya была использована эта же идеология, но с учетом особенностей скриптового языка MEL. В частности, Maya имеет скриптовые анимируемые команды трансформаций в видовом окне, а также доступные из главного меню возможности расчета и средства отображения в видовом окне статистики геометрии объекта и скорости анимации в кадрах (FPS) с постоянным обновлением в процессе выполнения скрипта. Кроме того, работать со скриптом в Maya гораздо проще – достаточно написать его в окне скрипт-редактора Maya и затем выделить и перетянуть текст на Shelf Tabs. В результате получаем кнопку под главным меню, по нажатию которой выполняется тело скрипта.

Вот сами скрипты:

Вращения cikle orbit
int $i = 0;
while ($i < 145)
{
orbit -ha 5;
refresh -cv;----команда принудительной перерисовки видового окна
$i = $i + 1;
}
displayStats -fr true;
int $i = 0;
while ($i < 145)
{
orbit -ha -5;
refresh -cv;
$i = $i + 1;
}

Вращения cikle roll_l
int $i = 0;
while ($i < 147)
{
roll -d 5;
refresh -cv;
$i = $i + 1;
}

Вращения cikle roll_2
int $i = 0;
while ($i < 147)
{
roll -d -5;
refresh -cv;
$i = $i + 1;
}

Масштабирование cikle dolly
int $i = 0;
int $c = 400;
while ($i < 81)
{
dolly -abs -d $c persp;
refresh -cv;
$i = $i + 1;
$c = $c - 5;
}
$i = 0;
while ($i < 81)
{
dolly -abs -d $c persp;
refresh -cv;
$i = $i + 1;
$c = $c + 5;
}

Трансляции cikle track
int $i = 0;
while ($i < 100)
{
track -d 0.1;

Часть кода под заголовком – отдельный скрипт тест, каждому может соответствовать своя кнопка. Можно ввести весь скрипт целиком для одной кнопки (убрав заголовки), тогда все тесты будут выполняться вместе, последовательно друг за другом. Смысл тестов тот же – имитация трансформаций (вращений, масштабирования и трансляций) в видовом окне. Для отображения статистики геометрии объекта нужно использовать Display>Heads UP Display>Poly Count, а доля отображения значения FPS в видовом окне – Display>Heads UP Display>Frame Rate.
Очевидно, данная методика может быть воспроизведена в любом пакете трехмерного моделирования и анимации, имеющем достаточно развитый скриптовый язык.

Тесты

Не останавливаясь на «голой» теории, я использовал вышеописанную методику для выполнения некоторых практических тестов, результаты которых и привожу ниже.
Первыми были выполнены тесты в 3D Studio Max 5.0 для двух API – OpenGL и Direct3D, а также в режиме Software в трех режимах отображения –wireframe, smooth&highlight и smooth&highlight c отображением текстур. В качестве тестового трехмерного объекта в сцене с одним omni-источником света использовалась mesh-модель танка средней сложности из свободно распространяемых в сети образцов библиотеки EsponaModel. Вот ее вид в режимах отображения wireframe, smooth&highlight и с текстурами:

Ее количественные показатели: треугольных граней - 334291, вершин - 180345, текстурных карт - 4, одна из которых многосоставная (из 6 текстурных карт). Тестирование в max проводилось для случая одного видового окна, развернутого на весь экран, разрешение экрана – 1152х864 85 Гц.
Для тестирования использовался компьютер на базе Intel Pentium 4 2GHz, 512 Mb PC2100 DDR SDRAM, операционная система – Windows 2000 SP2, DirectX 8.1. Тестировались видеокарты Riva TNT 32 Мб, GeForce 2 Pro 64 Мб DDR, GeForce 3 Ti200 64 Мб DDR. Включение Riva TNT в ряд тестируемых видеокарт обусловлено желанием сравнить производительность двух качественно разных классов видеокарт – с аппаратным T&L (все GeForce) и без него (RivaTNT).
В качестве драйверов видеокарт во всех случаях использовался Detonator версии 41.09. Все настройки, доступные из операционной системы – по умолчанию, кроме отключения вертикальной синхронизации. В 3D Studio Max для API OpenGL обязательно включалась опция Implementation-Specific Settings>Use Wireframe Faces (Custom Driver Extension), в API Direct3D – Geometry>Use Triangle Strips>For Wireframe Objects. Обе опции существенно ускоряют отображение в видовых окнах.
Прежде всего, для сравнения была измерена производительность в режиме Software, т.е. рассчитываемая только центральным процессором:

Максимальная производительность в данном случае составила около 1,8 миллионов треугольников в секунду в режиме отображения “каркас”. В режиме тонированной поверхности производительность упала более чем вдвое и составила около 800 тысяч треугольников в секунду, а в режиме отображения с текстурами – 600 тысяч треугольников, т.е. втрое меньше. Software-производительность измерялась со всеми видеокартами и несколько возрастала для карт с большей частотой GPU.

На диаграммах 2-4 представлена сравнительная производительность тестируемых видеокарт в Software и OpenGL в трех режимах. При анализе результатов этих диаграмм следует иметь в виду, что трансформации в Software рассчитываются только процессором, а в OpenGL – только GPU. В тестах в режиме Software процессор обсчитывал только трансформации, в реальных же задачах на процессор будет возложено множество других задач, так что Software-производительность в реальных задачах всегда будет существенно ниже по сравнению с рассчитанной в тестах. Рекорд производительности принадлежит GeForce 3 и составляет 3.7 миллиона треугольников в секунду в режиме отображения wireframe. Так что сами по себе результаты впечатляющие – GPU GeForce 2 и 3 по производительности «делают» процессор во всех режимах, и разница в производительности существенна.

А вот этот результат несколько неожиданный. Из него следует, что производительность видеокарт с использованием API Direct3D в случае расчета освещения и текстурирования гораздо выше, чем при использовании OpenGL. Зато в расчетах «чистой» геометрии (режим wireframe) все точно наоборот. Впрочем, возможно, что это обусловлено выбором для тестирования игровых видеокарт, а для профессиональных видеокарт результаты могут быть и иными.

Результат, отображенный на Диаграмме 9 вполне логичен – здесь во всей красе проявляют себя и пиксельный конвейер и общая оптимизация архитектуры GeForce 3.
И наконец, хочу привести сводную таблицу результатов тестирования всех видеокарт во всех режимах.

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

Основные выводы

1. Все видеокарты серии GeForce превосходят по производительности центральный процессор в задачах отображения трехмерной графики, особенно в случае использования API Direct3D для расчета освещенности и текстурирования. Замечателен результат GeForce 3 – производительность этой видеокарты в большинстве случаев выше, чем у предшественников. Рискну предположить, что GeForce 4 с его еще более оптимизированной архитектурой, дополнительным (вторым) конвейером T&L и повышенной тактовой частотой сможет показать еще более впечатляющие результаты производительности. Что в сочетании с падением цен на эти видеокарты делает их весьма разумным выбором для покупки. Если Вы работаете в 3D Studio Max, то покупка хорошей видеокарты будет гораздо выгоднее установки второго процессора (разумеется, если речь не заходит о финальном рендеринге, который выполняется процессором). Несмотря на это следует заметить, что измеренная практическая производительность видеокарт разительно отличается от заявленной nVidia теоретической производительности.
   
   
2. Отчетливо видно, что, по крайней мере, для игровых видеокарт, OpenGL уступает по производительности Direct3D.
   
   
3. По всем признакам эволюция развития технологий отображения направилась в сторону использования вершинных и пиксельных шейдеров. Доказательством тому служат как динамика производительности видеокарт в этих режимах, так и встраивание возможностей для интерактивного отображения в видовых окнах аппаратных шейдеров как для 3D Studio Max (плагин CgFX), так и для Softimage, так и для Maya. Плагин CgFX к тому же использует в работе исключительно API Direct3D (даже в случае Maya).
   

Перейдем к результатам тестирования в Maya 4.5
Для тестов использовался тот же геометрический объект, что и в max, экспортированный в формат .obj и оптимизированный в Maya, но без текстур. Количественные показатели вершин и граней тоже остались прежними.
Поскольку Maya ничего не знает о существовании разных API (вернее, знает только OpenGL), тесты были проведены по одному разу для двух режимов отображения.

Вывод очевиден. Maya почти безразлично, какой именно GeForce установлен в системе. Поэтому, для работы в Maya покупка второго процессора выгоднее приобретения GeForce 4.

В заключение хочу сказать, что описанные тестовые скрипты могут работать с любой сценой, необходимо только для 3D Studio Max вводить «руками» в соответствующее место скрипта количество вершин, соответствующее тому объекту, который находится в видовом окне.

Автор выражает огромную благодарность Тимофею Чеблокову за конструктивные замечания и помощь в подготовке статьи.