Vulkan: люблять за швидкість, ненавидять за складність

Чому існує Vulkan (і чому це боляче)

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

Vulkan перевертає це. Додаток каже GPU точно, чого він хоче і коли, використовуючи явну синхронізацію та явне
керування ресурсами. Драйвер перестає вгадувати і стає тонким шаром перекладу. Такий зсув
відкриває продуктивність — особливо в CPU-зв’язаних рендерах — і робить поведінку більш детермінованою. Він також значно спрощує
можливість сильно помилитися.

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

Цікаві факти й історичний контекст (коротко, конкретно)

• Vulkan походить від AMD Mantle. Mantle довів, що «тонкий API, явний контроль» може зменшити накладні витрати на CPU; Vulkan узагальнив цю ідею.
• Керує ним Khronos Group. Та ж консорціум, що OpenGL, OpenCL та кілька медіастандартів — тобто багато зацікавлених сторін і обережна еволюція.
• Vulkan 1.0 вийшов у 2016 році. Цей час був важливим: багатоядерні CPU вже всюди, але класичні шляхи з потоками драйвера в OpenGL часто блокувалися на одному ядрі.
• SPIR-V — частина угоди. Шейдерний формат Vulkan — це проміжне представлення, зроблене для портативності і гнучкості інструментів, а не для радості людей.
• Стали звичкою валідаційні шари. Екосистема Vulkan нормалізувала «запуск з валідацією в CI», чого користувачі OpenGL зазвичай не робили послідовно.
• Descriptor set створювали для пакетування. Vulkan зрушив прив’язку ресурсів у бік попередньо зібраних сетів, щоб уникнути переробок на викликах, особливо при навантаженні на CPU.
• Синхронізацію формалізували явно. Специфікація визначає залежності пам’яті, залежності виконання та layout-и детально — ніякого «драйвер, мабуть, це зробить».
• Портативність з’явилася пізніше. Vulkan за замовчуванням не був «write once run anywhere»; ініціативи портативності як MoltenVK і підсистема портативності виникли з болю.
• Розширення — повноцінний шлях еволюції. Vulkan розвивається через розширення і промоцію в ядро, що добре для фіч і погано для спрощених матриць сумісності.

Звідки береться швидкість (і де її немає)

Справжня перевага Vulkan: менша накладна на CPU і краща паралельність

Головна перемога — це накладні витрати на CPU. Vulkan заохочує будувати command buffer-и заздалегідь, повторно використовувати пайплайни,
мінімізувати зміну станів і уникати валідації на стороні драйвера в релізних збірках. Коли все зроблено правильно, можна розподіляти роботу
по подачі між ядрами: один потік записує UI, інший — геометрію світу, ще один — тіні, і ви збираєте це разом за допомогою secondary command buffer-ів або обережного розділення primary buffer-ів.

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

Інша перемога: передбачувана продуктивність завдяки явності

Передбачуваність — улюблений вид швидкості для SRE. Vulkan змушує вказувати переходи ресурсів і синхронізацію.
Це означає менше «працює на вендорі A» та більше ясності «наш бар’єр неправильний». У виробництві це велика річ.
Детермінована поведінка дозволяє встановлювати SLO на час кадру, ловити регресії рано і тримати випускний цикл під контролем.

Де Vulkan вам не допоможе

• Поганий контент. Overdraw, божевільні варіації шейдерів, текстури 8K на слабкій карті — Vulkan не змінить закони фізики.
• Хаос у пайплайнах. Якщо ви компілюєте пайплайни під час гри, стуттер — ваша провина, не API.
• Параноя синхронізації. Надмірні бар’єри можуть послідовно завантажити GPU ніби це 2008 рік. Vulkan вас не зупинить.
• Тріскання пам’яті. Якщо ви алокуєте/звільняєте кожен кадр, отримаєте фрагментацію, накладні від драйвера й випадкові спайки. Vulkan тільки полегшує зробити це неправильно.

Один афоризм вартий стікера:
«Надія — не стратегія.» — генерал Гордон Р. Салліван.
Vulkan винагороджує інженерів, які замінюють надію інструментуванням і відтворюваними процесами.

