3DMark 2005

Автор myxxx323, 09 Ноябрь 2009. Опубликовано в DirectX 9.0b-9.0с Shaders ver 2.0b

Год выпуска: 2006
Разработчик: Futuremark Corporation
Платформа: PC
Минимальные системные требования:
Операционная система: Microsoft Windows 2000 or XP operating system
Процессор: x86 compatible processor with MMX support, 2000MHz
Оперативная память: (512MB recommended)
DIRECT X: DirectX9.0c or later (required)

DirectX9 и модели шейдеров

С развитием функциональности графических процессоров разработчики должны использовать их дополнительные возможности как для улучшения качества сцен, так и для получения дополнительной производительности.
Компания Microsoft, создатель DirectX, продемонстрировала на редкость гибкую позицию, позволив двум ведущим разработчиков графических процессоров породить целый набор моделей шейдеров, использующих расширенную функциональность графических процессоров, превосходящих базовые требования модели шейдеров 2.0. Индустрии нужен был стандартизированный подход к расширению базовых возможностей DirectX 9, и в результате появились Shader Model 2.0а, Shader Model 2.0b и Shader Model 3.0.

К примеру, в Far Cry при расчете освещенности с использованием пиксельных шейдеров модели 3.0 за один проход осуществляется расчет максимум для 4 источников света, при использовании модели 2.0b – для 3, при использовании модели 2.0 – для одного источника света.

Итак, с переходом игр к новому способу разработки появился новый взгляд на оценку производительности: вместо тестирования видеокарт в абсолютно одинаковых условиях необходимо использовать для каждого конкретного ускорителя ту модель шейдеров, которая наиболее полно использует его возможности. Именно так разработчики из Futuremark видели 3Mark05.

3DMark05: этапы пути

Futuremark, называя свои тестовые пакеты «The Gamer’s Benchmark», постоянно добавляет поддержку новых технологий и развивает функциональность своих 3DMark. Тестовые пакеты от Futuremark, впервые появившиеся в конце 1998 года, со временем превратились в главный инструмент для измерения производительности видеокарт и оценки соотношения сил, для самых разных людей, от простых энтузиастов до менеджеров крупнейших компаний.

3DMark99 - концентрировался на скорости текстурирования и обработки полигонов.
3DMark2000 - получил поддержку аппаратной трансформации полигонов, вместе с этим увеличилась сложность сцен.
3DMark2001 - получил поддержку вершинных и пиксельных шейдеров 1.1 и дополнительно увеличенную сложность сцен – теперь в сценах присутствовали уже десятки тысяч полигонов.
3DMark03 - использовал шейдеры 1.х и 2.0. Только один из игровых тестов вовсе не использовал пиксельные шейдеры. Все остальные игровые тесты широко использовали пиксельные и вершинные шейдеры DirectX8, а последний, самый сложный, игровой тест широко использовал шейдеры модели 2.0. Сложность сцен увеличилась до сотен тысяч полигонов.
3DMark05 - поднял уровень технологий еще выше. Пакет использует только шейдеры модели 2.0 и выше, причем, все шейдеры могут исполняться в любом из профайлов, соответствующих моделям 2.0, 2.0а, 2.0b и 3.0. Сложность сцен увеличилась: теперь в среднем в кадре может находиться больше одного миллиона полигонов.

Главным отличием 3DMark05 от предыдущих версий тестового пакета является использование шейдеров как минимум модели 2.0 и выбор оптимального пути рендеринга для каждой из видеокарт.
Patric Ojala из Futuremark приводит такой пример: “Мы используем несколько специально подготовленных шейдеров, например, в первом игровом тесте шейдер, соответствующий модели 3.0, использует динамическое управление исполнением и прекращает работу при обнаружении того факта, что поверхность не освещена. Другим примером можно назвать шейдер, использующий Depth Stencil Textures”.

Графический движок: использование шейдеров

Предыдущие реинкарнации 3DMark от Futuremark использовали модифицированные версии MAX-FX, но для 3DMark05 компания разработала новый графический движок. Все шейдеры, использующиеся в сценах, написаны на языке высокого уровня – HLSL. Эти шейдеры не исполняются непосредственно, перед отправкой на ускоритель их нужно откомпилировать, т.е., перевести на язык, более понятный графическому процессору и его драйверу. DirectX предлагает несколько профайлов – несколько оптимальных конфигураций для компилятора шейдеров, предназначенных для графических процессоров с разной функциональностью. Так, скажем, для ATI RADEON 9700 PRO будет использован профайл PS 2_0/ VS 2_0, а для NVIDIA GeForce 6800 Ultra – PS 3_0/VS 3_0. Графические процессоры последнего поколения превосходят базовые требования DirectX 9.0, и, несмотря на то, что они поддерживают младшие профайлы, скажем, PS 2_0/ VS 2_0, по умолчанию для них будет выбираться профайл, наиболее полно использующий их функциональность. То же касается и графических процессоров , которые появятся позже выхода 3DMark05 – для них на основании списка возможностей, в обязательном порядке предоставляемого драйверами, будут выбираться профайлы, наиболее полно использующие их функциональность.

