Очевидно, дуже багато користувачів, зокрема, всі, хто воліє використовувати комп'ютер установки і проходження сучасних ресурсоємних ігор, знають, що у налаштуваннях графіки можна використовувати спеціальні засоби прискорення виведення зображення і підвищення якості картинки OpenGL чи DirectX. Що краще використовувати для повного використання всіх прихованих ресурсів комп'ютерної системиі досягти максимальної продуктивності? Питання це є досить спірним, і відповісти однозначно на користь якоїсь однієї платформи зазвичай неможливо, оскільки все залежить від конкретної мети, яку ставить перед собою користувач або розробник, а також від кожної конкретної ситуації, яка частково може бути пов'язана з «залізним» обладнанням у вигляді графічного прискорювача, програмною підтримкоюу вигляді драйверів та деякими додатковими аспектами. Спробуємо розібратися, що краще – OpenGL або DirectX, – звернувшись і до офіційних джерел інформації, і спираючись на думки користувачів та розробників програмного забезпечення, які можуть вимагати підтримку таких технологій.

Що таке OpenGL та DirectX?

Почнемо з того, що серед рядових користувачів існує помилкова думка, що ці два описуваних компоненти є графічними двигунами. Звідси і виникають некоректні питання з приводу того, який двигун краще – OpenGL чи DirectX?

Справа в тому, що до двигунів цих платформ відносяться лише частково, оскільки є виключно програмним забезпеченням, що дозволяє взаємодіяти програмному движку програми (ігри) з встановленим обладнанням (найчастіше з відео- та звуковим картами) через їх драйвери, які виконують роль посередників. Насправді OpenGL і DirectX є частиною інтерфейсів прикладного програмуванняз необхідним набором бібліотек, класів, дефініцій, структур, констант та функцій, що застосовуються для забезпечення роботи із зовнішніми програмними продуктами, що встановлюються в операційну систему.

Для чого використовуються ці технології

Звичайно, дуже часто можна зустріти й питання з приводу того, яка графіка краща — OpenGL чи DirectX? Така постановка теж частково є некоректною, оскільки може йтися не лише про задіяння ресурсів відеокарт, а й звукових чи будь-яких інших «залізних» і віртуальних пристроївмультимедіа. Але найчастіше мова справді йде саме про графічні прискорювачі. При цьому потрібно чітко розуміти, що вибір на користь того чи іншого «моста», що забезпечує взаємодію відеокарти із встановленою грою або будь-якою іншою програмою, де це необхідно, може залежати і від того, наскільки обов'язковою є така підтримка.

У сучасних іграх зі складними текстурами та досконало намальованими динамічними сценами така підтримка вкрай необхідна. Але проблема в тому, що далеко не всі графічні прискорювачі можуть правильно використовувати таку підтримку. У цьому випадку все вже залежить від драйверів. Будь карта будь-якої ультрамодної, але з застарілим керуючим ПЗ (драйверами) вона не зможе використовувати всі ті можливості, які спочатку були заявлені виробником. Проте в більшості ігор або в програмах для роботи з мультимедіа (наприклад, для обробки відео) дуже часто і доводиться вибирати, яку саме підтримку встановлювати в налаштуваннях, протиставляючи одну платформу інший (в англійському варіанті це зазвичай виглядає як OpenGL vs DirectX) .

Основні відмінності DirectX та OpenGL

Що ж до основних відмінностей, не вдаючись у технічні аспекти функціонування, відразу ж можна відзначити, що платформа DirectX, що є ексклюзивною розробкою корпорації Microsoft, призначена виключно для застосування в Windows-системах і частково на Xbox, а OpenGL представляє кроссплатформенну технологію, що вільно розповсюджується, застосовну в інших ОС (навіть у мобільних). Ліцензія GNU дозволяє будь-якому бажаючому вносити до компонентів цього API власні зміни та доповнення, що стосуються її вдосконалення з метою підвищення продуктивності тих самих відеокарт, тоді як поліпшень DirectX доводиться чекати лише в міру виходу нових версій платформи. При цьому навіть із найновішими драйверами при використанні на старих версіях мосту графічні прискорювачі не видають заявлених виробником показників.

Головні переваги та недоліки

Говорячи про те, що краще - OpenGL або DirectX 11 (12), окремо варто зазначити, що перша платформа призначена тільки для графіки, а друга може використовуватися взагалі для всього того, що відноситься до мультимедіа (за графіком відповідає компонент Direct3D) .

Крім того, багатьом експертами зазначається, що дуже високого ступеняВибір на користь того чи іншого мосту може залежати від типу графічної карти. Але якщо підходити до порівняння неупереджено, вважається, що в плані охоплення платформ краще виглядає OpenGL, але DirectX виграє в плані того, що є готовим програмним продуктом на кшталт класу Plug&Play. Однак не варто забувати і про те, що інструментальний набір DirectX останніх версійі так доступний OpenGL, а ось зворотної підтримки немає.

OpenGL чи DirectX: що краще для ігор?

Що ж до ігор, і тут однозначної відповіді дати не можна. Так, наприклад, досить часто можна зустріти коментарі з приводу того, що графічні чіпи лінійки Radeon 9800 найкращі результати в тестах показують на основі DirectX, а карти GeForce серії 5XXX – при використанні OpenGL. Зате DirectX має ще одну незаперечну перевагу.

Оскільки міст OpenGL спочатку створювався для інших платформ, з ним у Windows можлива поява різного роду багів, а ось DirectX дозволяє досить непогано користуватися іграми навіть на відносно застарілих комп'ютерахбез жодних гальмувань (яскравий приклад тому – гра Age Of Empires).

Буває і навпаки. Так, наприклад, деякі користувачі відзначають, що DOOM 3 на картах серії Radeon X1XXX використанням OpenGLпросто "літає", а Half-Life 2 дуже часто "гальмує". Але тут, певне, все залежить і від драйверів.

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

Що краще для BlueStacks: DirectX чи OpenGL?

Досить часто можна зустріти і питання щодо використання одного з найпопулярніших емуляторів Android-систем під назвою BlueStacks. Якій платформі віддати перевагу BlueStacks — OpenGL або DirectX? На жаль, і тут однозначної відповіді не можна дати.

Однак негласно вважається, що у разі встановлення через цей емулятор саме ігор, краще задіяти OpenGL, а от, якщо гра гальмуватиме, тоді доведеться перейти на DirectX. Але, знову ж таки, все це стосується лише ігровий графіки. У випадку з професійною обробкоюі рендеринг відео доведеться досить серйозно експериментувати.

