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 або 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 за один прохід здійснюється розрахунок максимум для чотирьох джерел світла, при використанні моделі 4b – для 2.0, при використанні моделі 3 – для одного джерела світла.

Отже, з переходом ігор до нового способу розробки з'явився новий погляд на оцінку продуктивності: замість тестування відеокарт в абсолютно однакових умовах необхідно використовувати для кожного конкретного прискорювача модель шейдерів, яка найбільш повно використовує його можливості. Саме так розробники з 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, розробники ігор замість математичних обчислень у шейдерах набагато охоче використовують звичайні текстури.

Вершинний шейдер:

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

Другий, складніший варіант тесту, використовує складний вершинний шейдер для трансформації травинок. Кожна травинка згинається незалежно від інших під дією вітру, що задається фрактальним шумом, що розраховується на центральному процесорі. Для того, щоб знизити вплив на результати тесту таких факторів, як продуктивність центрального процесора та швидкість забарвлення, розрахунок фрактального шуму максимально оптимізовано, а травинки віднесено подалі від камери.

 Batch Size Tests:

 Batch Size Tests – набір тестів, призначених для швидкості відтворення різного розміру батчів – груп полігонів, що надсилаються додатком драйверу прискорювача за один виклик функції Direct3D. У кожному з цих тестів малюється однакова кількість полігонів, але полігони щоразу об'єднані у групи різного розміру: 8,32,128, 512, 2048 та 32768 полігонів.
Для того, щоб драйвери відеокарт з метою оптимізації не об'єднували маленькі групи в більші, кожна початкова група полігонів малюється зі своїм кольором - це викликає перезавантаження графічного конвеєра при надходженні кожної нової групи полігонів:

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

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

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