Итак, в новой реинкарнации тестового пакета Futuremark еще дальше отходит от идеи сравнения видеокарт в абсолютно одинаковых условиях. Это и неудивительно: все современные видеокарты поддерживают базовые требования DirectX 9.0, но выше базовых требований все имеют совершенно разную функциональность. Ставить их в одинаковые условия некорректно: эти одинаковые условия в разных случаях будут оптимальными для одних видеокарт и неоптимальными для других. Взамен всего этого 3DMark05 за счет выбора наиболее функциональных профайлов для каждого графического процессора по максимуму задействует возможности каждой видеокарты.
Тем не менее, для тех, кому, всё-таки, интересно сравнить работу видеокарт в одинаковых условиях, введена возможность выбора профайла для компиляции шейдеров HLSL. Таким образом можно заставить видеокарту работать с менее функциональным профайлом, скажем, NVIDIA GeForce 6800 Ultra не будет использовать шейдеры 3.0, но при этом скорость отрисовки сцен, конечно, изменится.

Графический движок: использование центрального процессора

В игровых тестах новый пакет от Futuremark не использует ресурсы центрального процессора ни для чего иного кроме подготовки данных для построения сцены. То есть, никаких расчетов, связанных с игровой физикой, логикой или AI – «искусственным интелектом» - в игровых тестах нет.
Большинство встроенных тестов в обычных играх организовано таким же образом: на время проигрывания демо-записи и измерения скорости обсчет AI, физики и т.д. отключается. Например, в Doom3 встроенный тест организован именно таким образом.
Итак, в части использования ресурсов центрального процессора в игровых тестах разработчики Futuremark постарались приблизиться к реальным игровым тестам, и такой подход, похоже, вполне оправдан, ведь 3DMark – это, в первую очередь, тест видеокарт, а не центральных процессоров.

Графический движок: система расчета теней

Динамические тени появились еще в сценах 3DMark 2001 – движок использовал проецируемые карты теней. В 3DMark03, во втором и третьем тестах, графический движок перешел к другому способу построения теней, такому же, что использует «великий и ужасный» Doom3 – расчет объемов, ограничивающих затененные области, и использование буфера шаблонов для определения освещенности объектов.
В 3DMark05 разработчики отошли от этого метода расчета теней – обеспечивая отличное качество, он, тем не менее, имеет ряд недостатков. Для каждого объекта, который должен обрасывать тень, нужно создать его “теневой объем” – полигональную модель, гранями которой со стороны источника света являются грани самого объекта, а с боков – вытянутый от источника света в бесконечность силуэт объекта. Нахождение граней, образующих силуэт объекта и подлежащих вытягиванию, представляет собой непростую задачу, выполняемую средствами центрального процессора, и чем сложнее объект, то есть, чем больше полигонов включено в расчет, тем больше времени требуется на создание “теневого объема”.
Дальнейшее использование этих невидимых “теневых объемов” связано с необходимостью отрисовки их в буфер шаблонов, что значительно увеличивает нагрузку на графический процессор в плане скорости закраски. И чем больше объектов отбрасывает тени, тем больше нагрузка на графический процессор.

Метод расчета теней, который используется в 3DMark05, свободен от этих недостатков. 3DMark05 для расчета динамических теней использует тип карт теней, называемый «perspective shadow maps», PSM, с собственными доработками для минимизации проявления характерных для них недостатков.
При расчете динамических теней с помощью карты теней этапы построение сцены выглядит примерно так:

-Сначала сцена строится с позиции источника света. При построении не используются текстуры, пиксельные шейдеры и т.д., так как всё, что нужно на этом этапе – это значение Z, то есть, удаленность пикселов сцены от источника света. Это значение для каждого пиксела записывается в выходной буфер в формате с плавающей точкой. Чем выше размеры этого буфера и чем точнее формат представления данных, тем качественнее будет результат.
-После расчета карты теней сцена строится обычным образом, с позиции камеры. Для определения освещенности пикселов используются пиксельные шейдеры: в шейдере для каждого пиксела сцены определяется соответствующий ему пиксел карты теней и вычисляется расстояние от пиксела сцены до источника света. Если это расстояние оказывается равно или меньше, чем сохраненное в карте теней значение, то пиксел освещен. Если это расстояние больше, то очевидно, что какой-то из элементов сцены при расчете карты теней оказался ближе к источнику света, и пиксел оказался затенен.

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