Жарт №1: Vulkan — як ручна коробка передач — швидший, коли знаєш, що робиш, і дуже гучний, коли ні.

Податок складності: за що ви насправді платите

1) Тепер ви відповідаєте за синхронізацію

Явна синхронізація Vulkan — одночасно сенс і пастка. Потрібно мислити про:
порядок виконання (що відбувається до чого), видимість пам’яті (які записи стають видимими для яких читань),
і image layout-и (як GPU інтерпретує пам’ять для певної операції).

Класичний режим відмови: ви додаєте бар’єр «щоб бути в безпеці», але обираєте маску pipeline stage, яка змушує GPU
чекати набагато більше роботи, ніж потрібно. Все правильно. Все повільно. Це найпоширеніша трагедія Vulkan: коректність не гарантує продуктивність.

2) Ви відповідаєте за розміщення й життєвий цикл пам’яті

Vulkan показує heap-и пам’яті, типи пам’яті та різницю між host-visible і device-local пам’яттю.
Це чудово, бо ви можете зробити правильно для свого навантаження. Це також вичерпно, бо потрібні політики: хто виділяє, хто звільняє, як субалокується і як уникати фрагментації.

Якщо зробите нічого більше: використайте добре спроектований аллокатор (більшість команд використовує VMA або щось подібне) і стандартизуйтесь
на шаблонах алокації. Керування пам’яттю Vulkan — це не місце для артезіанської креативності.

3) Пайплайни дорогі, і Vulkan робить це вашою проблемою

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

Правильна позиція нудна: препроцесіть, кешуйте, розігрівайте і доставляйте кеші пайплайнів там, де можливо. У Vulkan нудно — конкурентна перевага.

4) Матриця розширень — це реальна робота

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

План швидкої діагностики: знайти вузьке місце швидко

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

1) Перша перевірка: прив’язка до CPU, GPU чи презенту?

• CPU-bound: одне ядро завантажене, GPU недовантажений, час кадру корелює з кількістю draw або складністю сцени, а не з роздільною здатністю.
• GPU-bound: велике завантаження GPU, час кадру масштабується з роздільністю, важкими шейдерами, пропускною здатністю або overdraw.
• Present-bound (vsync / compositor / swapchain): час кадру зафіксований інтервалами оновлення; GPU може простоювати в очікуванні present.

Рішення: не чіпайте шейдери, якщо ви CPU-bound; не мікрооптимізуйте запис command buffer-ів, якщо ви GPU-bound.
Якщо ви present-bound, припиніть «оптимізувати» і виправте режим swapchain або стратегію таймінгу.

2) Друга перевірка: стуттер через компіляцію пайплайнів/шейдерів?

Шукайте спайки, коли з’являються нові матеріали, PSO або ефекти. Якщо спайки зникають через кілька хвилин (розігрів кешів),
значить компіляція відбувається в рантаймі.

Рішення: реалізуйте стратегію кешування пайплайнів, проходи розігріву та/або доставляйте похідні кеші там, де платформа дозволяє.

3) Третя перевірка: синхронізація і бар’єри

Якщо GPU-час високий, але робота здається «занадто малою», перевірте надмірну синхронізацію: pipeline barrier-и, що послідовно виконують несуміжну роботу, непотрібні очікування в чергах або використання timeline semaphore як глобального м’ютекса.

Рішення: звужуйте stage маски, конкретизуйте access маски, переходьте від грубих очікувань по черзі до залежностей на рівні ресурсів,
і розгляньте async compute лише якщо доведено, що є перекриття.

4) Четверта перевірка: поведінка пам’яті і тиск від передач

Слідкуйте за алокаціями за кадр, чатом staging buffer-ів і надмірними копіями buffer/image.
CPU-спайки можуть бути через мапінг/анмапінг пам’яті й flush-ів кешу; GPU-спайки — через насичення пропускної здатності.

Рішення: впровадьте ring buffer-и, постійно замаплені staging-и й пакетну передачу; запровадьте правило «без алокацій під час кадру».

