Vulkan проти DirectX: чи наближається нова війна API?

Що означає «війна API» у 2026 році (і чому це інше)

Якщо ви жили в старі часи, історія «війни API» була проста: постачальник A прив’язує вас до платформи, постачальник B пропонує стандарт, розробники займають боки, форуми палають. Зараз це не те, що відбувається. Сучасний конфлікт більш приземлений і дорожчий: війна йде за операційні результати.

DirectX 12 (і його екосистема на Windows/Xbox) переважає там, де пріоритет — «випустити великий Windows-проєкт з передбачуваними інструментами й одним постачальником ОС, на якого можна нарікати». Vulkan переважає там, де пріоритет — «випустити на Windows/Linux/Android/схожих на SteamOS середовищах і тримати опції відкритими». Але обидва — явні API, і явні API — це як дати підліткам ключі від дому. Вони швидко навчаться відповідальності, але ваші стіни все одно будуть подряпані.

Справжній конфлікт стосується цих питань:

• Хто відповідає за портативність? Ви, постачальник middleware чи платформа?
• Хто відповідає за коректність? Драйвер (як у старих API) чи ваш движок (як у явних API)?
• Хто відповідає за стутер? Ваш пайплайн шейдерів, пайплайн активів чи історія рантаймової компіляції?
• Хто відповідає за досвід відладки? Ваші інженери за столами — чи SRE у полі, який проводить археологію за знятим трейсом?

«Нова війна API» станеться лише якщо ви визначаєте «війну» як перерозподіл бюджетів у бік стеку, який зменшує кількість інцидентів. Команди втомилися сперечатися про теоретичну пропускну здатність. Вони хочуть менше регресій після оновлень драйверів, менше багів, що «трапляються тільки на цьому ноутбуці», і менше чорних скриньок.

Історичний контекст: 9 фактів, які досі важливі

Люди люблять вдавати, що минуле не має значення у графіці. Це не так. Минуле — причина того, чому ваш сучасний трекер багів виглядає як збірка фольклору.

1. Vulkan виріс із Mantle від AMD. Mantle довів, що явний контроль може працювати для ігор, і індустрія одразу стандартизувала цю ідею.
2. DirectX — це не «просто API», це контракт екосистеми. Він включає інструменти, інтеграцію з ОС і модель драйверів, сформовану пріоритетами Microsoft.
3. DX12 і Vulkan замінили драйверну магію відповідальністю застосунку. Старий компроміс — драйвери, що роблять неявне відстеження небезпек і керування пам’яттю — не був безкоштовним; це була прихована вартість і непередбачуваність.
4. Довгий хвіст OpenGL досі впливає на продакшн-рішення. Не тому, що він сучасний, а тому, що «він працює всюди» був дефолтною ментальною моделлю роками.
5. Модель багатопоточного драйвера D3D11 задала очікування, за які команди досі чіпляються. Багато студій навчились покладатися на те, що драйвери згладжують погану синхронізацію. DX12/Vulkan цього не роблять.
6. SPIR-V стандартизував проміжне представлення шейдерів, але не досвід зі шейдерами. Шейдерний пайплайн Vulkan портативний у теорії; стутер та стратегія компіляції залишаються локальними.
7. Консольні API формували очікування на ПК. Сучасні рушії будуються навколо явного мислення про ресурси та бар’єри, бо консолі раніше задали цю дисципліну.
8. «Паритет функцій» ніколи не був справжнім диференціатором. Відмінності — в шарах відладки, інструментах захоплення, розмірі матриці QA і якості драйверів на вашому цільовому парку машин.
9. Шари трансляції тепер мейнстрім. Це не провал; це бізнес-результат. Але це зміщує моди відмов у нові місця: кешування PSO, відображення синхронізації та граничні поведінки драйверів.

Хто обирає Vulkan чи DirectX — і чому

DirectX 12: модель «один орендодавець»

Якщо Windows (і Xbox) — ваш основний джерело доходу, DX12 привабливий тим, що власник платформи дуже переймається досвідом — іноді це збігається з вашими інтересами, іноді — тому що вони не хочуть, щоб ви йшли. Це вирівнювання все ще має цінність. Інструменти для відладки, норми розповсюдження драйверів та загальна очікувана «історія графіки за ОС» створюють спокійніше операційне середовище.