Этот метод, конечно, имеет свои собственные слабые места, но разработчики из Futuremark уверяют в том, что их модификация PSM хорошо подходит для самых разнообразных сцен и источников света.
Расчет карт теней для направленных источников света производится в разрешении 2048х2048, карты теней сохраняются в формате с плавающей точкой, R32F или D24X8. Для этих источников света графический движок рассчитывает две карты теней: одна – для объектов, находящихся ближе к камере, и вторая – для остальной сцены. Таким образом достигается повышенная точность расчета теней в тех местах, где это наиболее заметно, т.е., близко к камере, и сохраняется возможность расчета теней для остальной сцены. Впрочем, даже этого иногда недостаточно для того, чтобы полностью избежать появления артефактов – в третьем игровом тесте 3DMark05 на участках скал, расположенных почти параллельно солнечным лучам, заметны артефакты затенения.

Обратите внимание на тень, отбрасываемую тросами возле "плавника" летучего корабля, и на фрагмент стены каньона.

Разработчики отмечают, что это не ошибки драйвера или аппаратные проблемы, это – проявление одного из слабых мест метода карт теней.
Для ненаправленных источников света графический движок 3DMark05 строит шесть карт теней в формате R32F размером 512х512, помещая источник света в центр воображаемого куба, отстраивая карты теней для 6 граней этого куба и таким образом сводя этот случай к случаю направленного источника света.

Выборка значений из карты теней в пиксельном шейдере при наличии аппаратной поддержки Percentage Closest Filtering (PCF) и Depth Stencil Textures (DST) производится с помощью PCF, то есть, по сути, с обычной билинейной фильтрацией, а если аппаратная поддержка PCF отсутствует, фильтрация производится прямо в шейдере, для этого из карты теней выбирается и усредняется 4 ближайших к точке отсчета значения.
Эти подходы обеспечивают несколько различающиеся результаты, как в плане производительности, так и в части качества изображения, но разработчики из Futuremark уверены в том, что при возможности нужно использовать именно DST и PCF, то есть, аппаратную поддержку и аппаратную фильтрацию карт теней, поскольку самые крупные игровые разработчики уже используют эти функции графических процессоров, и в будущем востребованность этих функций только увеличится.

Итак, достаточно деталей. Перейдем, наконец, к описанию тестов.

Game Test 1: Return to Proxycon :

Первый игровой тест, однозначно, относится к разделу action-игр: космические пираты снова атакуют грузовой корабль Proxycon.

Отражая сцены классических шутеров, Game Test 1: Return to Proxycon сочетает достаточно большие помещения с узкими коридорами, а большое количество одновременно сражающихся пехотинцев приближает игровую ситуацию к мультиплейерным играм.

Большинство поверхностей в Game Test 1: Return to Proxycon использует заданные шейдерами «металлические» материалы с расчетом освещенности по модели Блинна-Фонга. Необходимые для расчета экспоненты не вычисляются в шейдерах математически, вместо этого используются выборки из заранее рассчитанной таблицы.
Всего сцена имеет 8 источников света, отбрасывающих тени: 2 направленных источника света, для которых рассчитываются карты теней размером 2048х2048, и шесть ненаправленных источников, для которых рассчитываются карты теней 512х512х6.

Game Test 2: Firefly Forest :

Этот тест является хорошим примером сцены на открытом пространстве, использующей большое количество растительности. Сцена сравнительно невелика, но до предела насыщена деталями.
Лунная ночь. Земля покрыта густой травой, ветви деревьев чуть заметно колышет легкий ветерок…

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

Поверхность земли в этом тесте отображается с помощью «металлического» шейдера из первого теста, но с добавлением базовых и детальных карт цвета/нормалей. Материал ветвей деревьев не использует карты рельефности и отражения, но имеет кубическую карту цвета. Небо отображается посредством шейдера, имитирующего рассеяние света.
Лунный свет – направленный источник света, отбрасывающий динамические тени. Тени рассчитываются с помощью карты теней, имеющей разрешение 2048х2048. Волшебный светлячок освещает траву и деревья как ненаправленный источник света с кубической картой теней 512х512х6.

Game Test 3: Canyon Flight :

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