5) П’ята перевірка: презентація і таймінг кадрів

Якщо ваш таймпейс кадрів нерівномірний, ви можете гнатися за невірною метрикою. Середній FPS — марнославство; стабільний час кадру — розум.
Шукайте джиттер від відтворення swapchain, взаємодії з композитором або нестабільної подачі робочих навантажень.

Рішення: обирайте present mode свідомо, контролюйте таймінг кадрів (особливо при VRR), і ставтеся до реконструкції swapchain як до запланованої події.

Практичні завдання з командами: що запускати, що це означає, яке рішення

Це «SRE для графіки» — відтворювані команди, які можна запускати на девмашинах, CI-агентах і візорних коробках клієнтів.
Виводи — приклади; ваше середовище відрізнятиметься. Суть — у тлумаченні та наступному рішенні.

Завдання 1: Підтвердити, що loader і драйвер бачать вашу GPU (Linux)

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

Instance Extensions: count = 20
...

Devices:
========
GPU0:
    apiVersion         = 1.3.275
    driverVersion      = 550.54.14
    vendorID           = 0x10de
    deviceID           = 0x2684
    deviceType         = DISCRETE_GPU
    deviceName         = NVIDIA GeForce RTX 4070

Що це означає: Loader працює, ICD знайдено, і у вас є дискретна GPU, доступна через Vulkan.

Рішення: Якщо список пристроїв пустий або показує лише llvmpipe, виправте інсталяцію драйвера/ICD перед тим, як дебажити додаток.

Завдання 2: Швидко виявити, що ви працюєте на програмній реалізації

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

Що це означає: Ви на CPU-реалізації Vulkan. Скарги на продуктивність цілком обґрунтовані.

Рішення: Перестаньте оптимізувати. Виправте вибір драйвера, PRIME offload, доступ GPU в контейнері або passthrough для VM/віддалених сесій.

Завдання 3: Перевірити, які ICD JSON встановлені (типово для помилок у контейнерах)

cr0x@server:~$ ls -1 /usr/share/vulkan/icd.d/
nvidia_icd.json
intel_icd.x86_64.json

Що це означає: Система має кілька ICD; loader обиратиме залежно від GPU і середовища.

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

Завдання 4: Примусити loader показати, що він робить (debug loader)

cr0x@server:~$ VK_LOADER_DEBUG=all vulkaninfo --summary
INFO:             Vulkan Loader Version 1.3.275
INFO:             Searching for ICDs
INFO:             Found ICD manifest file /usr/share/vulkan/icd.d/nvidia_icd.json
INFO:             Loading ICD library /usr/lib/x86_64-linux-gnu/libvulkan_nvidia.so
...

Що це означає: Ви бачите виявлення і вибір ICD. Це золото, коли «працює на моїй машині» стикається з контейнерами.

Рішення: Якщо завантажується неправильний ICD, встановіть явні контрольні змінні середовища (або виправте пакування), а не гадати.

Завдання 5: Перевірити, що валідаційні шари встановлені і доступні

cr0x@server:~$ vulkaninfo --layers | head
VK_LAYER_KHRONOS_validation (Khronos Validation Layer) Vulkan version 1.3.275, layer version 1
VK_LAYER_MESA_overlay (Mesa Overlay layer) Vulkan version 1.3.275, layer version 1

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

Рішення: Якщо валідації нема — встановіть її або включіть у репозиторій. Не працюйте навпомацки.

Завдання 6: Запустіть додаток з валідацією + детальними повідомленнями (тріаж коректності)

cr0x@server:~$ VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation VK_LAYER_SETTINGS_PATH=/etc/vk_layer_settings.d ./my_vulkan_app
VUID-vkCmdPipelineBarrier2-srcStageMask-03842: Validation Error: srcStageMask includes VK_PIPELINE_STAGE_2_HOST_BIT but no host access mask set.
...

Що це означає: Бар’єр некоректний: ви вказали host stage залежність без відповідної access маски.

Рішення: Спочатку виправте коректність. Будь-яке профілювання продуктивності з некоректною синхронізацією — марна трата часу.