Дизайн DX12 тісно переплетений із WDDM і світоглядом Microsoft щодо планування, бюджетування пам’яті і безпеки. Це може бути плюсом: менше «загадкових стеків», більш послідовна поведінка на машинах коли все оновлено. Може бути й мінусом: більше рухомих частин, прив’язаних до циклів релізів ОС і політик.

Vulkan: модель «принось свою витривалість»

Vulkan привабливий, коли потрібно випускати на кількох ОС, і різноманітність апаратури — не побічна задача, а основний сюжет. Він також привабливий, якщо ви хочете уникнути стратегічної залежності від дорожньої карти одного постачальника.

Компроміс: Vulkan робить менше обіцянок про «просто працює» і більше обіцянок про «ось примітиви». Вам доведеться побудувати більше інфраструктури — валідацію в CI, розбір аварій за дампами GPU, кеші пайплайнів, надійні механізми включення/виключення функцій. Vulkan винагороджує команди, які мислять як SRE: вимірювати, ізолювати, автоматизувати і завжди припускати частковий збій.

Отже, чи наближається нова війна?

Не в старому розумінні. Сучасний конфлікт буде тихішим: рушії випускатимуть декілька бекендів; команди використовуватимуть шари портативності; постачальники змагатимуться інструментами та стабільністю драйверів; а ваш CTO назве це «стратегічною гнучкістю», тоді як графічний лід — «подвійною роботою».

Явні API: рахунок приходить

Vulkan та DX12 — явні. Це означає, що ви керуєте синхронізацією, пам’яттю та пайплайнами з більш прямим контролем. Це також означає, що ви зможете влучити собі в ногу з професійною точністю.

Найбільше непорозуміння — це те, що «явний» означає «швидший». Явний означає передбачуваний після того, як ви заплатите інженерний податок. Якщо ви цього не зробите, отримаєте непередбачуваність — але тепер це ваш баг, а не драйвера.

Звідки насправді береться біль у продакшені

• Створення пайплайнів і компіляція шейдерів: підгальмовування, стутер, шторми PSO.
• Помилки синхронізації: пошкоджені кадри, мерехтіння, device lost, недетерміновані баги, що зникають під інструментами захоплення.
• Бюджетування пам’яті: «працює на 16 ГБ GPU» — це не стратегія, це зізнання.
• Різниці в драйверах: однакове коректне використання API може радикально по-різному працювати на різних постачальників.
• Вибух матриці QA: сила Vulkan (портативність) — це також ваша тестова ноша, якщо ви її не обмежите.

Парафразована ідея, яка часто повторюється в SRE-кругах роками: Надійність походить з проєктування під те, як системи фактично відмовляють, а не як ми сподіваємось, що вони поводитимуться.
Це мислення потрібно для будь-якого API. Особливо для Vulkan.

Реалії інструментів: що ви справді можете дебагувати

Вибір API — це також вибір досвіду відладки. Коли щось іде не так, вам швидко потрібні відповіді: що застрягло, що скомпільовано, що вивантажено, що евакуйовано, якого бар’єра не вистачало.

DX12: більш інтегровані запобіжні засоби

На Windows DX12 виграє від цілісного стеку платформи: послідовне трасування подій, шари відладки, які багато команд стандартизують, і «відомий» набір інструментів у екосистемі графіки Windows. На практиці це скорочує час до першого сигналу при діагностиці проблем на типових споживчих конфігураціях.

Vulkan: більше видимості — більше відповідальності

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

Якість інструментів Vulkan залежить від платформи. На Linux вона може бути відмінною, якщо ви знаєте, що робите, але «знати, що робиш» має стати частиною вашої операційної моделі. Це не образа; це робота.

Жарт №1: Відлагодження зависання GPU — як відлагодження розподіленої системи, тільки журнали переважно — інтерпретативний танець.

Шейдери, PSO, пайплайни: де народжується стутер

