Частина друга. Графічні конвеєри GeForce 256 і GeForce 2

У попередній статті "Частина 1. Узагальнений графічний конвеєр", опублікованій в "КВ" № 39 , Розглянуті найбільш типові завдання, що виникають при відображенні інтерактивної тривимірної графіки. Дана, друга, частина присвячена розгляду особливостей апаратної реалізації графічного конвеєра на прикладі відеокарт GeForce 256 і GeForce 2 GTA.

GeForce 256 (NV 10)

До появи GeForce 256 відеокарти розраховували тільки два останні етапи графічного конвеєра (див. "КВ" № 39 ) - triangle setup & clipping і rasterizing. Сама поява лінійки відеокарт GeForce зобов'язане народилася в стінах nVidia ідеї апаратного прискорення етапів трансформації і освітлення, "ноги" якої (ідеї, а не nVidia :-) "ростуть" з досвіду розробки складних каркасних моделей в професійних пакетах CAD. Це я до того, що GeForce - суто "ігрова" карта. У nVidia "просто" вирішили зробити загальнодоступними, масовими, ті технології, які були присутні раніше тільки в дорогих професійних робочих станціях. За що їм велике спасибі.

Чому ж розрахунок трансформацій на відеокарті прискорює відображення? Тут потрібно згадати, що трансформації - це вузькоспеціалізовані операції матричного множення. В силу цього можна створити обчислювальний пристрій, який буде вміти тільки перемножувати матриці, але зате дуже швидко. В результаті апаратні трансформації в GeForce 256 розраховують полігони, як мінімум, в 2-4 рази швидше, ніж будь-який процесор з існуючих на момент її виходу. Процесор міг обрахувати, максимум, 1-2 мільйонів полігонів, а нова відеокарта в ідеалі - до 15 мільйонів.

Що це означає для кінцевих користувачів, чи то пак, для нас з вами? По-перше, набагато більш високу деталізацію полігонних моделей в іграх і можливість розробляти складні деталізовані об'єкти без втрати інтерактивності в пакетах тривимірного моделювання. По-друге, трансформації не обмежуються тільки перетвореннями, пов'язаними з переміщенням спостерігача або об'єкта в цілому. Якщо ми вже вміємо перемножать все вершини на одну і ту ж матрицю, то чому не піти далі і не множити на кілька матриць не всі, а частина вершин об'єкта? В результаті отримуємо анімацію, яка розраховується тільки відкритий в режимі реального часу! І це не фантастика, а абсолютна реальність, відома як vertex blending. Ходять чутки, що Кармак використовує цей механізм для анімації в DOOM 3.

Блок трансформацій також підтримує чотири додаткових площині відсікання до шести основним.

Що стосується апаратних розрахунків освітлення, то тут ситуація не настільки райдужна. Так, GeForce 256 підтримує на апаратному рівні розрахунок освітленості від декількох джерел світла. Але, як вже говорилося, зашитий в відеокарту алгоритм розраховує тільки розсіяну і відбиту компоненти освітлення. Крім того, GeForce 256 не вміє правильно інтерполювати освітленість на рівень пікселів - нормалі вершин губляться після етапу розрахунку їх освітленості, а інтерполяція без побудови нормалей для пікселів призводить до того, що ми побачимо "грановану" поверхню, з різкими зламами освітленості на ребрах полігонів. Тобто, в кращому випадку - модель освітленості по Гуро, коректна модель гладкою освітленості по Фонгу тільки апаратними засобами GeForce 256 хоча і досяжна, але не закладена розробниками як стандартна. Блок освітлення підтримує апаратний розрахунок до восьми джерел світла.

В GeForce 256 можна одночасно накладати дві текстури. Реалізована апаратна генерація трьох типів текстур координат - за координатами вершин, по променю відображення погляду в вершинах і по нормалям вершин. Генерація текстурних координат за координатами вершин використовується для створення проективних текстурних координат (приклад - світло від ліхтарика, закріпленого на голові ігрового персонажа). Текстерно координати по нормалям вершин дозволяють розраховувати і використовувати текстуру глобального освітлення, а текстури по променю відображення - текстуру відображення навколишнього середовища (cube environment mapping). Тобто, спочатку прораховуються шість текстур відображення (наприклад, за допомогою камери), потім ці шість текстур накладаються на шість граней куба. Куб поміщається в сцену так, щоб відбиття об'єктами знаходилися всередині нього. Принцип розрахунків простий - від спостерігача надсилається промінь в кожну вершину об'єкта, за допомогою нормалі розраховується відбитий промінь по закону "кут падіння дорівнює куту відбиття", відбитий простежується до перетину з межею куба. Таке перетин дасть ділянку текстури, який і буде зіставлений вершині. Як вже говорилося, інтерполяція текстурних координат на рівень пікселів може бути виконана точно. В результаті можна мати в сцені об'єкт з поверхнею, динамічно і в реальному часі відображає оточення.