Нарешті, якщо говорити про те, що краще - OpenGL або DirectX - для розробника, який тільки починає освоєння цих технологій і робить перші кроки, більшість фахівців у цій галузі відзначають, що спочатку краще ознайомитись із принципами функціонування та інструментальним набором DirectX, оскільки ця платформа виглядає для новачка простіший, і для неї постійно випускаються непогані комплекти SDK, призначені якраз для спрощення адаптації програмних продуктів до «заліза», а потім переходити до вивчення OpenGL.

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

Короткі висновки

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

Очевидно, дуже багато користувачів, зокрема, всі, хто воліє використовувати комп'ютер установки і проходження сучасних ресурсоємних ігор, знають, що у налаштуваннях графіки можна використовувати спеціальні засоби прискорення виведення зображення і підвищення якості картинки OpenGL чи DirectX. Що краще задіяти для повного використання всіх прихованих ресурсів комп'ютерної системи і досягти максимальної продуктивності? Питання це є досить спірним, і відповісти однозначно на користь якоїсь однієї платформи зазвичай неможливо, оскільки все залежить від конкретної мети, яку ставить перед собою користувач або розробник, а також від кожної конкретної ситуації, яка частково може бути пов'язана з « залізним обладнанням у вигляді графічного прискорювача, його програмною підтримкою у вигляді драйверів та деякими додатковими аспектами. Спробуємо розібратися, що краще – OpenGL або DirectX, – звернувшись і до офіційних джерел інформації, і спираючись на думки користувачів та розробників програмного забезпечення, які можуть вимагати підтримку таких технологій.

Що таке OpenGL та DirectX?

Почнемо з того, що серед рядових користувачів існує помилкова думка, що ці два описуваних компоненти є графічними двигунами. Звідси і виникають некоректні питання з приводу того, який двигун краще – OpenGL чи DirectX?

Справа в тому, що до движків цим платформи відносяться лише частково, оскільки є виключно програмним забезпеченням, яке дозволяє взаємодіяти програмному движку програми (ігри) із встановленим обладнанням (найчастіше з відео- та звуковим картами) через їх драйвери, які виконують роль посередників. Насправді OpenGL і DirectX є частиною інтерфейсів прикладного програмування з необхідним наборами бібліотек, класів, дефініцій, структур, констант і функцій, що застосовуються для забезпечення роботи із зовнішніми програмними продуктами, що встановлюються в операційну систему.

Для чого використовуються ці технології

Звичайно, дуже часто можна зустріти і питання з приводу того, яка графіка краща - OpenGL або DirectX? Така постановка теж частково є некоректною, оскільки мова може йти не лише про задіяння ресурсів відеокарт, а й про звукові або будь-які інші «залізні» та віртуальні пристрої мультимедіа. Але найчастіше мова справді йде саме про графічні прискорювачі. При цьому потрібно чітко розуміти, що вибір на користь того чи іншого «моста», що забезпечує взаємодію відеокарти із встановленою грою або будь-якою іншою програмою, де це необхідно, може залежати і від того, наскільки обов'язковою є така підтримка.

У сучасних іграх зі складними текстурами та досконало намальованими динамічними сценами така підтримка вкрай необхідна. Але проблема в тому, що далеко не всі графічні прискорювачі можуть правильно використовувати таку підтримку. У цьому випадку все вже залежить від драйверів. Будь карта будь-якої ультрамодної, але з застарілим керуючим ПЗ (драйверами) вона не зможе використовувати всі ті можливості, які спочатку були заявлені виробником. Проте в більшості ігор або в програмах для роботи з мультимедіа (наприклад, для обробки відео) дуже часто і доводиться вибирати, яку саме підтримку встановлювати в налаштуваннях, протиставляючи одну платформу інший (в англійському варіанті це зазвичай виглядає як OpenGL vs DirectX) .

Основні відмінності DirectX та OpenGL

Що ж до основних відмінностей, не вдаючись у технічні аспекти функціонування, відразу ж можна відзначити, що платформа DirectX, що є ексклюзивною розробкою корпорації Microsoft, призначена виключно для застосування в Windows-системах і частково на Xbox, а OpenGL представляє кроссплатформенну технологію, що вільно розповсюджується, застосовну в інших ОС (навіть у мобільних). Ліцензія GNU дозволяє будь-якому бажаючому вносити до компонентів цього API власні зміни та доповнення, що стосуються її вдосконалення з метою підвищення продуктивності тих самих відеокарт, тоді як поліпшень DirectX доводиться чекати лише в міру виходу нових версій платформи. При цьому навіть із найновішими драйверами при використанні на старих версіях мосту графічні прискорювачі не видають заявлених виробником показників.

Головні переваги та недоліки

Говорячи про те, що краще - OpenGL або DirectX 11 (12), окремо варто відзначити, що перша платформа призначена тільки для графіки, а друга може використовуватися взагалі для всього того, що відноситься до мультимедіа (за графіком відповідає компонент Direct3D) .

Крім того, багатьом експертами зазначається, що дуже високою мірою вибір на користь того чи іншого мосту може залежати і від типу графічної карти. Але якщо підходити до порівняння неупереджено, вважається, що в плані охоплення платформ краще виглядає OpenGL, але DirectX виграє в плані того, що є готовим програмним продуктом на кшталт класу Plug&Play. Однак не варто забувати і про те, що інструментальний набір DirectX останніх версій і так доступний в OpenGL, а ось зворотної підтримки немає.

OpenGL чи DirectX: що краще для ігор?

Що ж до ігор, і тут однозначної відповіді дати не можна. Так, наприклад, досить часто можна зустріти коментарі з приводу того, що графічні чіпи лінійки Radeon 9800 найкращі результати в тестах показують на основі DirectX, а картки GeForce серії 5XXX – при використанні OpenGL. Зате DirectX має ще одну незаперечну перевагу.

Оскільки міст OpenGL спочатку створювався для інших платформ, з ним у Windows можлива поява різного роду багів, а ось DirectX дозволяє досить непогано користуватися іграми навіть на відносно застарілих комп'ютерах без будь-яких гальмувань (яскравий приклад тому - гра Age Of Empires).

Буває і навпаки. Так, наприклад, деякі користувачі відзначають, що DOOM 3 на картах серії Radeon X1XXX з використанням OpenGL просто "літає", а Half-Life 2 дуже часто "гальмує". Але тут, певне, все залежить і від драйверів.

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

