1. ⇡ # Нові функції Direct3D 12 і Vulkan
2. ⇡ # Асинхронні обчислення в Direct3D 11 і Direct3D 12
3. ⇡ # Multi-Engine на GPU різної архітектури: AMD GCN

Інтерфейси прикладного програмування (API) довгий час залишалися найбільш консервативними компонентом 3D-графіки. Стандарт Direct3D 11 був представлений ще в 2008 році, і до сих пір основна маса нових ігор на ПК використовує його в якості основного і в переважній більшості випадків єдиного API. Цей острівець стабільності в надзвичайно швидко розвивається індустрії, який є комп'ютерні ігри, утворився аж ніяк не через традиціоналізму розробників ПЗ або виробників заліза. Навпаки, єдиний стандарт Microsoft, який витіснив з великої гри колись могутнього суперника (OpenGL), дав можливість всім учасникам ринку сконцентрувати зусилля на своїх прямих завданнях без необхідності оптимізувати драйвери, архітектуру GPU і ігрові движки під кілька API одночасно (як в билинні часи під Glide і популярний OpenGL).

Нещодавні потрясіння в цій сфері, пов'язані з назвами DirectX 12 і Vulkan, викликані, по суті, зусиллями єдиної компанії - AMD, яка в 2013 році випустила власний інтерфейс програмування Mantle у співпраці з DICE, автором ігрової серії Battlefield. В даний момент робота над Mantle припинена, але обидва універсальних API нового покоління запозичили ідеї AMD і переслідують ту ж мету - більш ефективно використовувати обчислювальні ресурси, які є в розпорядженні сучасних GPU.

Незважаючи на настільки привабливу ідею Direct3D 12 (тут і далі ми будемо говорити саме про графічної бібліотеці в складі DirectX) і Vulkan, темп впровадження нових API залишає бажати кращого навіть у порівнянні з Direct3D 11, якій знадобився надзвичайно довгий термін, щоб цілком переманити розробників з Direct3D 9. і все ж творці значного числа гучних і високобюджетних проектів останніх двох років впровадили підтримку Direct3D 12 або Vulkan принаймні у вигляді експериментальної або побічної функції. Зрештою, методика тестування GPU на 3DNews вже здебільшого складається з ігор з підтримкою цих API. Слушна нагода для того, щоб провести дослідження і зробити проміжні висновки про те, наскільки корисні DirectX 12 і Vulkan для продуктивності сучасного заліза.

⇡ # Нові функції Direct3D 12 і Vulkan

Про засади, що лежать в основі Direct3D 12, і його відмінності від попередньої версії API Microsoft, ми писали в 2014 році, коли стандарт знаходився на ранній стадії розробки і багато хто з його особливостей ще не були фіналізовані. Головне, що змінилося в зовнішності Direct3D 12 з тих пір, - це набір додаткових функцій рендеринга, відкритих для графічних процесорів з тими чи іншими апаратними можливостями.

Залишимо за кадром будова конвеєра рендеринга і деякі особливості програмування під Direct3D 12, які описані в нашій давньої статті. Є лише кілька відмінних рис нового API, які повинні хвилювати широку публіку. Почнемо огляд з універсально значущих пунктів і закінчимо тієї самої функцією Direct3D 12 (і Vulkan), яка породила багато суперечок, нерозуміння і завищених очікувань на сторінках публікацій і форумів, - асинхронними обчисленнями.

Найпривабливішою рисою Direct3D 12 і Vulkan є швидка підготовка т. Н. draw call. У той час, коли AMD прагнула популяризувати Mantle, безліч людей, раніше далеких від програмування комп'ютерної графіки, були змушені познайомитися з цим терміном. У 3D-рендеринга так називається команда, яка потребує створити єдину полігональну сітку (mesh). В іграх кожна модель персонажа, юніта і практично будь-якого незалежного об'єкта є mesh. Отже, чим більше таких об'єктів присутній на екрані, тим більше draw calls повинен віддати центральний процесор. Коротка підготовка draw call в Direct3D 12 при інших рівних умовах знижує навантаження на CPU, скорочує час бездіяльності графічного процесора і в результаті дає можливість виводити більше об'єктів на екран. Допомагає і розподіл навантаження в многоядерной системі, яке в Direct3D 12 відбувається більш ефективно.