Завдання 7: Захопити кадр за допомогою RenderDoc з командного рядка (відтворюваний repro)

cr0x@server:~$ qrenderdoc --version
qrenderdoc v1.31

Що це означає: RenderDoc UI встановлено. Для автоматизації зазвичай захоплюють через інжекцію або тригери всередині додатку.

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

Завдання 8: Перевірити CPU-гарячі точки за допомогою perf (накладні на запис command buffer-ів)

cr0x@server:~$ perf stat -e cycles,instructions,context-switches,cpu-migrations -p $(pidof my_vulkan_app) -- sleep 5
 Performance counter stats for process id '24188':

     9,845,221,003      cycles
    12,110,993,551      instructions              # 1.23  insn per cycle
           8,214      context-switches
             112      cpu-migrations

       5.001233495 seconds time elapsed

Що це означає: Ви отримали уявлення про вартість CPU і смикання планувальника під час роботи додатку.

Рішення: Якщо context switches/migrations стрибають під час стуттеру, перевірте contention потоків, логування або примітиви синхронізації, що поводяться як глобальні блоки.

Завдання 9: Визначити, чи додаток тихо блокується на present/vsync

cr0x@server:~$ strace -tt -p $(pidof my_vulkan_app) -e trace=futex,nanosleep,clock_nanosleep -s 0
12:44:10.112233 futex(0x7f2d3c00a1c0, FUTEX_WAIT_PRIVATE, 7, NULL) = 0
12:44:10.128901 clock_nanosleep(CLOCK_MONOTONIC, 0, {tv_sec=0, tv_nsec=8000000}, NULL) = 0

Що це означає: Додаток регулярно чекає/спить; часто це корелює з обмеженням кадрів, презентаційним таймінгом swapchain або внутрішнім тротлінгом.

Рішення: Якщо думаєте, що ви GPU-bound, але бачите регулярні sleeps, перевірте present mode, лімитер кадрів і кількість зображень swapchain.

Завдання 10: Перевірити такти GPU та завантаження (приклад NVIDIA)

cr0x@server:~$ nvidia-smi dmon -s pucm -d 1 -c 5
# gpu   pwr gtemp mtemp    sm   mem   enc   dec  mclk  pclk
# Idx     W     C     C     %     %     %     %   MHz   MHz
    0    92    63     -    38    22     0     0  8001  2100
    0   165    67     -    97    75     0     0  8001  2520
    0   160    66     -    96    78     0     0  8001  2520
    0   158    66     -    95    77     0     0  8001  2520
    0    98    63     -    41    24     0     0  8001  2100

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

Рішення: Якщо SM залишається низьким, але FPS низький — ймовірно ви CPU/present/sync-bound. Якщо SM завантажено під максимум — GPU-bound.

Завдання 11: Перевірити тиск на GPU-пам’ять (використання VRAM)

cr0x@server:~$ nvidia-smi --query-gpu=memory.total,memory.used,memory.free --format=csv
memory.total [MiB], memory.used [MiB], memory.free [MiB]
12282 MiB, 10840 MiB, 1442 MiB

Що це означає: Ви близькі до обмеження. Vulkan не захистить вас від пейджингу або евікції; поведінка залежить від драйвера/ОС.

Рішення: Зменшіть резидентність (mip bias, стрімінг текстур, менші кеші) і уникайте створення великих тимчасових зображень у пікових навантаженнях.

Завдання 12: Побачити спам компіляції шейдерів у логах (підпис стуттера)

cr0x@server:~$ journalctl --user -n 200 | grep -i -E "shader|pipeline|spirv" | head
Jan 13 12:41:02 workstation my_vulkan_app[24188]: pipeline: creating graphics pipeline for material=WetConcrete variant=Skinned
Jan 13 12:41:02 workstation my_vulkan_app[24188]: shader: compiling fragment SPIR-V module hash=9c2f...
Jan 13 12:41:02 workstation my_vulkan_app[24188]: pipeline: cache miss, building pipeline key=0x7f1a...

Що це означає: Ви компілюєте пайплайни/шейдери під час виконання. Це генератор стуттеру.