Що краще для BlueStacks: DirectX чи OpenGL?

Досить часто можна зустріти і питання щодо використання одного з найпопулярніших емуляторів Android-систем під назвою BlueStacks. Якій платформі віддати перевагу BlueStacks - OpenGL або DirectX? На жаль, і тут однозначної відповіді не можна дати.

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

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

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

Короткі висновки

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

Враховуючи сьогоднішнє домінування DirectX, ми мимоволі забуваємо, що 10 років тому точилася жорстка війна між Microsoft та Silicon Graphics в області 3D API. Дві компанії намагалися завоювати довіру розробників, Microsoft використовувала своє потужне фінансове підживлення, а SGI спиралася на досвід та репутацію в області 3D реального часу. У цій сучасній битві "Давид проти Голіафа" малюк отримав на свій бік одного з найвідоміших ігрових розробників - Джона Кармака (John Carmack). Частково це сталося через успіх двигуна Quake; надійна підтримка OpenGL стала важливим фактором, щоб змусити виробників GPU випускати повний комплектдрайверів. Фактично це дало 3dfx одну з ранніх переваг і відкинуло ATI в аутсайдери, поки компанія вирішувала проблеми з підтримкою OpenGL.

Тим часом Microsoft створювала свій API "з нуля", розвиток був поступовим. Кілька років можливості Direct3D були далекі до бажаного рівня, багато програмістів знаходили API заплутанішим і незрозумілішим, ніж OpenGL. Але ніхто не може звинуватити Microsoft у тому, що ця компанія легко здається. З кожною новою версією Direct3D, API поступово наздоганяв OpenGL. Інженери в Редмонді працювали, не покладаючи рук, щоб забезпечити продуктивність рівня конкуруючого API.

Поворотний момент настав із випуском DirectX 8, який з'явився у 2001 році. Вперше Microsoft API надав більше можливостей, ніж просто копіював API SGI. Були введені власні інновації, подібно до підтримки вершинних і піксельних шейдерів. SGI, чиє головне джерело прибутку полягає у продажі дорогих робочих станцій 3D, опинилася в невдалому становищі, оскільки компанія не змогла передбачити вибухове зростання відеокарт для геймерів, яке дозволило ATI і nVidia проникнути і на професійний ринок з настільно низькими цінами(через економію масштабу), що SGI просто не могла конкурувати. Розробка OpenGL була також ускладнена гарячими суперечками між прихильниками API. Оскільки ARB (група, що відповідає за прийняття нових версій API) включала багато різних і часто конкуруючих компаній, було складно дійти згоди щодо функцій, які потрібно додати до API. Натомість кожна компанія захищала власні інтереси. Навпаки, Microsoft тісно працювала з ATI та nVidia, використовуючи їхню вагу для прийняття рішень, якщо виникали якісь протиріччя.

З випуском DirectX 9 Microsoft вдалося здобути вирішальну перемогу та вразити розробників. Тільки Джон Кармак і ті розробники, яким була важлива універсальність, залишилися віддані OpenGL. Але їхній авторитет похитнувся. Втім, не забуватимемо, що фортуна може і відвертатися. Так сталося з web-браузерами. Нехай навіть компанія подолала важкий шлях, зайнявши фактично монопольне становище, спочивати на лаврах не варто, оскільки конкуренти можуть буквально виникнути з нізвідки. І коли гурт Khronos узявся за розробку OpenGL два роки тому, у багатьох затеплилася надія, і до нинішньої конференції SIGGRAPH було виявлено чималий інтерес.

У серпні Khronos анонсувала OpenGL 3, серйозне оновлення API, яке має наздогнати Microsoft, а програмний гігант, у свою чергу, запланував DirectX 11 API наступного покоління. Але все вийшло дещо інакше.

Щоб повністю зрозуміти суперечності, що оточують оголошення OpenGL 3, нам потрібно повернутися на кілька років тому, у 2002 році. Як ми вже сказали вище, приблизно в той же час OpenGL почав втрачати ґрунт під ногами. До того моменту DirectX просто копіював можливості OpenGL. Цього ж разу Microsoft вдалося випередити API SGI. З випуском DirectX 9, Microsoft додала підтримку високорівневої мовишейдерів HLSL, а OpenGL не було нічого порівнянного. Слід нагадати, що коріння OpenGL лежить в IRIS GL, API, яке спочатку було створено SGI для підтримки всіх функцій "заліза" компанії. Довгий час ATI і nVidia просто слідували моделі рендерингу SGI, тобто OpenGL дуже добре підходив відеокартам виробників з самого їх народження. Але з появою шейдерів нові GPU відхилилися від традиційного рендерингового конвеєра.

На той час одна компанія усвідомлювала важливість швидкого еволюційного розвитку OpenGL, якщо це API сподівається працювати на сучасних GPU: ми маємо на увазі 3DLabs. Це не дивно, оскільки 3DLabs закинула ігрові картипісля невдачі Permedia 2, зосередившись на професійному ринку, де OpenGL є стандартом. 3DLabs представила план з кількох пунктів, який дозволяв OpenGL перейти до нову еру. Перший пункт: додавання високорівневої мови шейдерів GLSL. Далі планувався повний перегляд API. Багато функції APIвже втратили сенс на сучасних 3D-відеокартах, але через зворотну сумісність вони вимагали розробників GPU підтримувати їх принаймні на програмному рівні. Це не тільки призводило до того, що писати драйвери ставало складніше, а також підвищувало ймовірність виникнення помилок, а й спадкові функції робили API досить заплутаним для програмістів-новачків.

Тому 3DLabs хотіла запропонувати набір функцій, який гарантує ефективне виконання GPU, а також усуне застарілі або надлишкові опції. Цей набір функцій був названий OpenGL 2.0 Pure та призначався для розробників нових додатків. Для зворотної сумісності до Open GL 2.0 було додано повний набір розширень OpenGL 1.x.

На жаль, після нескінченних дискусій у рамках ARB цей план було відхилено. І коли OpenGL 2.0 став, нарешті, доступний, все що в ньому було зроблено - лише додана підтримка GLSL в API. Всі інші пропозиції 3DLabs опинилися в кошику для сміття, в результаті OpenGL продовжував відставати від Microsoft API.

Потрібні зміни