Багатоядерні CPU в Direct3D 12

В цілому прошарок API в стеці ПО, що управляє графічним процесором, стала тонше в порівнянні з Direct3D 11 за рахунок того, що багато функцій, які в Direct3D 11 виконуються в тій чи іншій мірі автоматично (такі як управління пам'яттю, синхронізація між чергами інструкцій, підтримання паралелізму навантаження на GPU і ін.), тепер повністю належать ігровому движку. З одного боку, відкриваються широкі можливості для оптимізації швидкодії, але з іншого - програміст повинен мати на увазі особливості архітектури різних GPU, щоб уникнути падіння продуктивності.

Direct3D 12 приніс масу функцій рендеринга, описаних в рамках feature levels 12_0 і 12_1. Але на відміну від попередніх ітерацій Direct3D, 12-я версія призначена не для того, щоб явити світові щось раніше небачене (як це було з шейдерами в Direct3D 8 і тесселяції полігонів в Direct3D 11). Дійсно, деякі можливості feature levels 12_0 і 12_1 підвищують якість певних ефектів (наприклад, пов'язаних з прозорими текстурами), а інші використовуються в перспективних алгоритмах рендеринга (див. Опис VXGI в нашому огляді GeForce GTX 980 ). І все ж більшість пунктів feature levels 12_0 і 12_1 служить для того, щоб графічний процесор виконував швидше ряд вже відомих задач, які в іншому випадку створюють велике навантаження на пропускну здатність блоків накладення текстур, шину пам'яті та ін.

В принципі, додаткова обчислювальна потужність, яку вивільняє нова версія API, сама по собі дозволяє збагатити ігрову графіку більш деталізованими текстурами і об'єктами. Більш того, в деяких іграх під Direct3D 12 і Vulkan геймплей тісно пов'язаний з вибором API (як в Ashes of the Singularity, яка за рахунок безлічі юнітів на екрані створює величезну кількість draw calls). Але якщо поставити питання в формулюванні «Чи стане гра виглядати краще, якщо включити в неї Direct3D 12 або Vulkan?», То на даний момент відповідь буде в переважній більшості випадків негативним. Масштаб впровадження нових API все ще занадто малий, а залізо на руках користувачів занадто різноманітно, щоб розробники ігор відкрили для відеокарт, добре працюють під Ditect3D 12 і Vulkan, ексклюзивний доступ до помітної частини візуального контенту.

Підтримка функцій рендеринга Direct3D 12 в GPU різної архітектури ( Wikipedia )

За мінімальним вимогам стандарту в категорію GPU, сумісних з feature level 12_1, проходять тільки архітектури Vega, Maxwell і Pascal (а також інтегрована графіка Intel, починаючи з процесорів Skylake), а найбільш повною підтримкою володіє Vega і Intel HD Graphics. Але і інші архітектури AMD або NVIDIA на тому чи іншому рівні підтримують ряд функцій з feature level 12_0 і 12_1, в тому числі одні з найкорисніших: Conservative Rasterization , Volume Tiled Resources і Rasterizer Ordered Views .

При цьому від графічного процесора не потрібна сумісність з feature level 12_0 і 12_1 для роботи під Direct3D 12. Насправді GPU з можливостями на рівні feature level 11_0 і 11_1, створені в ту пору, коли Direct3D 12 не було і в помині (архітектури Femi і Kepler від NVIDIA і GCN першого покоління від AMD), можуть скористатися всіма перевагами runtime-бібліотеки Direct3D 12 і, потенційно, отримати виграш у швидкодії. У AMD і NVIDIA підтримка Direct3D 12 в драйвері починається з серій Radeon HD 7000 і GeForce GTX 400 відповідно.

⇡ # Асинхронні обчислення в Direct3D 11 і Direct3D 12

Сучасні GPU лише в силу звички називаються графічними процесорами. Архітектура, що складається з великої кількості виконавчих блоків (ALU, потокових процесорів або CUDA-ядер, в термінології різних виробників), підходить для виконання будь-яких програм, легко розділяються на незалежні один від одного ланцюжка операцій (GP-GPU, General Purpose GPU) - будь то промислові завдання, майнінг криптовалюта, машинне навчання і т. д.

Методи GP-GPU застосовуються і в іграх (щонайменше з того часу, коли NVIDIA купила компанію - творця «фізичного прискорювача» Ageia і адаптувала її API PhysX для роботи на графічних процесорах), але жодна з комерційних ігор ще не може похвалитися тим , що розкрила потенціал неграфічних розрахунків в такій мірі, як «демки» PhysX, які періодично демонструє NVIDIA. Причина лежить на поверхні: навіть кращі GPU не володіють надлишком ресурсів для того, щоб дійсно масштабні обчислення ігрової фізики не знищили частоту зміни кадрів. Тим більше в той час, як перед розробниками ПЗ і заліза відкрилися більш привабливі перспективи - дозвіл надвисокої чіткості і VR.

Однак актуальні і потенційні функції обчислень загального призначення в сучасних іграх не обмежуються фізикою. SSAO (Screen-Space Ambient Occlusion), локальні відображення в екранному просторі (Screen-Space Reflections), генерація карт тіней, різні моделі глобального освітлення тощо. Можуть бути реалізовані в якості методів GP-GPU. Неважко помітити, що в даному випадку відсутня принципова межа між завданнями двох типів. Вона існує лише на рівні архітектури додатку і API, коли графіка і обчислення представляють собою окремі черги інструкцій. Саме одночасне виконання множинних черг інструкцій лежить в основі того, що називають (не цілком коректно, але про це пізніше) асинхронними обчисленнями.

В рамках Direct3D 11 існує єдина чергу інструкцій для рендеринга графіки. І як би ретельно не була оптимізована архітектура GPU, в процесі рендеринга неминуче виникають «бульбашки», коли шейдерниє ALU простоюють, в той час як свою роботу виконують інші компоненти процесора - блоки накладення текстур, ROP, шина пам'яті і т. Д.

У свою чергу, Direct3D 12 і Vulkan дозволяють створити дві окремі черги - для графіки і обчислень відповідно (без урахування черзі для передачі даних по шині PCI Express), а завдання розподілу ресурсів GPU між ними лягає на сам процесор і його драйвер, які стежать за виникненням «бульбашок» в тій чи іншій черзі і ефективно їх закривають за рахунок інструкцій з сусідньої черги. У загальних рисах підхід аналогічний функції Hyper-Threading центральних процесорів.

Прим .: н а насправді в Direct3D 12 і Vulkan можна створювати множинні черги всіх трьох типів - в залежності від того, скільки підтримує GPU.

Залишилося пояснити, чому термін «асинхронність» не кращим чином описує те, що відбувається в процесі рендеринга з двома чергами інструкцій, які ми обережно назвали окремими, але не незалежними. Коректний (і офіційний для Direct3D 12) термін - Multi-Engine. Справа в тому, що ті процедури, які виконуються в «графічної» і «обчислювальних» чергах Direct3D 12 або Vulkan, як правило, містять взаємні залежності даних: виконання інструкцій в одній черзі має бути зупинено, доки не буде отримано результат певної інструкції з іншої черги.

У такому випадку можна говорити лише про одночасне (concurrent), але не асинхронному (незалежному за часом завершення) виконанні. Прикладом справжньої асинхронности є фоновий процес з низьким пріоритетом, що протікає одночасно з рендерингом кадру, - такий, як декомпресія ресурсів, оновлення карт тіней в моделях глобального освітлення тощо. (Див. Слайд AMD вище). Таким чином, термін «асинхронні обчислення» застосуємо до вузького кола завдань, в той час як поняття Multi-Engine описує одночасне виконання декількох черг обчислювальних інструкцій безвідносно до структури залежностей між ними.

«Асинхронні обчислення» не завжди асинхронні

⇡ # Multi-Engine на GPU різної архітектури: AMD GCN

Розглянемо животрепетне питання практичної реалізації Multi-Engine. Популярне думка говорить, що а) графічні процесори AMD виграють від застосування Multi-Engine, в той час як чіпи NVIDIA (включаючи Pascal) не можуть настільки ж ефективно використовувати його в силу архітектурних обмежень, б) серед архітектур NVIDIA тільки Pascal підтримує Multi-Engine . Як нам матимуть змогу переконатися, обидва твердження в цілому вірні, але повна картина далеко не така однозначна.