Рішення: Додайте офлайн-крок збірки, проходи розігріву або детермінований етап «скомпілювати всі потрібні пайплайни перед грою».

Завдання 13: Підтвердити режим swapchain і кількість зображень (логування додатку + перевірки)

cr0x@server:~$ grep -E "presentMode|minImageCount|imageCount" /var/log/my_vulkan_app.log | tail -n 5
swapchain: presentMode=VK_PRESENT_MODE_FIFO_KHR
swapchain: minImageCount=2 chosenImageCount=2
swapchain: format=VK_FORMAT_B8G8R8A8_SRGB colorSpace=VK_COLOR_SPACE_SRGB_NONLINEAR_KHR

Що це означає: FIFO — це vsync; два зображення — подвійний буфер. Це може збільшити затримку і зменшити толерантність до спайків.

Рішення: Розгляньте потрійне буферування (3 images) для плавнішого таймінгу кадрів, або MAILBOX, коли це підходить — після вимірювання потреб у затримці.

Завдання 14: Перевірити, що ви випадково не працюєте з дебаг-накладними в релізі

cr0x@server:~$ env | grep -E "VK_INSTANCE_LAYERS|VK_LOADER_DEBUG|VK_LAYER"
VK_INSTANCE_LAYERS=VK_LAYER_KHRONOS_validation
VK_LOADER_DEBUG=all

Що це означає: Валідація і debug loader увімкнені. Добре для налагодження, жахливо для метрик продуктивності.

Рішення: Для прогонів продуктивності очистіть змінні середовища і переконайтесь, що збірка вимикає валідацію і debug-маркери, якщо це не потрібно явно.

Три корпоративні міні-історії з передової

Міні-історія 1: Інцидент через неправильне припущення

Середня студія випустила оновлення рендерера Vulkan, щоб зменшити навантаження CPU в open-world сценах.
Внутрішні дані продуктивності виглядали фантастично на головних тестових машинах команди: нові дискретні GPU, здебільшого того самого вендора.
QA погодилась. Запуск пройшов чисто — поки черга підтримки не почала заповнюватися повідомленнями «випадкове мерехтіння текстур» на ноутбуках.

Баг був періодичний і важко відтворюваний. Кадри зазвичай виглядали нормально, потім кілька об’єктів мигали зі застарілими текстурами,
ніби GPU зразковував пам’ять учора. Команда припустила, що це «баг драйвера», бо артефакти були специфічні для вендора й моделі.

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

Виправлення було просте: коректний бар’єр, вузькі й точні stage/access маски та забезпечення, що переходи layout-ів визначені для точної підресурсної ділянки.
Справжнє виправлення було культурним: валідаційні шари стали обов’язковими в CI і в QA-репро-збірках, і інженери перестали ставитися до перевірок коректності як до необов’язкового десерту.

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

Міні-історія 2: Оптимізація, що дала зворотний ефект

Компанія, що робила CAD-подібний візуалізатор, вирішила «повністю піти на Vulkan» і агресивно пакетувала роботу.
Вони зменшили оновлення дескрипторів, зробивши масивні descriptor set-и з тисячами записів, що оновлювалися рідко,
і індексувалися динамічно. На папері менше оновлень = менше CPU-циклів. Усі кивнули.

Перший прохід продуктивності виглядав добре на топових GPU. Потім вони тестували на різних машинах і побачили дивні падіння:
деякі GPU стали драматично повільнішими при панорамуванні камери, незважаючи на меншу кількість draw та API-викликів.
Час GPU зріс, і причину було неочевидно. Команда спочатку звинуватила складність fragment shader-ів.

Реальність: стратегія «один величезний descriptor set» спричинила погану локальність кешу і збільшила навантаження на апаратні шляхи індексації дескрипторів.
Деякі драйвери впоралися добре; інші платили більше за доступ. Ще гірше — їхній descriptor set став точкою синхронізації, бо оновлення вимагали ретельного фензингу, щоб не змінювати дескриптори в використанні.

