Знаймо

Додати знання

приховати рекламу

Цей текст може містити помилки.

Direct3D 10


Переписати

План:


Введення

Переписати
Ця стаття повинна бути повністю переписана.
На сторінці обговорення можуть бути пояснення.

Direct3D 10 - набір API функцій для взаємодії з відеокартою; підтримується апаратно відеокартами класу NV GeForce 8x00, ATI Radeon 2x00 і вище. Direct3D 10 (D3D10) - компонент інтерфейсу програмування додатків (англ. API) DirectX 10, 10-я версія Direct3D, наступник Direct3D 9. Direct3D 10 забезпечує функції для взаємодії операційної системи і додатків з драйверами відеокарти. Ці функції прив'язані до операційної системи в лінійці Windows і доступні в Windows Vista і Windows 7. Частково D3D10 працює на відеокартах рівня Direct3D 9.

Офіційна фінальна версія вийшла 10 листопада 2006 року в складі Windows Vista.


Далі наведені ключові особливості і відмінності від Direct3D версії 9.


1. Можливості та особливості

1.1. Нова модель драйвера

В Windows Vista абсолютно нова модель драйвера - WDDM ( Windows Display Driver Model, раніше звана LDDM - Longhorn Display Driver Model) - серйозна зміна в моделі відеодрайвера з часів появи апаратного прискорення. У XDDM ( Windows XP Display Driver Model) кожен виклик DirectX додавав покажчик команди (токен) в буфер команд в незалежному від відеокарти форматі. Коли DX Runtime вирішував, що буфер достатньо заповнений, викликалася функція драйвера (в режимі ядра), яка отримувала цей буфер. Після цього драйвер розбирав цей буфер і передавав дані відеокарті. Тобто ніяких функцій драйвера в користувальницькому режимі не було. Розвиток відеокарт і, як наслідок, ускладнення буфера команд призвело до того, що драйвер став немислимо великим і в разі будь-якої помилки провокував BSOD. Також в XDDM у операційної системи немає способів встановлення пріоритету, управління відеопам'яттю, планування викликів DX, що утрудняє поділ відеокарти між декількома процесами - причина "втрати пристрої".

У новій моделі драйвера зроблено поділ між користувальницької і працює в режимі ядра частиною драйвера. Всі виклики DX безпосередньо йдуть в користувальницький драйвер, який готує відразу буфер з вмістом, залежних від обладнання. Цей буфер передає дані в ядро ​​операційної системи, звідки вони йдуть на відеокарту. Таким чином вся важка робота виконується в користувацької частини, а в ядрі - пересилання зібраного буфера в DMA-трансфер відеокарти. Як підсумок, якщо користувальницький драйвер впаде, нічого страшного не трапиться - закриється конкретний додаток (але не BSOD). І у драйвера більше контролю (коли і скільки викликів функцій ядра робити). Також DX Runtime стає зовсім тонкий - немає буферів команд, безпосередньо викликаються функції драйвера. Крім цього між користувацькими та ядерними частинами є планувальник завдань, який вибирає які зібрані буфера відправляти відеокарті (поділ GPU на багато процесів).


1.2. Віртуалізація відеопам'яті

Тепер якщо не вистачає відеопам'яті, то ресурси переносяться в системну (звідки можуть бути отсвоплени). За рахунок наявності у Windows Vista контролю виділення відеопам'яті (раніше, у драйвера) можна розподіляти її більш ефективно, ніж POOL_MANAGED в XDDM. На даному етапі це працює на програмному рівні - планувальник GPU перед передачею DMA -пакета карті завантажує всі потрібні текстури в відеопам'ять (вміє довантажувати їх заздалегідь, поки GPU зайнятий іншим і вільна шина). Якщо додаток повноекранне, все зайве з відеопам'яті буде перенесено в системну пам'ять в міру необхідності; якщо у віконному режимі, то відбувається розподіл пам'яті між поточними процесами. Якщо потрібно гарантувати 100% наявність ресурсу в відеопам'яті, то необхідно використовувати повноекранний режим і контроль над розміром виділень.


1.3. Відсутність ситуації "втрати пристрої" (Device Lost)

У попередніх версіях з різних причин міг відбуватися Device Lost, після чого було потрібно завантажувати всі ресурси в відеопам'ять заново і виробляти відновлення об'єктів. З новою моделлю драйвера цієї проблеми більше не існує. Можливий тільки Device Removed, який означає щось на кшталт "висмикнули відеокарту" / "поставили нову версію драйвера" і зустрічається дуже рідко.

1.4. Прибрані списки можливостей (D3D caps)