Найпростіший для аналізу випадок - це архітектура GCN (Graphics Core Next), на якій базуються всі графічні процесори AMD останніх років, починаючи з Tahiti ( Radeon HD 7950 / 7970 ) І закінчуючи Vega 10 ( Radeon RX Vega 56 / 64 ). Як гідності, так і недоліки чіпів AMD в дійсності мають у своєму розпорядженні до застосування Multi-Engine. GCN в своїй основі орієнтована на обчислення GP-GPU в не меншому ступені, ніж на рендеринг графіки, і влаштована таким чином, що добра частина завдання насичення GPU паралелізмом вирішується на рівні «заліза», а не драйвера або програми. Навіть самі ранні чіпи GCN забезпечують одночасне виконання декількох черг «обчислювальних» команд одночасно з чергою рендеринга графіки за рахунок командних процесорів двох типів - GCP (Graphics Command Processor) і ACE (Advanced Compute Engine). А починаючи з третього покоління архітектури (чіпи Tonga і Fiji ), GCN також включає роздільні планувальники для шейдерних і «обчислювальних» інструкцій. В результаті процесор може динамічно передавати обчислювальні ресурси окремих CU (Compute Unit - блок, що містить 64 ALU) між декількома чергами інструкцій.

Крім того, GCN допускає порівняно безболісну зміну контексту CU. Зміна контексту в даному випадку означає, що CU, що знаходиться в очікуванні даних від тривалої операції, якою займаються інші блоки GPU, отримує від командного процесора іншу роботу, зберігши вміст своїх регістрів в будь-якому зовнішньому сховищі. У GCN цим сховищем є високошвидкісний інтегрований кеш, і процесор може користуватися зміною контексту досить вільно.