Інший приклад демонструє те, що ARB не здатна приймати швидкі та ефективні рішення. Довгий час OpenGL спирався для рендерингу текстур на техніку під назвою pbuffers. Усі програмісти погоджувалися, що ця техніка була складна у розумінні, важка у використанні та давала погану продуктивність. Тому ATI запропонувала розширення її заміни - uber-buffers. Це розширення виявилося вельми амбітним. Крім рендерингу на текстуру, ATI уможливила рендеринг на масив вершин, крім інших розширених можливостей. Можливо, розширення було навіть надто амбітними, на його опис та визначення пішло надто багато часу, програмісти довго чекати не хотіли, тому nVidia та 3DLabs, зрештою, запропонували свій варіант, який принаймні дозволяв виконувати ефективний рендеринг на текстуру, без глобального підходу рішення ATI. Пішло кілька років, перш ніж стало можливо побачити результат усіх цих зусиль - у вигляді розширення під назвою framebuffer_object, яке забезпечує базові функції, що з'явилися ще в DirectX 9!

Так, у 2005 році OpenGL зміг наздогнати Microsoft API, випущений трьома роками раніше. Всі основні гравці (ATI, nVidia, 3Dlabs і розробники ПЗ) погоджувалися, що далі так продовжуватися не може, або OpenGL поступово сходитиме зі сцени, і рано чи пізно буде забутий. У даному контексті ARB передав кермо влади Khronos у 2006 році, і за майбутнє OpenGL почала відповідати ця група. ATI і nVidia присяглися, що вони стануть вищими за власні амбіції і конкуренцію і будуть ефективно співпрацювати, щоб OpenGL став, нарешті, гідний XXI століття. Розробники теж були сповнені ентузіазму, оскільки група Khronos дуже ефективно показала себе в роботі над OpenGL ES, 3D API для мобільних пристроїв.

Дуже швидко гурт Khronos почав відкривати завісу таємниці над майбутнім OpenGL. Знову ж таки, план полягав у переробці API у два етапи. Перша версія, Longs Peak, має забезпечити рівень функціональності R300/NV30 на рівних із Shader Model 2, а також дати нову, більш гнучку модель програмування. Вийшло щось подібне до OpenGL 2.0 Pure, який 3DLabs запропонував кілька років раніше, оскільки гурт Khronos планував прибрати застарілі функції API і сфокусуватися на невеликій кількостісучасні функції. Їхній набір був названий OpenGL Lean and Mean. Друга версія, з кодовою назвою Mount Evans, полягала в оновленні API, принагідно виправляючи всі помилки, які були виявлені, до рівня функцій R600/G80 (Shader Model 4). План розробок був дуже жорстким, у ньому йшлося про появу Mount Evans менше, ніж через шість місяців після Longs Peak. Але учасники гурту Khronos були впевнені у своїх силах.

З часів ARB відбулася ще одна зміна: гурт Khronos вирішив працювати більш відкрито. Вся Нова інформаціяпублікувалася на сайті OpenGL, розповідаючи розробникам про новий API, щоб вони змогли наперед отримати враження про його роботу. Все йшло досить добре до кінця 2007 року. Хоча фінальна специфікація Longs Peak очікувалася у вересні, група Khronos оголосила, що через проблеми вона буде відкладена - без надання будь-яких деталей. Про рішення працювати більш відкрито, прийняте кілька місяців тому, було забуто, і гурт Khronos продовжив свою роботу в інформаційному вакуумі. Жодних новин не було - фактично, про прогрес у галузі нового API не з'являлося жодної інформації.

Викриття

Про OpenGL 3 нічого не було чути до серпня 2008 року, коли проводилася конференція SIGGRAPH. Багато хто чекав приємного сюрпризуПроте новини Khronos виявилися для прихильників OpenGL розчаруванням. API не тільки запізнився приблизно на рік, але й, крім іншого, більшість нових аспектів Longs Peak було повністю забуто. Після фіаско OpenGL 2.0, який насправді став OpenGL 1.6 з іншою назвою, версія OpenGL 3.0 почала виглядати не більше ніж версія 2.2. Неприємний сюрприз разом з відсутністю новин протягом кількох місяців призвели до вельми агресивної реакції на дії групи Khronos всюди на форумах. Оскільки реагувати якось треба, Khronos відповіла на офіційному форумі OpenGL через Бартольда Ліхтенберта (Barthold Lichtenbelt) з nVidia. Його детальна відповідьпринаймні пролив деяке світло на те, що відбувалося в групі. Ми дізналися, наприклад, що за деякими пунктами реалізації плану рішення так і не було прийнято вчасно, і водночас багато хто вважав, що потрібно терміново додати підтримку OpenGL для останніх GPU. Тому план було змінено, щоб розширити OpenGL 2 та додати функції Direct3D 10.

Навіть з урахуванням згаданих аргументів, групу Khronos можна як і раніше критикувати за те, що вона не змогла вчасно сповістити про кризову ситуацію, воліючи її замовчувати. Оскільки те саме сталося шість років тому з OpenGL 2.0, то оптимізму на майбутнє це не вселяє. Після двох обіцянок переписати API – обидва з яких не були виконані – як можна вірити у майбутнє OpenGL? Нарешті, коментар Джона Кармака на останній QuakeCon не приносить полегшення. Коли Джона запитали про стан OpenGL 3 він відповів ще менш політкоректно, ніж Ліхтенберт.

За словами Кармака, провал OpenGL 3, на відміну від поширеної думки, пов'язаний із провалом деяких розробників САПР/CAD, які не дуже добре поставилися до Longs Peak. Вони побоялися проблем із сумісністю та своїми додатками через зникнення деяких старих функцій. Ця версія була тактовно підтверджена Ліхтенбертом: "Під час стадії дизайну Longs Peak, ми прийшли до розбіжностей щодо тих функцій, які будуть прибрані з API... Розбіжності виникли через різні потреби ринків... Ми виявили, що не можемо запропонувати один API для всіх..."

Отже, в результаті OpenGL 3 став не більш ніж черговим оновленням. API насправді не змінилося. Khronos просто назвала деякі функції, що не рекомендуються, а також навела контекст, в рамках якого функції призведуть до помилок. Це набагато менше того, що було обіцяно (розробникам драйверів все одно доведеться підтримувати ці функції), але є кроком вперед, оскільки розробники можуть приготуватися до майбутніх версій, які можуть, нарешті, дати справжній режим Lean and Mean. OpenGL 3 також запроваджує поняття профілів. на Наразіпрофіль тільки один, але за планом будуть створені профілі для ігор та для САПР, наприклад, причому кожен профіль підтримуватиме різні масиви функцій.