У DX10 більше немає КАПС, як таких. Гарантується наявність всієї функціональності, тобто якщо карта підтримує DX10, то вона зобов'язана підтримувати останню версію шейдеров в повному обсязі, підтримувати всі формати текстур, всі можливі режими фільтрації, шаблону (stencil) і всього іншого. Більш того, для DX10 написали специфікацію правил растеризації, тобто тепер картинка на різних відеокартах на однаковому коді завжди повинна бути однаковою і збігатися з еталонним програмним растерізатор. Якщо це не так, то це баг виробника відеокарти. Надалі функціональність буде розширюватися (пакет DX10.1, DX11 і т.д.).


1.5. Зменшено час виклику функцій DirectX

Зменшено час виклику функцій (в тому числі DIP) на CPU. За даними презентацій Microsoft можна спостерігати 10x зменшення часу. Це суттєво, так як важка гра може проводити близько 10 + мілісекунд у викликах DX. Велику частину часу виклику раніше йшло на Runtime і Driver. тепер driver model фактично нічого не робить, а відразу надає виконання драйверу.

1.6. State Objects і Constant Buffers

З'явилися State Objects - об'єкти, які можна попередньо зібрати при створенні і потім швидко встановлювати на відеокарті. Додані Constant Buffers, що дозволяють більш ефективно виставляти константи шейдерів.

1.7. Використання об'єктів-станів

Всі Set * State замінені на об'єкти-стану (State Objects). Стану розділені за кількома групами:

  • Rasterizer State - fill mode, cull mode, depth bias, multisample, scissor і т. д.
  • Blend State - alpha blend, color write mask, blend op і т. д.
  • Depth State - depth func, stencil func і т. д.
  • SamplerState - tex filtering, clamping і т. д.

Стану для кожної групи ставляться цілком, а не кожен окремо, як в D3D9. Для кожної групи можна створити State Object, якому при створенні вказується повний набір станів групи, і "встановити" можна тільки його. Створення State Object - дорога і повільна операція і повинна викликатися рідко. Мотивація цього нововведення - такий API дозволяє драйверу згенерувати набір команд відеокарті заздалегідь (при створенні State Object) і не генерувати його щоразу під час рендера при викликах Set * State.


1.8. Буфера і Біндінг

Для основних типів даних (вершин, індексів, констант) запроваджено єдиний буфер - ID3D10Buffer - набір байтів в пам'яті. Type safe забезпечується за рахунок вказівки при створенні вмісту буфера. Для ресурсів введені окремі об'єкти для Біндінг до конвеєра - resource views. Тобто спочатку створюємо текстуру як об'єкт в пам'яті, а потім її resource view як інпут для шейдера або як render target, і вже з цим view викликаємо PSSetShaderResources (замість SetTexture) і OMSetRenderTargets (замість SetRenderTarget). Варто відзначити, що в одного ресурсу може бути кілька resource views.

Такий принцип дозволяє працювати узагальнено. Існують "бестіпние" (typeless) ресурси, тобто ресурси, які не мають визначеного типу (не зазначений при створенні) - наприклад, DXGI_FORMAT_R32G32B32_TYPELESS. Тип таких ресурсів вибирається під час створення view (наприклад, DXGI_FORMAT_R32G32B32_UINT або DXGI_FORMAT_R32G32B32_FLOAT) і вибору елемента / Слайс з масиву текстур / об'ємної текстури.


1.9. Використання буферів констант

Set * ShaderConstant замінені на Constant Buffers - групи констант (буфер на n констант), що встановлюються за раз. Групу можна Лока і записувати як звичайний буфер. Біндінг до шейдери проводиться починаючи з деякого слота.

Таким чином використання констант зводиться до поділу їх на кілька груп за частотою оновлення (per-object, per-material, per-pass, per-scene) і створенню для кожної групи Constant Buffer. Крім додаткового продуктивності такий підхід дає драйверу високорівневу картину - більше можливостей для оптимізації.


1.10. Параметри шейдеров

VertexDeclaration замінений на Input Layout. Він вимагає при створенні Shader Input Signature, тобто список input-параметрів шейдера. Створений об'єкт можна використовувати як Vertex Declaration з будь-яким шейдером, мають такий же список input-параметрів. У D3D9 Vertex Declaration встановлювався незалежно від шейдера при рендер і тому драйверам доводилося серйозно модифікувати сетап при зміні vdecl. Зараз vdecl жорстко прив'язаний до входу шейдера, що дозволяє драйверу предвичіслять все заздалегідь.

1.11. Прибрані asm-шейдери

Шейдери більше не можна писати на асемблері - потрібно користуватися HLSL. Хоча асемблер для shader model 4.x є і можна дивитися результат компіляції шейдеров в нього, але більше немає можливості отримати бінарний код шейдера з тексту асемблера (то що робили psa.exe / vsa.exe). Отреверсінженіріть бінарний код, втім, ніхто не заважає.

1.12. Компілятор HLSL 4.0

Щоб було легше портувати код шейдерів, компілятор вміє компілювати HLSL-шейдери старих версій (SM2.0, SM 3.0) в SM4.0. У новому HLSL додали атрибути для хинтов компілятору - розмотування циклів і вибір dynamic vs static branching для умовних переходів.