Якщо ви хочете передбачити проблеми з продуктивністю, не починайте з трикутників. Почніть із компіляції й створення стану. І Vulkan, і DX12 змушують вас виконувати роботу наперед (створення пайплайнів, PSO) або платити за це в рантаймі стутером, який гравці опишуть як «випадкова затримка».

DX12 PSO: детермінований, якщо серйозно ставитися до кешування

Pipeline State Object у DX12 важкі, і це зроблено навмисно. Ви можете зробити їх дешевими в рантаймі, побудувавши наперед, серіалізувавши кеші і ніколи не створюючи їх на гарячому шляху. Але команди все одно цього не роблять. Зазвичай тому, що геймплей-інженер додав «ще один матеріал», і рендерер ввічливо скомпілював нову комбінацію під час бою з босом.

Vulkan пайплайни: та сама історія, менше виправдань

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

Справжній урок з продакшену

Ви не можете «оптимізувати» стутер від компіляції шейдерів однією хитрістю. Потрібно спроєктувати пайплайн: запікання активів, контроль комбінацій, каталоги PSO/пайплайнів, збереження кешів і рантаймове прогрівання, прив’язане до контенту. Це не графічна магія. Це операційна робота.

Шари портативності: спасіння чи повільний збій?

Сучасна реальність: багато команд не обирають лише Vulkan або DX12. Вони беруть абстракцію — бекенд рушія або шар портативності — і відправляють той API, який підходить для платформи.

Це може бути блискучим. Також це може стати повільним збоєм, якщо ви ставитесь до шару як до «проблеми когось іншого». Слoї трансляції зміщують складність:

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

Практичний висновок: якщо ви використовуєте шар портативності, закладіть інженерний час на «спостережуваність шару» та «вихідні шлюзи» для платформи-специфічних фіксів. Інакше ви врешті-решт опинитесь заблокованими багом, якому не зможете впевнено приписати відповідальність.

Три корпоративні міні-історії з польових боїв

Міні-історія 1: Інцидент через хибне припущення

Середня студія випустила патч, який викликав періодичні помилки device-lost на підмножині Windows-машин. Звіти про аварії були шумними: на деяких GPU все ок, на деяких — ні, і спроби відтворити поводилися як сором’язливий кіт — відтворювались тільки коли ніхто не дивився.

Хибне припущення було тонким: команда припустила, що перехід ресурсу, який «завжди працював» у їхньому старому бекенді, буде неявно оброблятися так само в новому явному бекенді. Їхня внутрішня абстракція відкривала «використовувати текстуру для семплінгу» і «використовувати текстуру як рендер-таргет», не вимагаючи реальної декларації бар’єра в місці виклику.

В тестуванні драйвер часто покривав це. В полі відмова траплялася під тиском пам’яті і при активному асинхронному завантаженні, коли порядок командних буферів змінювався. Баг виявився як випадкове пошкодження, а потім ескалація до видалення пристрою.

Виправлення було нудним: вони зробили переходи явними в інтерфейсі рушія, примусили валідацію в дебаг-білдах і додали «лінтер небезпек», який відкидав неоднозначні шаблони використання в CI. Інцидент завершився не тому, що вони знайшли магічне обхідне рішення, а тому, що припинили вважати драйвер своїм співавтором.

Міні-історія 2: Оптимізація, яка відгукнулась боком

Інша команда вирішила зменшити навантаження CPU, агресивно повторно використовуючи командні буфери і пропускаючи те, що вони називали «надлишковими» оновленнями дескрипторів. Вони проганяли бенчмарки на одній високопродуктивній системі і отримали помітний приріст. Хтось оголосив перемогу.

Через два тижні QA почав помічати рідкісні мерехтіння і «неправильні текстури», які з’являлися тільки після тривалих сесій гри. Ще гірше: зняті під час бага каптури часто виглядали правильно, бо інструменти захоплення змінювали таймінги й життєві цикли ресурсів настільки, щоб приховати проблему.

Корінь проблеми — порушення правил життєвого циклу в масштабі: дані дескрипторів повторно використовувалися після того, як виділення під них були перерозподілені аллокатором під тиском. Зазвичай це було безпечно, бо старий вміст пам’яті лишався незмінним — поки не став іншим.