Крім цього, набір функцій, запропонований OpenGL 3, дуже схожий на пропозицію Direct3D 10, крім Geometry Shaders і Geometry Instancing, які додані в API як розширення. Але підтримуються і деякі функції Direct3D 10.1, подібно до незалежних режимів змішування (blending) для MRT.

З випуском Direct3D 10 Microsoft удалося зробити найбільш розгорнуту версію свого API з моменту створення. Звичайно, всі ці роки сумісності суттєво обмежили можливості еволюції API, тому метою було створення основи для майбутніх розробок. Звичайно, новий API отримав змішані відгуки від геймерів та розробників.

Microsoft є, за що ганити. Після такого хвастання свого API ще за кілька років до його появи, DirectX 10 привів до розчарувань, коли геймери зрозуміли, що на практиці він нічого особливо не змінює. Додайте до цього і той факт, що новий API був написаний виключно для Vista, тому цілком зрозумілим є негативний настрій до того, що підносилося як маленька революція. Щодо розробників, все виявилося складніше. Зв'язавши Direct3D 10 та Vista, Microsoft суттєво обмежила кількість парку комп'ютерів, який працює з новим API.

Більше того - і це ні для кого не секрет - у Останніми рокамиПК втратив свою роль як ігровий платформиз виходом приставок нового покоління, на які перейшли кілька великих розробників з ПК. id Software, Epic та Lionhead тепер працюють на багатоплатформних проектах, якщо не розробляють ігри виключно для приставок. Оскільки обидві HD-приставки на ринку використовують GPU DirectX 9, розробники мають всі стимули, щоб дотримуватися попереднього API Microsoft.

Чому ми говоримо про Direct3D 11 вже зараз? По-перше, тому що Microsoft нарешті підняла завісу таємниці над власним API. По-друге, оскільки перед нами все ж таки подія, яка дозволяє отримати уявлення про те, чого очікувати від "заліза" наступного року. Більше того, є всі шанси, що Direct3D 11 стане більшим. важливою сторінкоюв історії цього API, ніж версія 10. Якщо Direct3D 10 був повністю переробленою версією, з усіма пов'язаними ризиками, Microsoft має достатній проміжок між версіями 10 і 11, щоб виправити всі проблеми, пов'язані з першою серйозною переробкою API. Тому Direct3D 11 можна назвати серйозним оновленням, хоч і не можна назвати революційним. Новий API побудований на тих же принципах, що й Direct3D 10, він сумісний із попередніми версіями та з "залізом" попереднього покоління. Нарешті, API буде доступний не тільки лише на Windows 7, та й під Vista. Microsoft виправила великі проблеми десятої версії, а серед розробників ходять неофіційні чутки, що вони пропустять Direct3D 10 і перейдуть відразу на версію 11 в майбутніх іграх.

У цьому є сенс із кількох причин. Зазвичай, стадія розробки гри займає від двох до чотирьох років. Тому на той час, коли гра вийде, Direct3D 11 вже затвердиться на парку ПК, оскільки API працюватиме на всіх комп'ютерах з Windows 7, а також і на переважній більшості ПК під Vista. Крім того, дуже ймовірно, що незалежно від дати виходу, приставки будуть використовувати GPU, сумісні з Direct3D 11 (або щось подібне, як Xenos в Xbox 360, який є надбудовою над DirectX 9). Отже, націлювання на такий набір функцій дозволить розробникам захопити ринок приставок наступного покоління. Але ми тут не для того, щоб вивчати ринок. Що дає новий API з технічного погляду?

Багатопотоковий рендеринг

Багатопоточний рендеринг? Але хіба ми вже не використовуємо багатоядерні CPU протягом кількох років і розробники не навчилися з ними працювати? Що ж може бути нового в багатопотокових двигунах рендерингу Direct3D 11? Деякі з вас будуть здивовані, але сучасні двигуни, як і раніше, використовують тільки один потік для рендерингу. Інші потоки використовуються для звуку, розпакування ресурсів, фізики та ін. Але рендеринг серйозно навантажує CPU, то чому б його не рознести на кілька потоків? На те є кілька причин, деякі з них пов'язані з тим, як працює GPU, а інші – з 3D API. Тому Microsoft вирішила усунути програмні проблеми, а також допомогти вирішити апаратні.

На перший погляд, розпаралелювання процесу рендерингу виглядає привабливо, але якщо ви придивитесь уважніше, то зрозумієте, що GPU тут тільки один (навіть якщо кілька GPU з'єднуються через SLI або CrossFire, їх метою є створення ілюзії, що працює один, віртуальний GPU), тому та буфер команд тільки один. Коли один ресурс використовується кількома потоками, технологія взаємного виключення (mutual exclusion, mutex) запобігає одночасному запису команд від кількох потоків, щоб вони не заважали один одному. Це означає, що всі переваги використання кількох потоків усуваються однією критичною секцією, яка робить код послідовним. Ніякий API не може вирішити цю проблему - вона успадкована зі способу зв'язку CPU і GPU. Але Microsoft пропонує API, яке може спробувати її обійти. У Direct3D 11 з'явилися вторинні буфери для команд, які можна зберегти та використовувати пізніше.

Тому кожен поток має відкладений контекст, де записані команди у списку (Display List), який можна вставити в головний потік обробки. Цілком зрозуміло, коли список запитується основним потоком (команда "Execute" на слайді "Multi-threaded Submission" нижче), потрібно переконатися, що потік перестав його заповнювати. Тому синхронізація, як і раніше, є, але модель виконання, принаймні, дозволяє зробити деяку роботу рендерингу паралельною, хоча, звичайно, прискорення, що виходить, не можна визнати ідеальним.

Ще одна проблема попередніх версій Direct3D пов'язана зі створенням ресурсів – наприклад, текстур. У поточних версіях API (9 і 10) ресурси доводилося створювати в потоці рендерингу. Розробники обійшли цю проблему, створивши потік, що зчитує та розпаковує текстури з диска, після чого заповнює ресурс (об'єкт Direct3D), який створено в основному потоці.

Але, як можна бачити, більша частина робочого навантаження, як і раніше, залишається в основному потоці, який і так перевантажений. Це не дає оптимального балансу, який потрібний для швидкого виконання. Тому Microsoft додала новий інтерфейс Direct3D 11: програміст може створювати один об'єкт "Device" на потік, який можна використовувати для завантаження ресурсів. Синхронізація функцій об'єкта "Device" проводиться більш тонко, ніж у Direct3D 10, і набагато економічніша за ресурсами CPU.