Таким чином, керуюча логіка GCN здатна ефективно завантажувати виконавчі блоки GPU за рахунок інструкцій з окремих черг, заповнюючи навіть порівняно невеликі «бульбашки» конвеєра. Підсумковий приріст швидкодії залежить від того, наскільки часто «бульбашки» виникають в режимі однієї черги. Але ж правда, графічні процесори AMD істотно недовантажені в більшості ігор в порівнянні з чіпами NVIDIA, і з кожним новим поколінням ситуація погіршується. Досить поглянути на Radeon RX Vega 64, яка в задачах GP-GPU щонайменше не поступається GeForce GTX 1080 Ti , Але в іграх ледь справляється з GeForce GTX 1080 . GCN - «широка» архітектура, яка потребує високого паралелізму для повного навантаження. Тому так, можливості Multi-Engine, які відкривають сучасні API, можуть стати у нагоді для AMD - з великим застереженням про те, що розробники ігор почнуть їх активно використовувати.

Multi-Engine на GPU різної архітектури: NVIDIA Kepler, Maxwell і Pascal

Ситуація з підтримкою Multi-Engine в графічних процесорах NVIDIA далеко не настільки прозора, як у випадку з AMD. Матеріали NVIDIA, що знаходяться в широкому доступі, не дають чіткої відповіді на всі питання. З повною упевненістю можна говорити лише про те, яким саме з GPU архітектур Kepler, Maxwell і Pascal взагалі дозволено мати справу із змішаною навантаженням (графіка / обчислення) під керуванням Direct3D 12 і Vulkan. А наше уявлення про те, чому це так, а не інакше, засноване здебільшого на сторонніх джерелах і не претендує на істину в останній інстанції. Що вдієш, така політика цієї компанії, особливо коли мова йде про недоліки їх продуктів.