Розгортання довелося призупинити. Вони переробили прив’язки в менші descriptor set-и, згруповані за матеріалом і проходом,
використовували descriptor indexing лише там, де це дійсно було корисно, і ввели per-frame ring для динамічних ресурсів.
Навантаження CPU трохи зросло. Стабільність часу кадру покращилася істотно, і розбіжність між GPU зменшилася.

Vulkan охоче прийме вашу «оптимізацію». Також охоче прийме регрес продуктивності.
API не навчає смаку.

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

Команда, що випускала ігровий рушій на Vulkan, мала нудне правило: кожен PR, що торкався рендерингу, мусив мати захоплений кадр
і дві метрики: розбиття часу кадру (CPU/GPU) і відсоток потраплянь у pipeline cache. Не інколи. Кожного разу.
Це дратувало людей. Але також запобігало інцидентам.

Наприкінці релізного циклу інженер змінив код і додав новий варіант постпроцесу.
Фічa була невелика і візуально ледь помітна. PR мав потрібне захоплення, і рецензент помітив дивину:
відсоток потраплянь у pipeline cache впав у сценарії, що мав лишатися незмінним. Час GPU також отримав нові спайки.

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

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

Жарт №2: Найкраща оптимізація Vulkan — та, яку ви не відправили, бо чек-лист рецензії її спіймав.

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

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

Корінь: Відсутня або неправильна синхронізація, помилкові переходи image layout або невідповідність підресурсного діапазону в бар’єрах.

Виправлення: Запускайте з валідаційними шарами; перевірте, що бар’єри використовують правильні stage/access маски; переконайтесь, що переходи layout-ів покривають точні mip/array шари; уникайте «ALL_COMMANDS» як костилю.

2) Симптом: стабільний FPS, але періодичні стуттери при повороті камери

Корінь: Створення пайплайнів або компіляція шейдерів під час гри; cache miss-и пайплайнів; вибух варіацій PSO.

Виправлення: Попередньо збирайте пайплайни офлайн; робіть розігрів при завантаженні; використовуйте pipeline caches; зменшуйте кількість варіацій; логгируйте створення пайплайнів і ставте це як помилку в ігровому режимі.

3) Симптом: низьке завантаження GPU, одне ядро CPU завантажене, багато викликів draw

Корінь: CPU-bound подача/запис; надмірні оновлення дескрипторів; забагато дрібних command buffer-ів; забагато роботи на кожен draw.

Виправлення: Пакетуйте draw-и; зменшуйте зміну станів; використовуйте secondary command buffer-и доречно; мультипотоковий запис; передалокуйте descriptor pool-и; переходьте на bindless/індексацію там, де це доведено корисним.

4) Симптом: час GPU несподівано виріс після «зробити бар’єри безпечними»

Корінь: Надмірна синхронізація: широкі stage маски, непотрібні idle черги, глобальні fence-и, послідовні проходи, що могли б перекриватися.

Виправлення: Звужуйте stage маски; використовуйте бар’єри на рівні ресурсів; надавайте перевагу timeline semaphore для структурованих залежностей; перевірте в GPU-профайлері/захопленні, що перекриття відновлено.

5) Симптом: аварія або device lost під час великого навантаження

Корінь: OOM, незаконний доступ до пам’яті через бага життєвого циклу або TDR/watchdog через довготривалі шейдери/dispatch-и.

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

6) Симптом: Працює на одному вендорі, ламається на іншому

Корінь: Покладання на невизначену поведінку; неправильні припущення про когерентність пам’яті; використання розширень без перевірки можливостей.

Виправлення: Вмикайте валідацію; тестуйте на кількох вендорах якнайраніше; відключайте фічі залежно від запитаної підтримки; уникайте «здається працює» логіки в синхронізації й layout-ах.

7) Симптом: використання пам’яті повільно зростає з часом

Корінь: Утечка VkImage/VkBuffer/VkDeviceMemory; зростання descriptor pool; алокації за кадр, що не повертаються; кеші без евікції.

Виправлення: Додайте трекінг алокацій; реалізуйте аудит життєвих циклів ресурсів; ставте ліміти кешів; використовуйте ring buffer-и для перекадрових алокацій; переконайтесь, що descriptor pool-и ресетяться/переробляються.