Теселяція

Основний новою функцією Direct3D 10 стала поява геометричних шейдерів, які нарешті дозволили створювати або знищувати вершини силами GPU. Але роль цього блоку який завжди розуміють правильно. Він не тільки забезпечує масовану підтримку геометрії, але й краще підходить для реалізації гнучкіших точкових спрайтів (Point Sprites), Fur Shading, або для розрахунків силуету об'єкта для алгоритмів об'ємних тіней. Нічого немає краще, ніж спеціальний блок для виконання тесселяції. Спочатку він планувався для Direct3D 10 (що пояснює присутність блоку в лінійці Radeon HD), але, схоже, Microsoft, ATI і nVidia не змогли досягти угоди вчасно, тому блок зник зі специфікацій, повернувшись тільки з Direct3D 11. Тому тесселяція є новою великою. Direct3D 11 – або, принаймні, тієї, яку простіше продавати не фахівцям.

На відміну від інших щаблів конвеєра, ці щаблі працюють не з трикутниками як примітиви, а з патчами. Hull Shader бере контрольні точкидля патчу на вході, після чого визначає деякі параметри Tesselator, такі, наприклад, як TessFactor, який показує рівень якості тесселяцції. Tesselator - блок із фіксованими функціями, тому програміст неспроможна проводити те, як виробляється розрахунок тесселяції. Блок відсилає отримані точки Domain Shader, який може застосовувати до них операції. Дозвольте навести приклад, який допоможе краще зрозуміти. Візьмемо приклад, який піднімався з кожним поколінням з часів Matrox Parhelia – карти усунення (Displacement Mapping).

Як вход для вершинного шейдера у нас є контрольні точки патча. Програміст може змінювати їх як йому хочеться, оскільки їх не так і багато. Щоб спростити ми взяли дуже грубу версію фінальної сітки. Трансформовані точки потім передаються Hull Shader, який визначає, скільки разів потрібно ділити кожну площину патча (наприклад, як функцію розміру патча в пікселях дисплея). Tesselator виконує тесселяцію. Тобто створює геометрію, яка пересилається до Domain Shader. Блок переміщує точки, створені для відповідного простору (точки, що виходять із Tesselator, знаходяться у просторі патча), створюючи класичні вершини, які він може зміщувати як функцію текстури, тобто робити Displacement Mapping.

Потенціал величезний. Завдяки тесселяції, можна обійтися без карти нормалей і реалізовувати рівень деталізації безпосередньо на GPU, дозволяючи використовувати дуже деталізовані моделі (кілька мільйонів полігонів замість 10 000 або близько цього числа в сучасних іграх) - принаймні теоретично. На практиці тесселяція призводить до появи деяких проблем, які не дозволяють цій техніці розвернутися на повну силу. Чи зможуть Direct3D 11 та сумісні карти обійти "підводне каміння" і представити функціональну версію? Поки ще занадто рано щось стверджувати, але, у будь-якому випадку, переконати вдалося не всіх, та ж id Software працює над вирішенням тієї ж проблеми геометрії через зовсім інший підхід, що базується на ray casting з вокселями.

Обчислювальні шейдери

Як ми згадували у нашій статті про CUDA, Microsoft не бажає втратити з рук ринок GPGPU, тому компанія створила власну мову, щоб GPU працював над іншими завданнями, а не лише малював гарні картинки. Відгадайте, що? Вибрана Microsoft модель, подібно до OpenCL, дуже нагадує CUDA, підтверджуючи перспективність погляду nVidia. Перевага над рішенням nVidiaлежить в універсальності - обчислювальні шейдери (Compute Shader) працюватимуть на GPU nVidiaі ATI, на майбутньому Intel Larrabee, а також мати кращу інтеграцію з Direct3D, нехай навіть у CUDA вже утворилася певна підтримка. Але ми не будемо приділяти цій темі багато часу, нехай вона цього гідна. Натомість ми плануємо за кілька місяців представити окрему статтю, яка розповідає про OpenCL і Compute Shaders.

Поліпшений стиск текстур

Вперше з'явившись у DirectX 6 десять років тому, функція стиснення текстур DXTC швидко поширилася на ринку GPU, її дуже активно використовують розробники. Звичайно, технологія, розроблена S3 Graphics, була ефективна, а накладні апаратні витрати були скромними, що, безперечно, пояснює успіх. Але тепер потреби змінилися. DXTC не розроблялася для стиснення карток нормалей і не враховувала HDR-рендерінг. Тому мета Direct3D була подвійна: дозволити стиснення HDR-текстур та обмежити "блочність" традиційних режимів DXTC. Для цього Microsoft додала два нових режими: BC6 для HDR-текстур та BC7 для покращення якості стиснення зображень LDR.

Shader Model 5

З поданням Shader Model 5, Microsoft намагається перекласти кілька принципів об'єктно-орієнтованого програмування на мову шейдерів HLSL. На відміну від попередніх версій, які представляли нові можливості (динамічне розгалуження/Dynamic Branching, підтримка цілих чисел і т.д.), в даному випадку мета полягає у полегшенні роботи програмістів, вирішуючи поширену проблему в сучасних ігрових двигунів: зростання числа шейдерів через велику кількість перестановок. Візьмемо конкретний приклад: уявіть, що двигун працює з двома типами матеріалів, пластиком і металом, а також двома типами освітлення: світлова пляма (spot) та розсіяне світло (omni). Щоб передбачити всі випадки, програмісту потрібно написати чотири шейдери:

Приклад дуже простий, оскільки тут лише два матеріали та два типи освітлення, але на практиці їх може бути кілька десятків. Якщо продовжувати так само, ситуація може швидко вийти з-під контролю. Ми отримуємо безліч дубльованого коду, і якщо виявляється якась помилка, її потрібно виправляти у всіх шейдерах. Щоб вирішити цю проблему, програмісти використовують так званий uber-shader, який разом з'єднує всі комбінації.

Light і Material - це інтерфейси, а код міститься у похідних класах OmniLight та SpotLight, PlasticMaterial та MetalMaterial. Тому код повністю розміщений в одному місці, редагування вносити простіше. У той же час і зручність читання не страждає завдяки організації коду, що нагадує принцип віртуальних функційв об'єктно-орієнтованих мовах. Ця функція напевно буде схвально зустрінута програмістами, хоча геймерам вона навряд чи щось дасть.