Водная поверхность – самая примечательная часть этой сцены. Вода не только имитирует отражения и преломления, но и имеет свое значение прозрачности, так что морское чудище, движущееся в толще воды, выглядит плывущим, действительно, в толще воды, а не за мутным преломляющим стеклом.
Шейдер, использующийся для отображения водной поверхности, является усовершенствованной модификацией «водного» шейдера из 3DMark03, но водная поверхность – это не только шейдер. Для корректного расчета преломлений и отражений, включая корректное отображение теней, требуется шесть проходов графического ускорителя. Сам же шейдер использует чтения из карт нормалей, преломления и отражения. Помимо этого, для объектов, находящихся под водой, используется объемный туман, делающий их более темными и менее насыщенными по мере удаления вглубь от поверхности воды.

Для усиления эффекта присутствия в большом открытом пространстве в сцене используется туман – благодаря его использованию удаленные скалы выглядят более естественно.

Шейдер, использующийся при отрисовке скал, разработчики называют самым сложным шейдером 3DMark05 – при совмещении с расчетом теней он едва укладывается в спецификации пиксельных шейдеров модели 2.0. Материал скал использует две базовые текстуры, две карты нормалей и расчет освещенности по модели Ламберта.
Сцена имеет один источник света – Солнце. Солнечные тени рассчитываются с помощью двух карт теней с разрешением 2048х2048, одна карда используется для объектов, близких к камере, а вторая – для остальной части сцены.

 CPU Test :

3DMark05, как и 3DMark03, для тестирования скорости центрального процессора использует игровые тесты в разрешении 640х480 с отключением пост-эффектов и с программнной эмуляцией вершинных шейдеров. Это смещает сбалансированность тестов в сторону увеличения нагрузки на центральный процессор и ставит результаты тестов в зависимость от скорости центрального процессора, а не видеокарты. Для гарантии того, что на любой системе тесты проходят в абсолютно одинаковых условиях, оба CPU Test используют режим вывода сцены с фиксированным числом кадров в секунду.

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

Fill Rate :

Этот тест перешел в 3DMark05 практически без изменений. Всё, что изменилось, видно невооруженным глазом: для того, чтобы снизить требования к величине пропускной способности памяти и выделить именно скорость текстурирования, разработчики максимально снизили разрешение используемых текстур – теперь это скучные «клеточки».

Тест, как обычно, имеет два режима: наложение одной текстуры и мультитекстурирование. В режиме наложения одной текстуры сцена имеет 64 поверхности с одним текстурным слоем на каждой, а в режиме мультитекстурирования – 8 поверхностей с восемью текстурами на каждой.

Pixel Shader :

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

Стоит напомнить, что шейдер написан на HLSL, базовые требования к графическому процессору, как и у всех остальных тестов 3DMark05 – поддержка шейдеров модели 2.0.

Разработчики отмечают, что результаты этого теста будут определяться не только быстродействием пиксельных процессоров, но и скоростью шины памяти – этот шейдер интенсивно использует текстуры большого объема.
Менее зависимой от скорости памяти альтернативой такому шейдеру разработчики видят шейдер, использующий математические вычисления, то есть, «создающий текстуры на лету», но, во-первых, подобный шейдер уже использовался в 3DMark03, а во-вторых, как отмечает Futuremark, разработчики игр вместо математических вычислений в шейдерах гораздо более охотно используют обычные текстуры.

Vertex Shader :

Тест состоит из двух частей: в первой части измеряется скорость несложной трансформации моделей морского монстра – шейдер, отвечающий за трансформацию, вполне может уложиться в спецификации шейдеров модели 1.0, но тест, следуя идеологии Futuremark, использует DirectX 9.0.

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

 Batch Size Tests :

 Batch Size Tests – набор тестов, предназначенных для скорости отрисовки разного размера батчей – групп полигонов, отправляемых приложением драйверу ускорителя за один вызов функции Direct3D. В каждом из этих тестов отрисовывается одинаковое количество полигонов, но полигоны каждый раз объединены в группы разного размера: 8,32,128, 512, 2048 и 32768 полигонов.
Для того, чтобы драйверы видеокарт в целях оптимизации не объединяли маленькие группы в более крупные, каждая исходная группа полигонов отрисовывается со своим цветом – это вызывает перезагрузку графического конвейера при поступлении каждой новой группы полигонов:

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

Каждая из реинкарнаций 3DMark ставила современные видеокарты на колени, используя новые технологии и более сложные сцены, но никогда еще "деноминация попугаев" не сопровождалась таким огромным скачком в качестве изображения. Для того, чтобы получить максимум впечатлений и по достоинству оценить новые тесты, нужно, конечно, посмотреть демо-режим - каждая игровая сцена в демо-режиме представляет собой законченное произведение искусства.

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