Рішення — відкрутити «оптимізацію», ввести явну систему версіонування для дескрипторних алокацій і розглядати повторне використання дескрипторів як фічу з інваріантами й тестами, а не як хитрість. Пізніше приріст продуктивності повернувся через безпечніше батчування й кращі рішення щодо макетів пайплайнів. Перший підхід був просто боргом із секундоміром.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

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

Це не було гламурною роботою. Це була інфраструктура: автоматична інсталяція драйверів, знімки ОС, повторюване відтворення сцен і стандартизований збір трас. Команда також впровадила суворий контроль фіч: якщо розширення або фіча не входила до «підтримуваної бази», вона не розгорталась без шляхів відкату.

Перед релізом оновлення драйвера одного вендора спричинило регресію в поведінці кешу пайплайнів. Багато команд дізналися б про це по злостивих відгуках. Ця команда дізналася про це в нічному прогоні: гістограма показала довгий хвіст піків кадру в одній сцені.

Вони випустили продукт із таргетованою мірою: детектувати версію драйвера, коригувати стратегію прогрівання пайплайнів і зменшувати створення пайплайнів у рантаймі. Ніякого драматизму, жодних соціальних мереж про пожежу, жодних екстрених патчів. Практика, яка їх врятувала, не була геніальною. Вона була поверненням і доказами.

Практичні завдання: команди, виходи та рішення (12+)

Це ті перевірки, які можна виконати на дев-ригках, CI-машинах або боксах для діагностики підтримки. Суть не в команді як такій — суть у дисципліні: отримати сигнал, інтерпретувати його, прийняти рішення.

Task 1: Confirm GPU(s) and driver in the field (Linux)

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU106 [GeForce RTX 2060] [10de:1f08] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] TU106 [GeForce RTX 2060] [1462:3756]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: Ідентифікуйте реальний GPU і ядровий драйвер, який використовується. Якщо ви бачите nouveau, коли чекали nvidia, ваша продуктивність і поведінка Vulkan буде кардинально іншою.
Рішення: Якщо завантажений неправильний драйвер, виправте драйвери перед тим, як ганятися за багами на рівні API.

Task 2: Check Vulkan loader + ICD visibility

cr0x@server:~$ vulkaninfo --summary
Vulkan Instance Version: 1.3.275

Instance Extensions: count = 23
...
Devices:
========
GPU0:
	apiVersion         = 1.3.275
	driverVersion      = 550.54.14
	vendorID           = 0x10de
	deviceName         = NVIDIA GeForce RTX 2060

Що це означає: Завантажувач Vulkan бачить пристрій і повідомляє версії драйвера/API.
Рішення: Якщо vulkaninfo не показує пристроїв або показує несподіваний software ICD, виправте інсталяцію/ICD JSON перед тим, як звинувачувати рендерер.

Task 3: Spot accidental software rendering (Mesa llvmpipe)

cr0x@server:~$ vulkaninfo --summary | grep -E "deviceName|driverName"
	driverName         = llvmpipe
	deviceName         = llvmpipe (LLVM 17.0.6, 256 bits)

Що це означає: Ви запускаєте Vulkan на CPU. Це не «трохи повільніше», це «ваш GPU у відпустці».
Рішення: Вважайте будь-який звіт про продуктивність із цієї машини невалідним для GPU-робіт; виправте драйвери/вибір ICD.

Task 4: Inspect GPU resets / hangs via kernel logs

cr0x@server:~$ sudo dmesg -T | tail -n 20
[Mon Jan 20 10:14:03 2026] NVRM: Xid (PCI:0000:01:00): 31, pid=21452, name=game, Ch 00000028
[Mon Jan 20 10:14:03 2026] nvidia-modeset: ERROR: GPU:0: Idling display engine timed out

Що це означає: Ядровий драйвер зафіксував послідовність помилки/скидання GPU.
Рішення: Пріоритезуйте стабільність: зменшіть розгін, протестуйте відомі робочі версії драйверів і дослідіть синхронізацію/пошкодження пам’яті в вашому додатку.