Інше

Як ви розумієте, ми лише коротко розглянули нові функції Direct3D 11, та й Microsoft ще не опублікувала всіх деталей. Серед тем, які ми не згадали, є збільшення максимального розміру текстури з 4K x 4K до 16K x 16K, а також можливість обмежувати кількість mip-карт, завантажених у VRAM. Є також можливість зміни значення глибини пікселя, не відключаючи такі функції, як ранню перевірку Z, підтримка змінних з плаваючою комою подвійної точності, розкид запису на пам'ять (scatter memory write) тощо.

Висновок

Ми багато чого чекали від OpenGL 3, і, як ви можете судити за статтею, ми були розчаровані як самим API (з якого зникли обіцяні функції), так і його розробкою (річна затримка та відсутність інформації з боку групи Khronos). З новою версією OpenGL ледве зміг наздогнати Direct3D 10, водночас Microsoft опублікувала перші деталі про 11 версію свого API.

Нічого революційного від Microsoft не варто очікувати, але, на відміну від OpenGL, Direct3D вже пережив повну перебудову своєї архітектури два роки тому. Звичайно, далеко не все було гладко, але сьогодні Microsoft може пожинати плоди зусиль з перебудови API на нову потужну основу.

Поза всякими сумнівами, Редмонд дивиться у майбутнє, а щодо OpenGL складається враження, що Khronos задовольняється підтримкою поточного покоління GPU. Сподіватимемося, що ми помиляємося, і еволюція OpenGL 3 піде набагато швидше, оскільки це єдине API, доступне для мультиплатформної розробки. Але надто багато накладок похитнули нашу віру в розвиток цього API.

OpenGL(= Open Graphics Library) - це програмний інтерфейсДля управління графічним процесором складається приблизно з 250 команд, зашитих у двох бібліотеках oglcore та oglutilities. Розробляється з 1990 компанією SGI (Silicon Graphics Inc.). Мета - створення мульти-платформного графічного інтерфейсудля розробників графічних карт та програмного забезпечення.

DirectX- це загальна назва для колекції з 10 Windows-бібліотек (див. таблицю нижче) для низькорівневого програмування "заліза" від різних виробників. Розробляється компанієюMicrosoft з 1994 (перша назва "Games SDK") з функціоналом, що постійно змінюється, розділеним на версії ( поточна версія 11). Мета та Головна задача- позиціонувати Windows як платформу для Multimedia. Майже всім Graphiс-, Sound-, Radio-, Video-, TV- hardware розроблені DirectX-Драйвера.
До версії DirectX 9.0 (включно) DirectX-бібліотеки принципово відрізнялися від інших Windows-APIs (Application Programming Interfaces). Вони не гарантували виконання необхідних запитів. Кожен програміст повинен самостійно контролювати - чи може програмоване через DirectX залізо виконати потрібну операцію, і якщо так, то в якому обсязі і формі. На практиці багато програмістів довіряютьDirectX-Драйверам з надією на те, що Драйвер цільового заліза настільки хороший, що не просто відхиляє некоректні для даного заліза запити, а спробує за допомогою аварійної системиїх опрацювати коректно. (Див. нижче опис HEL).

Згодом з'явилося кілька підходів до програмування DirectX:
1) C++ та DirectX Software Development Kit = DXSDK ;
2) Managed DirectX для C# - приблизно також швидкий у виконанні, але простіше у програмуванні, ніж 1) і є частиною DXSDK;
3) XNA для C# - це послідовник 2) нових Windows-PC, XBox, Windows-Phone;
4) Windows Presentation Foundation = WPF разом з XAML та C# → DirectX11 упаковано в одну величезну бібліотеку класів.

Managed DirectXшвидко став популярним, тому що пропонував простий та елегантний доступ до DirectX з високою швидкістю виконання, і в період з 2002 по 2007 став найпопулярнішою оболонкою для розробки PC-ігор під WindowsXP.
У 2007 році Microsoft оголосив про розвиток Managed DirectX розробивши два нових DirectX-APIs:
1) XNA , який на відміну Managed DirectX значно спрощував доступ до DirectX для розробок на PC-, XBox-і WindowsPhone-платформах;
2) WPF , з метою повної та цілісної інтеграції DirectX у всі програмні оболонки та інтернет-сторінки.

OpenGL Libs та DirectX Namespaces

OpenGL складається із двох бібліотек (DLL), які виключно заточені на Графіку.
Microsoft під ім'ям DirectX зібрав усе, що в рамках операційної системи звертається безпосередньо до заліза. У Managed DirectX ці бібліотеки організовані у вигляді Namespaces. Тільки перші чотири з цих Namesspaces займаються Графікою.

OpenGL & Direct3D Pipeline

Графічний чіп сучасної графічної карти містить безліч графічних процесорів у формі про каскадних пайплайнов (Pipeline). Перша половина цих процесорів зайнята роботою з векторною графікою, друга з растрової графіки. Ланцюжки команд OpenGL і Direct3D відображають принцип ланцюжків процесорів графічного чіпа. Отже набір команд OpenGL та Direct3D спрямовані приблизно порівну на 3D-Векторну та Растрову графіку. Таким чином, фундаментальна відмінність між вектором і Растрова Графіканейтралізується та ховається, щоб полегшити вирішення проблеми Векторно-Растрового переходу. Також ховається проблема поділу роботи між CPU та GPU, що ще складніше з огляду на різноманітність можливих варіантів.

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

Схема 3D-Pipelineв OpenGL & Direct3D повторює архітектуру GPU:

У DirectX є можливість відключити всю векторну частину через прапор CreateFlags.SoftwareVertexProcessing. Якщо в комп'ютері немає повноцінного або взагалі ніякого GPU, то Pipeline симулюватиметься всередині OpenGL/DirectX, використовуючи для всіх розрахунків CPU. У цьому випадку дані терміни – Vertex Shader, T&L Engine, HSSL/Cg – не мають жодного сенсу і краще говорити про CPU-графіку – HEL und HAL.