Аналогічно працює алгоритм для текстури освітленості, тільки замість променя використовується напрямок нормалі.

Що стосується піксельної растеризации і інтерполяції, тобто SETUP & CLIPPING - RASTERIZING, то швидкість його роботи в GeForce 256 становить 480 мільйонів пікселів в секунду, а графічний конвеєр дозволяє одночасно змішувати дані для чотирьох пікселів, тобто містить чотири піксельних блоку, що працюють незалежно. У кожному піксельної блоці є по одному текстурних блоків. Як вже говорилося, GF256 може одночасно накладати дві текстури. В цьому випадку необхідно спаровування текстурних блоків, і швидкість обробки пікселів падає вдвічі - до 240 млн. Пікселів в секунду.

nVidia розробила і зареєструвала спеціальне розширення піксельних шейдеров NV_REGISTER_COMBINERS, що регламентують внутрішні регістри піксельних даних блоків растеризації і команди для роботи з ними, надаючи можливість програмування алгоритмів змішування атрибутів пікселів на своєрідному "асемблері". Дане розширення дозволяє, зокрема, виконати інтерполяцію нормалей для кожного пікселя і тим самим побудувати попіксельно карту нормалей. Ця можливість має два дуже важливих слідства. Перше - розрахунок згладженої освітленості по Фонгу. Друге - можна накладати текстуру рельєфу (bump) на піксельну карту нормалей, "модулюючи" зміна напрямку цих нормалей. Розрахунок освітленості пікселя зі зміненими таким чином нормалями призводить до того, що поверхня об'єкта знаходить "рельєф", відповідний накладеної bump-текстурі. Кого цікавлять деталі, рекомендую почитати www.reactor.ru:8101/review-geforceshaders/review-geforceshaders.shtml .

Аналогічний метод розрахунку попиксельной освітленості і накладення текстури рельєфу отримав назву методу попиксельного скалярного твори (per-pixel dot product) і був вбудований nVidia в свої відеокарти наступного покоління - GeForce 2 як nVidia Shading Rasterizer (NSR).

Реальна продуктивність GF256 істотно знижується при використанні декількох апаратних можливостей одночасно, наприклад, при використанні розрахунків трансформацій і освітлення з 4 джерелами світла реальна швидкість обрахунку сцени може падати до 2-3 мільйонів трикутників в секунду. Так що заявлена ​​швидкість в 15 мільйонів трикутників якщо і досяжна, то тільки при роботі з полігонними моделями в каркасному відображенні (в цьому випадку з усіх параметрів вершин залишаються тільки координати і колір, освітлення і текстурування немає взагалі), і найбільшу вигоду від GeForce 256 отримали як раз CAD-інженери, а не гравці.

GeForce 2 GTS / Pro / Ultra (NV 15)

Наступним еволюційним етапом стала відеокарта GeForce 2 GTS (GigaTexel Shading). Основних якісних відмінностей від попередника у неї три: підвищена частота графічного процесора і пам'яті, два текстурних блоки на кожен з чотирьох піксельних конвеєрів, NSR.

Підвищення частоти процесора і пам'яті (200/200 МГц для GTS) призвело до збільшення продуктивності графічного конвеєра майже на 70% по відношенню до GeForce 256: кількість оброблюваних трикутників тепер становить 25 мільйонів в секунду, а швидкість обробки пікселів - 800 мільйонів в секунду. Причому ця швидкість не падає при одночасному накладення двох текстур - за рахунок того, що кожен з чотирьох піксельних конвеєрів має по два текстурних блоки.