Task 5: Check CPU throttling that masquerades as “GPU API overhead”

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Що це означає: CPU може бути заблокований у консервативному режимі частоти.
Рішення: Якщо профілюєте шляхи сабміту CPU, переключіть на performance governor для порівнюваних результатів; не порівнюйте Vulkan і DX12 на тротлінгованих CPU.

Task 6: Verify GPU utilization and clocks (NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,utilization.gpu,clocks.sm,clocks.mem,pstate --format=csv
name, driver_version, utilization.gpu [%], clocks.sm [MHz], clocks.mem [MHz], pstate
NVIDIA GeForce RTX 2060, 550.54.14, 42 %, 885 MHz, 405 MHz, P5

Що це означає: Завантаження помірне, такти низькі, енергетичний стан не максимальний.
Рішення: Якщо ви очікуєте GPU-завантажене навантаження, але бачите низькі такти/завантаження, підозрівайте вузьке місце на CPU, VSync-кап, лімітер кадрів або очікування на компіляцію шейдерів.

Task 7: Identify “GPU is waiting on CPU” via frame pacing metrics (generic)

cr0x@server:~$ cat /proc/loadavg
6.41 5.88 5.20 9/1324 21452

Що це означає: Система зайнята; load високе.
Рішення: Якщо часи кадрів стрибають при високому loadavg і низькому завантаженні GPU, профілюйте CPU: контенція потоків сабміту, стрімінг активів або компіляція PSO.

Task 8: Check memory pressure that triggers paging/evictions

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       1.1Gi       412Mi       2.0Gi       1.6Gi
Swap:          8.0Gi       2.7Gi       5.3Gi

Що це означає: Системна пам’ять напружена і використовується swap.
Рішення: Сумнівайтеся в звітах про стутер, доки не протестуєте з достатнім обсягом RAM; тиск пам’яті може спричинити каскад: пропуски кешу шейдерів і IO-стали.

Task 9: Spot IO stalls affecting shader cache / asset streaming

cr0x@server:~$ iostat -xz 1 3
Linux 6.6.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          28.51    0.00    6.20   18.77    0.00   46.52

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         312.0  18240.0     12.0   3.70    8.21    58.5   110.0   9216.0    15.44   2.10   96.8

Що це означає: Високий IO wait і майже насичений диск. Якщо кеші шейдерів або стрімінг активів звертаються до диска, будуть стрибки часу кадру.
Рішення: Перемістіть кеші на швидше сховище, зменшіть рантаймову компіляцію або прогрійте заздалегідь. Не сперечайтеся про Vulkan vs DX12, поки ваш NVMe завантажений.

Task 10: Confirm shader cache directory growth / thrash

cr0x@server:~$ du -sh ~/.cache
9.4G	/home/cr0x/.cache

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

Task 11: Check open file limits (surprisingly relevant for asset-heavy titles)

cr0x@server:~$ ulimit -n
1024

Що це означає: Низький ліміт дескрипторів файлів може спричиняти затримки стрімінгу активів або помилки, які виявляються як «зависання рендеру».
Рішення: Підніміть ліміти для тестових ригів і продакшн-лаунчерів; якщо бачите спорадичні IO-помилки, перевірте це перед переписуванням рендерера.

Task 12: Validate process memory usage while reproducing stutter

cr0x@server:~$ ps -o pid,cmd,rss,vsz,etime -p 21452
  PID CMD                           RSS    VSZ     ELAPSED
21452 ./game --renderer=vulkan   8421560 21188608   01:12:44

Що це означає: RSS ~8 GB; VSZ значно більший. Слідкуйте за неконтрольованими алокаціями, особливо кеші дескрипторів/пайплайнів і staging-буфери.
Рішення: Якщо пам’ять росте з часом гри і стутер погіршується, підозрюйте витоки або необмежені кеші, а не API.

Task 13: Detect compositor / window system interference (Linux desktop)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Що це означає: Сесія Wayland. Поведінка презентації і кадрування може відрізнятися від X11 залежно від композитора і драйверів.
Рішення: Для послідовних тестів продуктивності стандартизуйте середовище тестування (тип сесії, налаштування композитора, VRR, VSync).

Task 14: Quick sanity check of Vulkan validation layer availability

cr0x@server:~$ vulkaninfo | grep -A2 "VK_LAYER_KHRONOS_validation"
VK_LAYER_KHRONOS_validation (Khronos Validation Layer) Vulkan version 1.3.275, layer version 1:
    Layer Extensions: count = 3

Що це означає: Валідація встановлена і доступна для виявлення.
Рішення: Якщо ви не можете ввімкнути валідацію в dev/QA, ви свідомо обираєте відлагодження з меншим набором фактів. Виправте це перш за все.

Швидкий план діагностики

Коли команда каже «Vulkan повільніший за DX12» або «DX12 стутерує», ставтеся до цього як до інцидент-репорту, а не до думки. Ваша мета — ізолювати, який підсистем сьогодні є вузьким місцем на цій машині з цим драйвером.

Перше: класифікуйте біль (кадрове планування vs пропускна здатність)

• Якщо середній FPS низький: ви женетеся за пропускною здатністю.
• Якщо FPS в нормі, але відчуття погане: ви женетеся за кадруванням (стрибки, довгий хвіст).
• Якщо відбувається крах/device-lost: ви женетеся за коректністю та стабільністю; продуктивність другорядна.

Друге: визначте CPU-bound чи GPU-bound

• Перевірте завантаження GPU і такти під час проблемної сцени.
• Перевірте навантаження CPU, насичення ядер і симптоми контенції потоків.
• Тимчасово змініть роздільну здатність або масштаб рендеру:
  • Якщо продуктивність майже не змінюється — ймовірно CPU-bound або затримки на компіляції/IO.
  • Якщо продуктивність змінюється суттєво — ймовірно GPU-bound.

Третє: протестуйте «звичних підозрюваних» стутера

• Компіляція шейдерів/PSO: піки корелюють з новими матеріалами, новими районами, ефектами, що запускаються вперше.
• IO-стали: піки корелюють з подіями стрімінгу; disk utilization та iowait піднімаються.
• Тиск пам’яті: піки погіршуються з часом; свап або overcommit GPU-пам’яті.
• Синхронізація: бульбашки GPU; нестабільні піки; device lost на певних вендорах.

Четверте: перевірте припущення контрольованими перемикачами

• Вимкніть асинхронну компіляцію або перемістіть її на виділений потік, щоб побачити, чи зміщуються піки.
• Примусьте зменшений набір шейдерних пермутацій, щоб перевірити, чи зник довгий хвіст.
• Запустіть з валідацією (Vulkan) або debug-слоєм (DX12) у відтворюваній сцені, щоб ловити помилки небезпек раніше.
• Спробуйте відому робочу версію драйвера. Бісекція драйверів непоказна, але ефективна.

П’яте: приймайте рішення на підставі доказів, а не ідеології

Якщо Vulkan повільніший на одного вендора через проблеми драйвера і ви не можете пом’якшити це — можливо, ви випустите DX12 на цій платформі. Якщо DX12 блокує випуск на Linux/Android — можливо, ви випустите Vulkan і інвестуєте в інфраструктуру сумісності. «Кращий API» — той, що відповідає вашим операційним обмеженням.

Поширені помилки: симптом → корінна причина → виправлення

1) Симптом: випадкові піки часу кадру при вході в нові райони