8) Симптом: шторм реконструкцій swapchain (чорні кадри, глюки при ресайзі)

Корінь: Неправильне оброблення VK_ERROR_OUT_OF_DATE_KHR / SUBOPTIMAL; гонки в логіці ресайзу; презентація зі старими зображеннями swapchain.

Виправлення: Централізуйте життєвий цикл swapchain; призупиняйте рендер під час реконструкції; перебудовуйте залежні ресурси; перевіряйте, що всі in-flight кадри безпечно спущені.

Чек-листи / покроковий план для адекватного Vulkan у виробництві

Покроковий план: від прототипу до шипабельного продукту

1. Визначте ваш цільовий вузький місце.
   Якщо ви вже GPU-bound, Vulkan не вирішить це сам собою. Вирішіть, чи купуєте ви CPU-головне місце, детермінованість чи портативність.
2. Оберіть модель синхронізації і задокументуйте її.
   Вирішіть, як оброблятимете ресурси за кадр, in-flight кадри і залежності між чергами. Запишіть це як runbook для oncall.
3. Прийміть аллокатор пам’яті і встановіть політики.
   Стандартизуйте стратегію субалокації, правила вирівнювання і заборону алокацій під час кадру.
4. Зробіть створення пайплайнів контрольованою фазою.
   Реалізуйте pipeline caches, стабільні ключі пайплайнів і шлях розігріву. Відстежуйте hit rate кешу як KPI.
5. Побудуйте базу можливостей.
   Запитуйте версію Vulkan, можливості пристрою, ліміти й розширення під час запуску; логгуйте це; використовуйте для фіч-ґейтів і запасних шляхів.
6. Зробіть валідацію обов’язковою в CI і QA-збірках.
   Відправляйте релізи з валідацією вимкненою, але не приймайте PR-ів рендерингу, що не проходять чисто під валідацією.
7. Інструментуйте час кадру, а не FPS.
   Відстежуйте CPU-час кадру, GPU-час кадру, час очікування презенту і перцентилі спайків (p95/p99).
8. Стандартизируйте робочі процеси захоплення.
   Фіксована repro-сцена, детермінований шлях камери, фіксований індекс кадру і відома toolchain для захоплення.
9. Тестуйте на різних вендорах рано.
   Не дозволяйте першому тесту на AMD/Intel ноутбуці відбутися після того, як архітектура застигне.
10. Відправляйте з запобіжниками.
    Runtime-перевірки для несподіваного створення пайплайнів, алокацій під час кадру, виснаження descriptor pool-ів і помилок swapchain. Гучно падайте в дебагу; м’яко деградуйте в релізі.

Операційний чек-лист: що збирати в багу продуктивності клієнта

• Модель GPU, версія драйвера, версія ОС, композитор/віконна система (особливо на Linux).
• Версія Vulkan instance/device і перелік увімкнених розширень/фіч (логувати раз на старті).
• Гістограма часу кадру (не тільки середній FPS) і опис repro-сцени.
• Статистика pipeline cache: попадання/промахи, кількість пайплайнів, створених під час гри.
• Використання VRAM в стані спокою і в піку; чи наближається воно до бюджету.
• Налаштування swapchain: present mode, image count, стан vsync, вікно чи fullscreen.
• Один кадр-захват з repro-точки (із фіксованими налаштуваннями).

Інженерний чек-лист: «Чи ми обрали Vulkan навмисно?»

• Чи можемо ми пояснити нашу модель синхронізації новому інженеру за 10 хвилин?
• Чи є політика проти алокацій за кадр і створення пайплайнів під час гри?
• Чи тестуємо ми щотижня принаймні два вендори GPU?
• Чи є автоматичне виявлення device lost і дієва телеметрія краху?
• Чи можемо ми відтворити регрес продуктивності детерміновано (фіксований seed, фіксований шлях камери)?

FAQ

1) Чи завжди Vulkan швидший за OpenGL або Direct3D?