Vertex Shader = Каскад послідовно включених мікропроцесорів усередині GPU. Сучасні GPU містять до 8 таких каскадів паралельно: програма, написана наHLSL або для Vertex Shader також називається Vertex Shader.
Завдання Vertex Shader: перетворення 3D-трикутників (у світових координатах) на 2D-трикутники (в екранних координатах).
Процеси у Vertex Shader: Tesselation (тріангуляція), координатна трансформація, 3D-Scroll+Zoom+Rotation, Clipping, Back Face Culling.
T&L Engine- Transform & Light Engine - Fixed Vector Pipeline - найменування від одного до 8 паралельних Vertex Shader, які програмуються через заздалегідь прошиті алгоритми (Firmware), що не дають великої свободи, але при цьому значно швидші. Управління цими Firmware здійснюється з поза, через:
a) прапори станів, Приклад: device.Lights.Enabled = true; і
b) 3x3-матриці, Приклад: device.Transform.View = Matrix.LookAtLH(new Vector3(0f, 0f,-4f),
new Vector3(0f, 0f, 0f),
новий Vector3(0f, 1f, 0f)); .

Clipping= обрізка ліній та конвексних полігонів по межі екрану через алгоритм Коена-Сазерленда.
Back Face Culling: приблизно 50% трикутників звернено до спостерігача. тильною стороною- якщо ці полігони викинути з розрахунків, це прискорить растрові операції приблизно вдвоє.
Pixel-Shader = Rasterizer = включений після Vertex-Shader спеціальний процесорграфічного чіпа, що спеціалізується на растровій графіці = текстурування та відмальовування (рендер) окремого Піксела, програмується черезHLSL або у графічному чіпі міститься до 32-х паралельних Pixel-Shader.
Texture= деформація растрового прямокутника так, що він уміщається в заданий полігон.
BitBlitter= скорочення від Bit Block Transfer = додавання розтеризованих шрифтів, ліній, чотирикутників, еліпсів і т.д.
Z-Test= Depth Test = Видалення прихованих пікселів.
Alpha & Color Blending= накладання масок прозорості.
Fog= Додавання туману в залежності від відстані між спостерігачем та об'єктом.
Dithering= згладжування кольорів.

HEL та HAL

Під час встановлення Драйвера Графічних карт, звукових карт, джойстиків тощо. визначаться в операційній системі у формі Device Driver Interface DDI. За допомогою певного DDI кожна DirectX-Бібліотека при старті ініціалізує один Hardware Emulation Layer HEL і один Hardware Abstraction Layer HAL. HEL містить низькорівневі виклики базових функцій та коду CPU. HAL містить зовнішні, автономні мікро-програми для графічних, звукових карт і т.д. HAL має більше високий пріоритетвиконання, ніж HEL, але при цьому всі бібліотечні виклики виконуються навіть тоді, коли HAL мало що може. HEL-Графіка, HEL-Анімація, HEL-Звук, HEL-Відео та ін., як правило, повільні у виконанні, але вони гарантовано здійсненні.
Виробники CPU - Intel та AMD конкурують з виробниками Графічних та Мультимедійних карт. Вони постійно покращують графічну та звукові компоненти та загальну архітектуру CPU, щоб посилити HEL проти HAL. І роблять це з великим успіхом: у простих іграх та мультимедіа важко помітити різницю у продуктивності, і для офісних програм досить звичайного on-board-Videocontroller без окремої відео-пам'яті (використовується загальна пам'ять).

Приклад: промальовування через GDI+ чи DirectDraw HEL/HAL Існує три шляхи, щоб щось намалювати: 1) звичайний Windows-дзвінок без DirectX працює через GDI+ та DDI. Приклад: graphics.DrawLine(mypen, 0, 0, 100, 100); 2) через DirectDraw, HEL та DDI 3) через DirectDraw та HAL Якщо варіант 3) існує, то 2) закрито. 3) швидше, ніж 2) та 2) швидше, ніж 1) . GDI+ та DirectDraw-команди можна вільно змішувати. GDI+ Info: http://msdn.microsoft.com/library/GDIPlus.asp

Direct3D Device

це найважливіший Direct3D-Клас, який безпосередньо керує графічною картою. Його головна функція - Device.Present, перемикати BackBuffer Графічної Карти на FrontBuffer і таким чином відображати функцію на моніторі.
Далі цей клас містить Властивості/Функції як для векторної графіки(Viewport, Vertex Format, Transform) і для Растрової Графіки (Material, Texture, адреси і довжини для Output-Buffer).
При старті будь-якої програми, яка використовує Direct3D, створюється даний класта резервуються ресурси та права доступу до Графічної Карти.

DirectX, Windows 7/8

Починаючи з W7 весь інтерфейс користувача базується на DirectX. Таким чином, DirectX вже не просто графічна бібліотекаа основна частина операційної системи. Microsoft наказує розробникам графічних чіпівдетальний план необхідної функціональності, якому повинні відповідати всі драйвери між операційною системою і DirectX. Виробники немає особливих варіантів - вони мають слідувати розпорядженням Microsoft, інакше вони втрачають ринок Windows-машин. см:Windows Display Driver Model WDDM W7 Display Driver Model Windows Driver Kit (WDK)

Плюси:
1) Можна покластися на те, що W7 використовує Графічне залізо на повну. Немає DDI не HEL, лише HAL.
2) Можна бути впевненим, що будь-який драйвер для W7 пропонує мінімальний набір команд "Direct3D 10".
3) Інтерфейс користувача W7 пропонує швидку високоякісну графіку, прозорість, анімацію, 3D і відео.
4) Інтернет-сторінки можуть використовувати WPF для швидкої DirectX-графики.

Мінуси:
1) Старі Графічні карти, принтери, сканери, що не мають DirectX10.1-драйвера не працюватимуть під W7.
2) Старі DirectX-ігри, як правило, не працюють під W7.

Windows Presentation Foundation WPF

Основними елементами W7-графики є:
a)Desktop Window Manager= DWM
b) Windows W7 Display Driver Model = WVDDM або коротше WDDM, що підтримуються W7-Графічними картами.
Працює так:
1.) Всі вікна та графічні елементи(включаючи шрифти) W7 - це векторна графіка.
2.) Дані та команди Векторної Графіки зберігаються, керуються та позиціонуються через DVM.
3.) DVM передає дані та команди WVDDM-драйверу.
4.) Драйвер перетворює все у формат даних та команд DirectX і завантажує це все у свою Графічну карту.
5.) Графічний пайплайн на карті малює картинку автономно (без участі CPU) з максимальною швидкістюу Back-Buffer.
6.) як тільки Back-Buffer заповнений, Графічна карта перемикає його як у стан Front-Buffer для виведення на екран.