1.13. Еволюційні зміни в шейдерах

У Shader Model 4 додані цілочисельні інструкції і бітові операції (можна вважати в чесному fixed point і передавати булеві прапорці), прибрано обмеження на кількість інструкцій (але дуже довгий шейдер може впертися в обмеження по часу виконання пакету на GPU, до 10 сек)

1.14. Геометричні шейдери (Geometry Shader)

Геометричний шейдер - додатковий шейдер між вершинним (Vertex Shader) і піксельним (Pixel Shader), який може генерувати примітиви. На вхід йому подається примітив з інформацією про сусідів, на вихід - можна згенерувати кілька (не фіксоване число). Основна ідея - нарешті генерувати геометрію на GPU. Geometry Shaders дуже погано підходять для тесселяції і потрібні для всілякої локальної генерації геометрії по дрібниці. Наприклад, можна патікл будувати по одному Вертекс або використовувати стрипи геометрії в post-processing (наприклад, в motion blur - з карти швидкостей генерувати геометричні лінії, по яких Блур картинка (так робить Lost Planet)). Зовсім з іншої області - наприклад, робити рендер в Cubemap за один прохід, GS з'ясовує в які сторони cubemap потрапляє трикутник, і розбиває його на декілька. Основна перешкода використання GS - їх швидкість на сучасному залозі. Гальмують. Основна причина - "анти-паралельність" GS, тобто так як шейдер може видавати variable input і GPU зобов'язана зберігати послідовність виведення трикутників, потрібно вводити проміжну стадію, пішушую в пам'ять, а потім робити фінальний Gather, що вбиває дірки.


1.15. Stream Out

Це можливість записувати результат роботи Vertex Shader / Geometry Shader в пам'ять. Наприклад, кешувати обробку геометрії або взагалі геометрію, створену GS. Можна вважати ітеративні ефекти, типу Cloth / Water. Тобто тепер можна безпосередньо Трансформ і записувати геометрію на GPU, не тільки малювати пікселі в Render Target. Також є можливість читати в шейдерів з буфера в пам'яті за індексом, тобто мати достатньо велику read-only shared memory. NV наприклад пропонує там константи анімації зберігати для інстансінга.

1.16. Зменшення кількості draw calls і перемикань станів

З'явилися масиви текстур, тобто контейнер однакових за розміром і форматом текстур, з якого шейдер може вибирати по індексу (в DX10.1 - можна і cubemap arrays). Це той самий atlasing done right - раніше коли в одній текстурі зберігали декілька різних, доводилося турбуватися за мип-левел, залишати зазор між текстурами і т. д. Тепер не треба. У шейдер приходять primitive / instance id, в залежності від instance ID можна використовувати інший набір текстур / координат / whatever. Очікується, що dynamic branch в шейдерів швидкий (краще, ніж в DX9-hardware), тому можна передавати Material ID і бранч за матеріалами в шейдерів. Тобто, в теорії, можна за один виклик генерувати велику кількість геометрії з різними параметрами, текстурами і взагалі матеріалами. На практиці, найбільше заважає таки вартість dynamic branch і проблем, з ним пов'язаних (обчислення градієнтів текстурних координат). А решта - цілком можна й потрібно використовувати.


1.17. Multi-sampling antialiasing features

Невелика фіча, ради однієї якою можна переходити на DX10. Тепер в шейдери можна читати кожен MSAA-семпл окремо, тобто писати свій власний AA-фільтр, осудно семплів при процессингу і взагалі використовувати MSAA RT як текстуру. Ще й AlphaToCoverage разом з цим тепер офіційно присутня. У D3D10.1 це можна робити і з depth textures.

1.18. Підтримка depth textures

Тепер depth buffer можна використовувати як текстуру. Можна сказати, щоб при семплінг порівнював зі значенням і робив фільтрацію сусідів, можна дістати чистий depth value. Можна навіть stencil value дістати.

1.19. Інші цікаві можливості

  • є рендер в volume texture
  • в DX10.1 можна скопіювати зі звичайної текстури в стислу на GPU
  • є справжній conditional render, тобто можливість викидати цілий draw call за результатами роботи GPU асинхронно (можна робити occlusion culling повноцінно)

1.20. Додаткові факти

Операційна система Windows XP не підтримує DX10. Причина в тому, що перенесення нової драйверної моделі неможливий - потрібно занадто багато змін в ядрі операційної системи. Якщо ж переносити тільки набір нових функціональних можливостей DX10, то теж виникають проблеми: віртуалізацію і шедулінг неможливо здійснити в старій моделі драйвера, перенесення апаратних можливостей - занадто великий обсяг роботи для Microsoft і IHV.


Цей текст може містити помилки.

Схожі роботи | скачати

Схожі роботи:
Direct3D 11
© Усі права захищені
написати до нас
Рейтинг@Mail.ru