Корінь: рантайм-створення пайплайнів/PSO і компіляція шейдерів у рендер-потоці.

Виправлення: побудуйте каталог PSO/пайплайнів, прогрівайте на екранах завантаження, зберігайте кеші пайплайнів і обмежте зростання пермутацій.

2) Симптом: «Vulkan повільніший за DX12» лише на ноутбуках

Корінь: запуск на інтегрованому GPU або шлях презентації гібридного GPU, що викликає додаткові копії/композитинг.

Виправлення: упевніться в правильному виборі GPU, зробіть UI для вибору адаптера і перевіряйте через vulkaninfo deviceName / вибір адаптера DXGI.

3) Симптом: device lost / скидання GPU під сильним навантаженням

Корінь: помилка синхронізації, вихід за межі в шейдерах або пошкодження пам’яті через помилки життєвих циклів.

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

4) Симптом: чудові бенчмарки, жахливе кадрування

Корінь: фокус на середньому FPS при ігноруванні довгого хвоста (компіляція, IO, аллокаторні чірни).

Виправлення: вимірюйте перцентилі (p95/p99 часу кадру), відстежуйте піки по сценах і включайте бюджет стутера в критерії прийнятності.

5) Симптом: випадкові неправильні текстури або мерехтіння після довгих сесій