Про NSR (nVidia Shading Rasterizer) ми вже говорили вище. Цей технологічний механізм дозволяє розробникам додатків програмувати різні власні способи змішування піксельних даних. Програмування піксельних шейдеров було підтримано і в API DirectX 8.0 від Microsoft. Крім регламентації даних і команд програмування, NSR містить сім зумовлених операцій над пиксельними даними, виконуваних за один прохід: Base Texture (накладення текстури), Per-Pixel Bump Mapping (рельєфне текстурування двох типів - Emboss і Dot Product3), Ambient Light (основний колір об'єкта), Per-Pixel Diffuse Lighting (розсіяне світло), Per-Pixel Specular Lighting (відбите світло), Colored Fog (кольоровий туман), Alpha Transparency (прозорість з використанням альфа-каналу).

Серед інших можливостей GeForce 2 згадки заслуговують: 32-бітний Z-буфер, що збільшує оброблювану відеокартою глибину сцени; стиснення текстур і даних Z-буфера, що економлять пам'ять і смугу пропускання; ефекти Motion Blur і Depth of Field, трилинейную і анізотропну фільтрації; максимальний розмір текстури до 2048x2048 пікселів в 32-бітному кольорі. Я спеціально не кажу про інші дуже цікаві можливості GF 2, зокрема, про підтримку відео і DVD, оскільки предметом даної статті є відображення тривимірної графіки.

Головне значення появи GeForce 2 GTS полягає в тому, що саме починаючи з цієї відеокарти у розробників додатків з'явилася офіційно підтримана реальна можливість програмування апаратних розрахунків відображення 3D. Таким чином, GeForce 256 і GeForce 2 GTS укупі, завдяки розширенню можливостей апаратних розрахунків відображення тривимірної графіки (T & L) і введення вершинних і програмованих піксельних конвеєрів, заклали основи RISC-архітектури майбутніх поколінь відеокарт. Введення програмованих вершинних конвейєрів в чіпсетах NV 20 (GeForce 3 і 4) і NV 30 остаточно усуває принципова відмінність інтерактивного 3d і кіно, роблячи якість і складність останнього цілком досяжним для першого.

Розгляд цих дуже цікавих можливостей - насамперед програмованих вершинних і піксельних шейдеров, а також їх вплив на якість і швидкість відображення стане предметом розгляду наступної статті.

А в завершенні огляду GF256 і GF2 наведу деякі результати тестування їх продуктивності в пакетах тривимірного моделювання Alias ​​Wavefront Maya 4.5 і 3d studio max 5. Ідея тестування полягає в обчисленні продуктивності відеокарти по відображенню каркасних моделей в видових вікнах згаданих програм, оскільки, з одного боку, такий режим роботи інтенсивно використовується на початковому етапі створення тривимірної сцени, з іншого - трансформації (повороти, переміщення і масштабування) каркасних моделей ідеально підходять для тестування ап аратного блоку T & L відеокарти.

Тестова система: процесор PIII-600ЕВ з частотою 600 МГц, 640 Мб оперативної пам'яті PC-133, відеокарта GeForce 2 Pro c 64 Мб пам'яті типу DDR, операційна система - Win2K SP2. В якості тестового в обох програмах використовувався один і той же 3d-об'єкт, що складається приблизно з 600 тисяч полігонів.

Результати тестів кілька бентежать. Так, в 3d studio max продуктивність трансформацій склала близько 400 тисяч полігонів в секунду в режимі відображення wireframe (каркас, т. Е. Тільки вершини і з'єднують їх межі), що майже в 50 разів менші, ніж заявлена ​​продуктивності відеокарти (нагадаю, що вона становить 25 мільйонів полігонів в секунду). У Maya справа йде трохи краще - тести показали продуктивність роботи в видових вікнах в режимі wireframe на рівні 3 мільйонів полігонів у секунду, хоча і це теж не бозна що, в порівнянні зі згаданими 25 мільйонами. У режимі smoth and highlite (т. Е. В режимі відображення згладженої освітленій поверхні) продуктивність в видових вікнах падала більш ніж в два рази.

Чим викликана така ситуація - точно відповісти складно. Можливо, розробники графічних пакетів аж ніяк не поспішають (не ризикують?) Скористатися наявними апаратними можливостями. В останньому твердженні можна було б сумніватися, якби не було rtre (див. Новини графіки "КВ" № 39 ) - рендер-плагіна для 3d studio max з продуктивністю в 30 мільйонів полігонів в секунду.

Можливо, справа йде краще в разі використання більш сучасних відеокарт GeForce 3 і 4, оскільки їх можна програмувати. Провести їх тестування поки не вдалося через відсутність у мене зразків цих відеокарт.

Ігор Сивак, [email protected]