На відміну від AMD, NVIDIA вирішила розділити свої GPU на переважно споживчі або професійні моделі, починаючи з архітектури Kepler. Перші спочатку позбавлені маси обчислювальних функцій, непотрібних в ігрових завданнях (таких як швидке виконання розрахунків подвійної точності). Крім того, на шляху від архітектури Fermi (GeForce 400/500) до Kepler, а потім Maxwell розробники послідовно скорочували керуючу логіку GPU, переклавши частину функцій на драйвер.

Проте підтримка змішаної навантаження навіть в масових чіпах NVIDIA значно розширилася з часів Kepler. «Дрібні» чіпи архітектури Kepler (GK10X, GeForce GTX 680 і нижче, а також GeForce GTX 770) здатні працювати з єдиною чергою команд, будь то графіка або чисто обчислювальна задача (ні про яке Multi-Engine мови не йде). У «великому» Кеплере (GK110 / 210, GeForce GTX 780 / 780 Ti і GeForce GTX TITAN ) І чіпах Maxwell першого покоління (GK107, GeForce GTX 750 / 750 Ti ) Впровадили окремий блок для прийому «обчислювальних» черг Hyper-Q, але окрема «обчислювальна» навантаження одночасно з графікою можлива тільки під пропрієтарним API CUDA. Крім того, «обчислювальна» чергу може задіяти один і тільки один з 32 слотів блоку CWD (CUDA Work Distributor), що розподіляє ланцюжка операцій між окремими SM.

Динамічний Розподіл потужного между графічної и «обчіслювальної» Черга з'явилося только в Maxwell іншого поколение (серія GeForce 900), но існує критично важліве обмеження: перерозподіл відбувається лишь на кордоні draw call, а значить, драйверу нужно віділіті необхідну для тієї чи Іншої задачі групу SM (Streaming Multiprocessor, блок, в Який організовані CUDA-ядра) заздалегідь. Звідсі вінікають помилки планування, Які Неможливо усунуті на льоту, и даже при ідеальному прогнозі еврістікі драйвера Maxwell буде пропускаті дрібні «бульбашки» конвеєра. Крім того, Maxwell несе важкі втрати від зміни контексту, т. К. Проміжні результати обчислень зберігаються в (володіє порівняно високою латентністю) оперативної пам'яті, при цьому відбувається повне очищення кеша L1 і розділяється пам'яті GPU. В таких умовах швидкодії не так сильно шкодить досить короткий простий окремих SM, як зміна контексту.

Схоже, саме ці архітектурні обмеження спонукали NVIDIA заблокувати Multi-Engine драйвера для Kepler і Maxwell. Додаток може створити скільки завгодно «обчислювальних» черг, але драйвер все одно об'єднає їх з графічної чергою. Як і раніше єдина лазівка ​​для розробників - це використовувати CUDA, хоча на ситуацію з розподілом ресурсів і зміну контексту API ніяк не впливає.

Серед «зелених» GPU тільки сімейство Pascal допущено до функції Multi-Engine в Direct3D 12 і Vulkan, бо Pascal, на відміну від Maxwell, вміє передавати ресурси SM між чергами графіки і «обчислень» динамічно, не чекаючи завершення draw call. При цьому ціна зміни контексту залишилася високою (аж до 0,1 мс або 170 тис. Циклів GPU в разі GeForce GTX 1070 / 1080!), А значить, Pascal і раніше обмежений в гнучкості при роботі з декількома чергами команд в порівнянні з GCN.

В результаті NVIDIA досить сильно ускладнила життя розробникам додатків, які бажають використовувати Multi-Engine. GCN невибаглива і передбачувана в плані змішаної навантаження, але прискорювачі Radeon на ринку в меншості. З іншого боку, відеокарти з графічними процесорами NVIDIA стоять в безлічі ігрових ПК і до того ж належать до кільком поколінням з різним рівнем підтримки Multi-Engine і методами його використання. Але, на щастя для NVIDIA, її продукти і без того не відчувають нестачі в швидкодії. Чіпи Maxwell і Pascal в порівнянні з процесорами GCN відповідного класу мають більш «вузьку» архітектуру з меншим числом шейдерних ALU, а значить - не вимагають настільки ж високого паралелізму для повного завантаження.

Если Ви помітілі помилки - віділіть необхідній текст и натісніть CTRL + ENTER.