Корінь: повторне використання дескрипторів / перерозподіл алокацій без коректного відстеження життєвого циклу.

Виправлення: додайте версіоновані алокації, суворіші моделі власності і дебаг-посилення (poisoning) для виявлення use-after-free.

6) Симптом: «працює в інструменті захоплення, не працює без нього»

Корінь: race condition і таймінг-чутливі небезпеки; інструменти захоплення серіалізують і змінюють планування.

Виправлення: побудуйте детерміновані сцени для відтворення, додайте GPU-підтримувану валідацію де можливо і внутрішні бар’єри/твердження життєвого циклу.

7) Симптом: регрес продуктивності після оновлення драйвера

Корінь: інвалідизація кешу пайплайнів, різні евристики компілятора шейдерів або змінене планування.

Виправлення: майте лабораторію сумісності драйверів, детектуйте версії драйверів у рантаймі і випускайте міри пом’якшення (зміна прогрівання, перемикачі, шляхи відкату).

8) Симптом: сабміт-потік CPU на 100%, GPU недовантажений

Корінь: надто багато дрібних малюнків, зайві зміни стану, часте перезбирадання командних буферів або контенція замків у рендері.

Виправлення: батчіть малюнки, використовуйте indirect rendering де доречно, зменшуйте накладні витрати на виклик і профілюйте замки; явні API не виправдовують балакучі сабміти.

Чек-листи / покроковий план

Чек-лист A: Вибір Vulkan чи DX12 для нового проєкту

1. Запишіть платформи й вагу доходів по них. Якщо важливі Linux/Android/пристрої на кшталт Steam Deck — Vulkan за замовчуванням.
2. Визначте підхід до портативності. Нативні бекенди проти шару портативності. Закладіть бюджет відповідно.
3. Визначте базовий апаратний та драйверний поліси. Матриця підтримуваних вендорів/драйверів і дії при невідповідності.
4. Підтвердіть валідацію в CI. Якщо ви не будете запускати валідаційні/дебаг-шари, ви обираєте повільніший час реакції на інциденти.
5. Сплануйте стратегію шейдерів/PSO до початку виробництва контенту. Пермутації тихо зростають, поки не вибухнуть голосно.
6. Зробіть кадрування критерієм прийняття. Відстежуйте p95/p99 часу кадру, а не лише середнє.
7. Визначте, хто відповідає за процес «зависання GPU». Інженери? Підтримка? SRE? Хтось має володіти playbook.

Чек-лист B: Випуск двобекендного рендерера без подвоєння відмов

1. Утримуйте паритет фіч навмисно неповним. Паритет дорогий; узгодженість дешевша. Виберіть «треба збігатися» і «можуть відрізнятися» фічі.
2. Стандартизуйте джерело шейдерів і логіку пермутацій. Один набір правил — кілька виходів.
3. Уніфікуйте моделювання життєвого циклу ресурсів і бар’єрів. Якщо ваша абстракція течить тут — вона потече кров’ю пізніше.
4. Реалізуйте бекенд-специфічні «вихідні шлюзи». Іноді треба використати розширення або вендорський хак. Зробіть це явним і аудиторованим.
5. Побудуйте пайплайн трасування і розбору. Захоплення, логи, ID збірок, версії драйверів — автоматично додавайте їх до звітів про баги.

Чек-лист C: План зменшення стутера (практичний порядок)