Ні. Vulkan часто швидший, коли ви CPU-bound через накладні драйвера, зміни станів і вартість submit-ів draw-ів.
Якщо ви GPU-bound, виграш може бути невеликим або відсутнім, якщо Vulkan не дає кращого планування і менше стальків.

2) Чому Vulkan здається таким багатослівним у порівнянні з іншими API?

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

3) Чи слід увімкнути валідаційні шари для тестування продуктивності?

Ні. Використовуйте валідаційні шари для коректності, потім вимкніть їх для прогонів продуктивності. Валідація змінює таймінги і може приховувати або створювати артефакти.
Ставте «validation clean» як воротa перед профілюванням.

4) Яка головна причина стуттеру Vulkan у випущених додатках?

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

5) Чи справді мені потрібен аллокатор як VMA?

Якщо ви випускаєте щось нетривіальне — так. Ручне керування VkDeviceMemory підступне і має тенденцію перерости у фрагментацію,
витоки і непослідовні політики. Аллокатор дає стандартизовану субалокацію, пули і діагностику.

6) Як дізнатися, що мої бар’єри занадто консервативні?

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

7) Який present mode варто використовувати?

FIFO — найширше підтримуваний і поводиться як vsync. MAILBOX може зменшити затримку і стуттер, коли підтримується, але може змінити поведінку таймінгу.
Обирайте на основі виміряної затримки і таймінгу, а не за ідеологією. Також враховуйте кількість зображень swapchain: подвійне буферування крихке під спайками.

8) Чому мій додаток працює на Windows, але падає на Linux (або навпаки)?

Часто це упаковка loader/ICD, різна поведінка WSI або приховані припущення про когерентність пам’яті і синхронізацію.
На Linux деталі композитора й віконної системи важливіші, ніж команди очікують. Використовуйте VK_LOADER_DEBUG і логгуйте можливості при старті.

9) Чи завжди «bindless» через descriptor indexing — це перемога?

Ні. Це може зменшити накладні на CPU і спростити прив’язку, але може створити тиск на кеши і варіативність між вендорами при надмірному використанні.
Використовуйте там, де це реально знижує витрати, і організуйте дескриптори для локальності. Вимірюйте на цільових GPU.

10) Що зазвичай означає «device lost» на практиці?

Це може бути реальна помилка GPU, але частіше це баг додатку (незаконний доступ до пам’яті, неправильна синхронізація),
хаос OOM/евікцій або watchdog timeout через довгі GPU-роботи. Розглядайте це як крах: збирайте телеметрію і відтворюйте під валідацією.

Наступні кроки, які ви реально можете зробити

Ціннісна пропозиція Vulkan проста: передбачуваний низькорівневий контроль в обмін на те, що ви берете на себе відповідальність, яку раніше ніс драйвер.
Якщо цей компроміс відповідає вашому продукту — CPU-bound рендерер, суворі вимоги до таймінгу, багатовендорна детермінованість — йдіть з відкритими очима.
Інакше обирайте щось вищого рівня і витрачайте інженерний бюджет на контент і інструменти.

Практичні наступні кроки, в порядку:

1. Зробіть прогони з валідаційними шарами звичкою. Запускайте їх у CI і зробіть «validation clean» воротами для змін рендерингу.
2. Інструментуйте час кадру і поведінку кешу. Відстежуйте CPU/GPU/present час окремо; логгуйте попадання/промахи pipeline cache і створення пайплайнів у рантаймі.
3. Встановіть політику пам’яті. Прийміть аллокатор, забороніть алокації під час кадру і відстежуйте використання VRAM відносно бюджету.
4. Кодифікуйте шаблони синхронізації. Запишіть конвенції бар’єрів, життєві цикли ресурсів і модель in-flight кадрів, як ніби це oncall runbook.
5. Побудуйте детермінований репро-харнес. Фіксована сцена, фіксований шлях камери, фіксовані захоплення кадрів. Якщо ви не можете відтворити — ви не можете покращити.
6. Тестуйте на різних вендорах рано і постійно. Невизначена поведінка — це борг, що наростає у найгірший момент: перед релізом.

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