1. Інструментуйте час та кількість створень шейдерів/PSO по сцені.
2. Перенесіть компіляцію з рендер-потоку; прогрівайте в безпечні моменти.
3. Зберігайте кеші пайплайнів; додавайте версіонування і обробку інвалідизації.
4. Зменшіть пермутації (обмеження системи матеріалів, консолідація ефектів).
5. Аудит IO: місце кешів, стратегія стиснення, асинхронне планування читань.
6. Аудит пам’яті: обмежуйте кеші, виправляйте витоки, впроваджуйте бюджети по рівнях.
7. Перепроіть з метриками перцентилів і сценаріями «першого запуску».

Жарт №2: «Війна API» — це коли дві команди тижнями сперечаються, а потім виявляється, що справжній торт — це mutex з назвою RenderQueueLock.

Часті питання

1) Чи завжди Vulkan швидший за DirectX 12?

Ні. Обидва можуть бути надзвичайно швидкими. Переможець залежить від драйверів, архітектури вашого рушія і робочого навантаження (великі виклики малювання, інтенсивний compute, інтенсивний стрімінг тощо). Чим явніший ви — тим більше продуктивність стає «вашою відповідальністю».

2) Чи безпечніший DirectX 12, бо «від Microsoft»?

Він безпечніший у сенсі, що інструменти Windows і інтеграція екосистеми можуть скоротити час відладки. Але коректність все одно на вас. DX12 не врятує вас від пропущених бар’єрів або помилок життєвих циклів.

3) Якщо ми оберемо Vulkan, чи мусимо ми підтримувати Linux?

Ні, але стратегічна цінність Vulkan зростає, коли ви націлені на кілька платформ. Якщо ви лише на Windows і не плануєте змінюватися, DX12 — розумний дефолт, особливо якщо команда вже в ньому флуентна.

4) Чи «обман» використовувати шари трансляції?

Ні. Це бізнес-інструмент. Але вони зміщують проблеми: поведінка кешу, відображення синхронізації і складність відладки. Ставтесь до шару як до продакшен-коду, який треба спостерігати, тестувати і час від часу патчити.

5) Яка #1 причина стутера в сучасних явних API?

Рантайм-компіляція шейдерів/створення пайплайнів. Не завжди, але достатньо часто, щоб ви мали припускати це, поки не доведете інше. Побудуйте стратегію пайплайнів/PSO рано, до закріплення контенту в поганих звичках.

6) Яка #1 причина «випадкових зависань GPU», що трапляються лише у деяких користувачів?

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

7) Чи має інді-команда обрати Vulkan?

Лише якщо портативність — реальна вимога або ви використовуєте рушій/бекенд, що робить Vulkan операційно простим. Якщо команда мала і ціль — Windows, DX12 (або зрілий рівень абстракції рушія) часто зменшує час на інфраструктуру.

8) Чи «зробить Vulkan нас готовими до майбутнього»?

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

9) Що треба вимірювати, щоб вирішити справедливо?

Вимірюйте перцентилі часу кадру (p95/p99), кількість і час створення шейдерів/PSO, час сабміту CPU, завантаження GPU/такти, тиск пам’яті і iowait. Середній FPS — це джерело поганих рішень.

10) Чи можна уникнути вибору, використавши абстракцію рушія?

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

Висновок: що робити далі (без святої війни)

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

Якщо ви створюєте або підтримуєте рендерер, зробіть наступне:

1. Операціоналізуйте валідацію. Зробіть її типом збірки, а не ритуалом.
2. Побудуйте стратегію шейдерів/PSO. Каталогізуйте, прогрівайте, кешуйте і бюджетуйте пермутації.
3. Створіть матрицю тестування драйверів/ОС, що відповідає реальності. Невелика, але добре підібрана лабораторія краща за героїчні відладки в останню хвилину.
4. Ухопіться за швидкий план діагностики. Класифікуйте біль, ізолюйте вузьке місце, перевіряйте підозрюваних і приймайте рішення.
5. Оберіть API на підставі ваших умов випуску. Не на підставі ідеології, форумних консенсусів або одного знімка бенчмарку.

Vulkan і DirectX 12 обидва потужні. Жоден не поблажливий. Оберіть той, що відповідає вашій операційній моделі — і інвестуйте в нього по-справжньому.