Гонка озброєнь DirectX: чому драйвери іноді випереджають кремній

October 21, 2025 • February 3, 2026 • Читання: 5 хв • Views: 0

Було корисно?

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

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

Драйвери проти кремнію: звідки справді береться продуктивність

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

Насправді ваш час кадру — це сума:

Робота на боці CPU: побудова командних списків, відсічення невидимих об’єктів, фізика, анімація та витрати на спілкування з драйвером/рантаймом.
Робота драйвера/рантайму: трансляція викликів API в пакети для заліза, валідація, кешування, управління пам’яттю та станом.
Робота на боці GPU: виконання шейдерів, фікс-функціональні стадії, растеризація, RT‑ядра, копіювальні двигуни тощо.
Present і кадрування: композиція, vsync, поведінка flip-моделі та планування ОС навколо цього.

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

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

Що насправді обіцяє DirectX (а чого не обіцяє)

DirectX — це не «тонкий шар над залізом». Це обіцянка сумісності з набором абстракцій.
Ці абстракції змінюються з часом — Direct3D 9 vs 11 vs 12 фактично різні парадигми — і кожна зміна змінює того, хто платить за які витрати.

Direct3D 11: драйвер робив багато невидимої роботи

D3D11 зробив розробників продуктивними, дозволивши їм бути трохи безвідповідальними. Можна було спамити виклики draw,
постійно змінювати стани й чекати, що драйвер впорається з ризиками, перещепить роботу й виправить рішення.
Це не було безкоштовно. Драйвер часто виконував важку роботу на CPU для кожного draw, і цей оверхед міг домінувати над часом кадру.

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

Direct3D 12: отримуєш потужність — отримуєш рахунок

D3D12 — нижчорівневий API. Додаток має більше керувати явно: стани ресурсів, синхронізація, дескрипторні купи, PSO
і стратегія компіляції шейдерів. Теоретично — менше оверхеду драйвера.
Насправді — більше шансів створити патологічні робочі навантаження й потім звинуватити «драйвер».

Драйвер усе одно має величезне значення в D3D12, бо:

Компіляція шейдерів, кешування та бекенд драйвера для codegen все ще різняться між вендорами й версіями.
Резидентність пам’яті і пейджинг усе ще опосередковані WDDM і політикою драйвера.
Планування все ще підпорядковане правилам ОС і драйвера (апаратні черги, пріоритети, гранулярність преземпшну).
Поведение pipeline library та кешів PSO може вирішувати, чи буде ваш «перший запуск» містити сильні підвиси.

DirectX — рухома ціль, а «ціль» — це ваш випущений проєкт

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

Як драйвери перемагають: важелі продуктивності, яких ви не бачите

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

1) Компилятори шейдерів: тихі королі

HLSL компілюється в DXIL (або старіший байткод), а потім драйвер знову компілює в ISA для GPU.
Останній етап — це місце, де живе багато «магії драйвера»: планування інструкцій, розподіл регістрів,
рішення щодо occupancy хвиль, математиці трансформацій і спеціалізації з урахуванням відомих особливостей заліза.

Оновлення драйвера може змінити codegen настільки, що:

Збільшиться occupancy (менше регістрів) і виросте пропускна здатність у завданнях, чутливих до пропускної здатності.
Зменшаться затримки за рахунок кращого планування інструкцій навколо латентності вибірки текстур.
Виправляться некоректні компіляції або проблеми з точністю, які змушували використовувати повільні запасні шляхи.
Налаштуються підгрупові/хвильові операції, що впливає на витрати дивергенції.

Компилятори шейдерів — також причина, чому «на цьому вендорі стало швидше»: у кожного вендора свої евристики і ступінь зрілості.
Це не шахрайство; це інженерія. Але інженерія, яка змінює продукт після покупки.

2) Обробка й кешування Pipeline State Object (PSO)

PSO в D3D12 мають створювати наперед. Якщо ви створюєте PSO під час виконання в середині кадру, ви заслуговуєте на підвисання.
Але реальність складніша: пайплайни контенту, моди, динамічні пермутації й live‑service зміни.
Драйвер може допомогти, ефективно кешуючи скомпільовані PSO, або зашкодити, інвалідуючи кеші при оновленнях.

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

3) Подання команд і батчинг

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

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

4) Резидентність пам’яті, пейджинг і «урвиско VRAM»

Управління графічною пам’яттю в Windows — це задача трьох тіл: наміри додатка, політика драйвера, політика ОС.
Коли ваш робочий набір вміщується у VRAM, все добре. Коли ні — ви зриваєтеся зі скелі в пейджинг,
зупинки та «чому мій 1% такий поганий?».

Драйвери впливають на рішення про резидентність, евікшн‑евристики та наскільки агресивно передзавантажувати.
Дві версії драйвера можуть поводитися по-різному під тиском: один починає трешити, інший деградує плавно.
Якщо ви женетеся за підвисаннями — припускайте, що ви поруч із межею резидентності, поки не доведете протилежне.

5) Планування і преземпшн: WDDM — не ваш друг, це ваш орендодавець

Політики планування WDDM визначають, як контексти ділять GPU. Ігри конкурують з браузерами, відтворенням відео,
оверлеями захоплення, панелями RGB і композитором ОС. Драйвер бере участь у цьому плануванні.

Оновлення драйвера може підправити гранулярність преземпшну, пріоритети черг або поведінку таймінгу навколо present.
Це може суттєво змінити кадрування навіть якщо середній FPS залишається тим самим.

6) Режими Present, кадрування та «плавність» як інженерна властивість

Користувач відчуває не «середній FPS». Він відчуває часи кадрів і їхнє кадрування.
Режим present (flip‑модель проти blit), vsync, VRR і поведінка композитора вирішують, чи ваш бюджет 16.6 мс
буде стабільним чи рулеткою.

Драйвери можуть:

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

7) Обхідні шляхи: непоказне мистецтво випуску

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

Ось чому іноді ви бачите, що нова гра «працює краще на вендорі X» після day‑one драйвера: не тому, що кремній
навчився нових трюків за ніч. Драйвер навчився виживати при поведінці тієї гри.

Жарт №1: Драйвери як кава — всі кажуть, що можуть без них, а потім дивишся, як вони пробують.

Факти й історія: гонка озброєнь у 10 шрамів-крапель

Епоха D3D9: «замінники шейдерів» були поширені: драйвери іноді підмінювали шаблони шейдерів на швидші еквіваленти, коли їх розпізнавали.
D3D10 приніс великий скидання: він ущільнив модель API і порушив багато «хитрих» поведінок драйверів з D3D9.
D3D11 популяризував багатопоточне рендеринг… умовно: відкладені контексти існували, але багато рушіїв досі потрапляли в локи драйвера і CPU‑вузькі місця.
Mantle вплинув на D3D12: індустрія отримала підказку, що великий оверхед драйвера вбивав сцени з великою кількістю draw‑викликів.
Еволюція WDDM змінила продуктивність: WDDM 1.x vs 2.x принесли різну динаміку управління пам’яттю і планування для сучасних GPU.
Shader Model 6 рухався в бік DXIL: конвеєр компіляції став стандартизованішим, але бекстенд драйвера все ще вирішує фінальний ISA.
Flip‑модель present стала нормою: сучасний Windows віддає перевагу flip‑моделі для ефективності; це змінює латентність і кадрування в порівнянні зі старими blit‑шляхами.
Адаптація DXR виявила прогалини зрілості драйверів: рання продуктивність трасування променів часто сильно коливалася з оновленнями драйвера, бо стек був новим і швидкі шляхи еволюціонували.
Resizable BAR мав значення в деяких DX навантаженнях: увімкнення доступу CPU до більшого діапазону VRAM змінювало шаблони трансферів і зменшувало оверхед у певних сценаріях.
«Day‑one драйвери» стали ринковою очікуваністю: не тому, що маркетинг просив, а тому, що обходи на боці драйвера і налаштування кешу шейдерів стали частиною готовності запуску.

Типові режими відмов: коли драйвер стає вузьким місцем

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

CPU‑овий оверхед драйвера (особливо D3D11)

Симптоми: одне CPU‑ядро під зав’язку, GPU недовантажений, FPS обмежений «render thread», масштабування більше з кращими CPU ніж з кращими GPU.
Кореневі причини включають багатослівні зміни стану, надмірну кількість draw‑викликів, неефективні оновлення ресурсів або серіалізацію драйвера через локи.

Підвисання від компіляції шейдерів (DX12, і також DX11 при неправильній роботі)

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

Треш резидентності VRAM

Симптоми: періодичні зупинки, різкі провали при обертанні камери, велика розбіжність при високороздільних текстурах, гірше в безрамковому режимі з іншими відкритими додатками.
Корінь проблеми: робочий набір перевищує VRAM або фрагментація викликає евікшини; драйвер/ОС пейджить у системну пам’ять.

Проблеми з present/композицією

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

Регресії драйверів і «виправлення», які пересувають проблему

Симптоми: одна гра прискорилась, інша уповільнилась, або ваше стабільне навантаження стало нестабільним після оновлення.
Корінь: зміни евристик, зміни кешування або ввімкнення/вимкнення швидких шляхів через обхідні налаштування.

Швидкий план діагностики (перший/другий/третій)

Це чекліст, яким я користуюся, коли хтось каже «DX продуктивність дивна» і мені треба отримати сигнал за 15 хвилин.
Мета — визначити, яка черга голодує: CPU, драйвер, GPU, резидентність пам’яті чи present.

Перший: вирішіть, чи ви CPU/драйвер‑обмежені або GPU‑обмежені

Дивіться використання CPU по ядрах і завантаження двигунів GPU.
Якщо завантаження GPU низьке, але одне CPU‑ядро гаряче, підозрюйте оверхед драйвера або вузьке місце render thread.
Якщо GPU на ~95–100% і CPU помірний — ймовірно GPU‑bound (зосередьтесь на шейдерах, пропускній здатності, налаштуваннях).

Другий: ідентифікуйте клас стутера (компіляція, резидентність, present)

Стутер при першому показі ефекту: компіляція шейдерів/PSO.
Стутер при повороті камери або вході в нові області: стримінг/резидентність.
Стутер зі стабільним GPU‑часом, але нерівним present: кадрування/композитор/оверлеї.

Третій: агресивно бісектуйте змінні

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

Правило рішення: якщо ви не можете назвати вузьку чергу, ви ще не діагностуєте — ви оповідаєте історію.

Практичні завдання з командами: вимірюй, вирішуй, повторюй

Ці завдання призначені для Windows‑систем, але я використовую shell на кшталт bash (Git Bash, MSYS2, WSL, що викликає Windows‑утиліти).
Команди реалістичні. Ідея — дисципліна: захоплюйте докази, інтерпретуйте їх, вирішуйте, що робити далі.

Завдання 1: Підтвердіть модель GPU і версію драйвера

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-CimInstance Win32_VideoController | Select-Object Name,DriverVersion,DriverDate | Format-Table -Auto"
Name                          DriverVersion      DriverDate
----                          -------------      ----------
NVIDIA GeForce RTX 4070       31.0.15.5212       11/28/2024 12:00:00 AM

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

Завдання 2: Перевірте збірку Windows і підказки версії WDDM

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber | Format-List"
WindowsProductName : Windows 11 Pro
WindowsVersion     : 23H2
OsBuildNumber      : 22631

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

Завдання 3: Швидко захопіть завантаження двигунів GPU

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Counter '\GPU Engine(*)\Utilization Percentage' -SampleInterval 1 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object InstanceName,CookedValue | Sort-Object CookedValue -Descending | Select-Object -First 10 | Format-Table -Auto"
InstanceName                                        CookedValue
------------                                        ----------
pid_1234_luid_0x00000000_0x0000_engtype_3D             92.3412
pid_1234_luid_0x00000000_0x0000_engtype_Copy            4.1201
pid_5678_luid_0x00000000_0x0000_engtype_VideoDecode     1.0033

Що це означає: Високе 3D‑завантаження вказує на обмеження зі сторони GPU; низьке 3D при високому CPU — на подачу/драйвер.
Рішення: Якщо 3D низьке, перестаньте крутити графічні налаштування і почніть профілювати CPU/драйверний оверхед.

Завдання 4: Перевірте CPU по процесах і знайдіть насичення одного потоку

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process | Sort-Object CPU -Descending | Select-Object -First 8 Name,Id,CPU,Threads | Format-Table -Auto"
Name        Id    CPU   Threads
----        --    ---   -------
GameClient  1234  987.4  62
Discord     4321  112.6  45
chrome      8888   71.9  83

Що це означає: Великий CPU‑час і багато потоків не доводять багатопоточний рендеринг; це часто маскує одне гаряче render thread.
Рішення: Якщо FPS низький і одне ядро зашпиговане в Диспетчері завдань, трактуйте це як CPU/драйвер‑обмеження, поки GPU‑час не доведе протилежне.

Завдання 5: Перевірте логи Event Viewer на помилки DXGI і драйвера

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 50 | Where-Object {$_.ProviderName -match 'Display|dxgkrnl'} | Select-Object TimeCreated,Id,ProviderName,Message | Format-Table -Wrap"
TimeCreated           Id ProviderName Message
-----------           -- ------------ -------
1/12/2026 9:41:02 PM 4101 Display     Display driver nvlddmkm stopped responding and has successfully recovered.

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

Завдання 6: Перевірте стан композиції DWM і конфігурацію оновлення

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process dwm | Select-Object Name,Id,CPU,StartTime | Format-List"
Name      : dwm
Id        : 1024
CPU       : 58.12
StartTime : 1/12/2026 7:03:11 PM

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

Завдання 7: Ідентифікуйте оверлеї і хукери захоплення як першочергових підозрюваних

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process | Where-Object {$_.Name -match 'GameBar|Xbox|RTSS|obs|Discord|Steam|nvcontainer'} | Select-Object Name,Id | Format-Table -Auto"
Name         Id
----         --
GameBar      7777
Discord      4321
Steam        2468
nvcontainer  1357

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

Завдання 8: Перевірте активність диска і тиск на розташування кешу шейдерів

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Counter '\PhysicalDisk(_Total)\Disk Bytes/sec' -SampleInterval 1 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object CookedValue"
CookedValue
-----------
124928512
98234368
110231552

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

Завдання 9: Підтвердіть стан файлу підкачки (пейджинг може підсилювати проблеми з резидентністю)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-CimInstance Win32_PageFileSetting | Select-Object Name,InitialSize,MaximumSize | Format-Table -Auto"
Name               InitialSize MaximumSize
----               ----------- -----------
C:\pagefile.sys    16384       32768

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

Завдання 10: Швидко перевірте тиск пам’яті

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Counter '\Memory\Available MBytes' -SampleInterval 1 -MaxSamples 3 | Select-Object -ExpandProperty CounterSamples | Select-Object CookedValue"
CookedValue
-----------
812
790
765

Що це означає: Низький об’єм вільної RAM підвищує ймовірність стутеру через пейджинг і конфлікт стримінгу активів.
Рішення: Якщо вільна RAM падає нижче ~1–2 ГБ під час гри, закрийте фонові додатки перед тим, як звинувачувати GPU.

Завдання 11: Перевірте, чи гра дійсно використовує DX12 (або DX11)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-Process GameClient | Select-Object -ExpandProperty Modules | Where-Object {$_.ModuleName -match 'd3d12|d3d11|dxgi'} | Select-Object ModuleName,FileName | Format-Table -Auto"
ModuleName FileName
---------- --------
dxgi.dll   C:\Windows\System32\dxgi.dll
d3d12.dll  C:\Windows\System32\d3d12.dll

Що це означає: Ви будете здивовані, як часто «DX12 продуктивність» тестується, коли додаток таємно впав на DX11.
Рішення: Якщо завантажено неправильний API, виправте опції запуску/конфіг; не інтерпретуйте показники продуктивності, поки шлях API не підтверджено.

Завдання 12: Перевірте план живлення і поведінку частоти CPU

cr0x@server:~$ powercfg.exe /getactivescheme
Power Scheme GUID: 381b4222-f694-41f0-9685-ff5bb260df2e  (Balanced)

Що це означає: Агресивні режими енергозбереження можуть збільшити латентність і погіршити кадрування в сценаріях, обмежених CPU/драйвером.
Рішення: Для діагностики використовуйте високопродуктивний план на десктопах, потім перевіряйте вплив перед тим, як залишати його назавжди (ноути інші).

Завдання 13: Помітте тиск GPU‑пам’яті через інструменти вендора (приклад NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,utilization.gpu,memory.used,memory.total --format=csv
name, driver_version, utilization.gpu [%], memory.used [MiB], memory.total [MiB]
NVIDIA GeForce RTX 4070, 552.12, 91 %, 11342 MiB, 12282 MiB

Що це означає: Використання пам’яті поруч із максимумом свідчить, що ви фліртуєте з евікшинами і пейджингом (особливо при 4K + високих текстурах).
Рішення: Якщо пам’ять >90% і ви бачите стутер — спочатку зменшіть якість текстур або роздільну здатність; не ганяйтеся поки за «налаштуваннями драйвера».

Завдання 14: Захопіть швидкий ETW‑трейс для планування GPU/present (підготовка)

cr0x@server:~$ wpr.exe -start GPU -filemode
WPR: Started recording with profile GPU.

Що це означає: Ви записуєте ETW‑трейс, який потім можна аналізувати в WPA, щоб побачити затримки present, черги GPU і подачу на CPU.
Рішення: Якщо лічильники не дають відповіді, зробіть трейc. Гадання повільніше за вимірювання.

Завдання 15: Зупиніть трейс і збережіть його

cr0x@server:~$ wpr.exe -stop C:\temp\gpu-trace.etl
WPR: Trace successfully saved to C:\temp\gpu-trace.etl

Що це означає: Тепер у вас файл, що показує, куди пішов час: CPU, GPU, present, DWM, черги драйвера.
Рішення: Використайте WPA, щоб підтвердити: чи ви заблоковані на present, чекаєте на GPU або CPU‑обмежені в драйверних викликах?

Завдання 16: Базова перевірка мережі (так, це важливо для скарг на «стутер»)

cr0x@server:~$ ping -n 10 1.1.1.1
Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=15ms TTL=58
Reply from 1.1.1.1: bytes=32 time=16ms TTL=58
Reply from 1.1.1.1: bytes=32 time=120ms TTL=58
Reply from 1.1.1.1: bytes=32 time=16ms TTL=58

Ping statistics for 1.1.1.1:
    Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 15ms, Maximum = 120ms, Average = 26ms

Що це означає: Гравці скаржаться на «стутер», який насправді мережевий джиттер, що викликає підвисання анімації/стримінгу в онлайн‑тайтлах.
Рішення: Якщо графіки часу кадру не показують підвисань, але UX страждає — перевірте мережеву варіабельність, перш ніж переписувати рендерер.

Три короткі історії з корпоративної реальності

Коротка історія 1: Інцидент, спричинений неправильною припущенням

Студія випустила оновлення DX12 для живої гри. Зміни виглядали чистими: менше draw‑викликів, кращий батчинг,
більш явні бар’єри та крок попередньої збірки PSO під час екранів завантаження. Команда припускала, що якщо гра
працює на їхніх внутрішніх тестових машинах, вона працюватиме на машинах клієнтів з «подібними GPU».

На тижні релізу пішли звернення в підтримку: випадкові 2–3‑секундні зависання в першому матчі, іноді із подальшим крашем.
Зависання не завжди відтворювалося в офісі. Коли відтворювалося — хтось знизував плечима і звинувачував «Windows як Windows».
Тим часом канал інцидентів наповнився гравцями, які ділилися обхідними прийомами на кшталт «пограй один бот‑матч спочатку» і «не alt‑tab».

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

Фікс не був «скажіть гравцям оновити драйвери», хоча це зменшило масштаб проблеми. Справжній фікс був інженерний:
додати детерміністичний шлях розігріву шейдерів/PSO, що охоплює поширені пермутації, зберігати кеш PSO на боці додатка,
і додати телеметрію подій компіляції, корельовану зі спайками кадрів. Також оновили runbook інциденту, щоб ставити питання
«чи це інвалідизація кешу?» перед тим, як звинувачувати рендерер.

Коротка історія 2: Оптимізація, що обернулася проти

Корпоративний візуалізаційний додаток (уявіть CAD + рендеринг у реальному часі) зіткнувся з CPU‑вузьким місцем у D3D11.
Render thread був гарячим, і команда зробила те, що роблять команди під дедлайном: переклала більше роботи на воркер‑потоки, використовуючи deferred contexts.
Ідея була проста — паралелізувати запис команд, зменшити час у драйвері на головному потоці і тримати GPU зайнятим.

У синтетичних тестах середній FPS покращився. Команда святкувала. Потім користувачі почали повідомляти про «рандомні підвисання» при
повороті великих збірок. Підвисання були гіршими на високопродуктивних CPU, що завжди чудовий спосіб почати зустріч.

Відкатка сталася через поведінку драйвера і витрати на синхронізацію. Шлях deferred context збільшив кількість
злитих командних списків за кадр і ввів контенцію при оновленні ресурсів, які не були спроектовані для паралелізму.
Драйвер також частіше потрапляв у внутрішні локи, бо додаток створював лавину дрібних командних списків, кожен зі змінами стану,
які драйвер раніше міг дедуплікувати в однопотоковому потоці.

Вони врешті відкрутили зміну для найгірших випадків і реалізували більш нудне виправлення: зменшили зміни станів, батчили draw‑виклики по матеріалах
і агресивно кешували незмінні об’єкти стану. Також обмежили використання deferred contexts для специфічних робочих навантажень, де це
послідовно допомагало. Урок не в «потоки погані». Урок у тому, що оверхед драйвера не є чистою функцією кількості ядер CPU.

Коротка історія 3: Сумна, але правильна практика, що врятувала день

Невелика ops‑команда підтримувала флот кіосків Windows з інтерактивним DirectX‑досвідом. Апаратура була ідентична за PO,
але реальний світ мав інші плани: оновлення Windows відбувалися, драйвери GPU дрейфували, а вендор випустив нову утиліту‑оверлей,
яка «допоміжно» моніторила продуктивність.

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

Одного місяця нова версія драйвера покращила продуктивність у популярному бенчмарку гри, і менеджмент запитав, чому кіоски не оновлено негайно.
Ops‑команда опиралася. В стейджингу вони знайшли таймінгову проблему present на специфічному 60Hz панелі кіоска, що викликала мікростютер —
FPS не падав, але відчуття було жахливим.

Вони тримали оновлення, подали тикет вендору з мінімальною репродукцією (плюс ETW‑трейси) і розгорнули кіоски з зафіксованою версією.
День був врятований практикою, про яку ніхто не хвалиться на конференціях: контрольований розгорт, базові метрики і сміливість сказати «не зараз».

Жарт №2: Оновлення драйвера — це лотерейний квиток, де виграш — «ваш додаток працює як у вівторок минулого тижня».

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

Цей розділ існує, щоб ви не марнували тиждень. Це повторювані провини, які я бачив у іграх, візуалізації і корпоративних UI‑додатках на DirectX.

1) Симптом: низьке використання GPU, низький FPS

Корінь: вузьке місце у подачі/драйвері (занадто багато draw, багато змін стану, або оверхед D3D11).
Виправлення: зменшити кількість викликів draw; батчити по матеріалах; уникати зайвих змін стану; переходити на D3D12 лише якщо ви можете керувати явними витратами.

2) Симптом: 1% lows жахливі, середні значення нормальні

Корінь: стутер від компіляції шейдерів, створення PSO в середині кадру або треш резидентності VRAM.
Виправлення: препроцесіть/розігрійте PSO; зберігайте бібліотеки PSO; переконайтеся, що кеш шейдерів увімкнений; знизьте якість текстур якщо VRAM близький до повного.

3) Симптом: стуттер у безрамковому вікні; ексклюзивний повноекран гладкий

Корінь: шлях композиції/оверлеї/таймінгові взаємодії DWM.
Виправлення: вимкніть оверлеї; протестуйте різні режими present; віддавайте перевагу flip‑моделі; розгляньте ексклюзивний повноекран для чутливих до латентності додатків.

4) Симптом: стутер з’являється після оновлення драйвера, потім зникає через «якийсь час»

Корінь: кеші шейдерів інвалідовано; компіляція відбувається поступово при зустрічі контенту.
Виправлення: забезпечити in‑app розігрів шейдерів; не інтерпретуйте «перший запуск» як стабільний стан; документуйте поведінку кешу для підтримки.

5) Симптом: випадкові зависання, іноді з подією ресету драйвера

Корінь: TDR через зависання GPU, нестабільні частоти/undervolt або баг драйвера, викликаний конкретним шляхом шейдера.
Виправлення: поверніть стоки частот; зменшіть агресивні undervolt; захопіть ETW + дамп; якщо відтворюється — мінімізуйте шейдер і подайте баг вендору.

6) Симптом: продуктивність сильно відрізняється між вендорами для того самого DX12 контенту

Корінь: різні бекстенди компілятора і евристики; різні sweet spot для розміру хвиль, регістрів і бар’єрних шаблонів.
Виправлення: використовуйте незалежне профілювання (PIX + інструменти вендорів); уникайте невизначеної поведінки; тестуйте кілька варіантів шейдерів при потребі.

7) Симптом: «оновив GPU, але покращення немає»

Корінь: вузьке місце CPU/драйвер, проблеми з PCIe‑лінком, обмеження планом живлення або додаток обмежений present/vsync.
Виправлення: перевірте обмеження present/vsync; перевірте насичення CPU‑ядер; підтвердіть швидкість PCIe в інструментах вендора; тестуйте uncapped режим для діагностики.

8) Симптом: мікростютер без очевидних спайків CPU/GPU

Корінь: кадрування і нерегулярності черги present (часто через композитор/VRR/невідповідність частот оновлення).
Виправлення: змініть режим present (ексклюзивний vs безрамковий); вирівняйте налаштування частоти оновлення; зменшіть фонові GPU‑клієнти; запишіть present з ETW.

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

Чекліст A: Гігієна відтворення (перестаньте самі себе газлайтити)

Зафіксуйте точну версію драйвера і збірку ОС для тесту.
Вимкніть оверлеї і інструменти захоплення для базових прогонів.
Запишіть налаштування: роздільна здатність, vsync/VRR, режим вікна, апскейлери.
Запустіть одну й ту саму сцену тричі: холодний старт, прогріттий прогін, ще один прогріттий прогін.
Логуйте статистику часу кадру (середнє, 1% low) і позначайте місця, де з’являються підвисання.

Чекліст B: Визначте, яке підсистема винна

Якщо GPU‑завантаження низьке і одне CPU‑ядро гаряче: зосередьтесь на подачі/драйверному оверхеді.
Якщо GPU‑завантаження високе: аналізуйте вартість шейдерів, полосу пропускання і налаштування.
Якщо стутер при першому показі ефекту: фокус на компіляції шейдерів/PSO.
Якщо стутер при вході в нові області: фокус на стримінгу і резидентності.
Якщо стутер залежить від режиму (безрамковий vs повноекран): фокус на present/композиторі.

Чекліст C: Триаж регресій (як припинити сварки в Slack)

Відтворіть на двох машинах: одна контрольна, одна уражена.
Бісектуйте версії драйвера (останній добрий → перший поганий), якщо можливо.
Захопіть ETW‑трейси на обох і порівняйте поведінку present + черг GPU.
Перевірте поведінку кешу шейдерів (чи скидається? чи записується на диск?).
Якщо регресія специфічна для вендора — скоротіть до мінімального тесту і коректно подайте баг.

Чекліст D: Рекомендації перед релізом

Реалізуйте пред‑збірку PSO і кеш керованих додатком для поширених пермутацій.
Забезпечте опцію «розігрів шейдерів» або робіть це автоматично в неінтерактивні моменти.
Трекуйте події компіляції й затримки present у телеметрії (з дотриманням приватності та згоди).
Тестуйте на кількох версіях драйверів, включаючи старі «популярно стабільні».
Документуйте відомі проблемні оверлеї і давайте користувацькі інструкції, які не перекладають провину на них.

FAQ

1) Як оновлення драйвера може зробити мій GPU швидшим без зміни апаратного забезпечення?

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

2) Чи завжди DX12 швидший за DX11?

Ні. DX12 зменшує певні оверхеди драйвера, але перекладає відповідальність на додаток. Якщо рушій створює PSO в середині кадру,
неправильно обробляє бар’єри або заливає систему дрібними подачами, DX12 може бути повільнішим або викликати більше стутерів.

3) Чому я отримую стутер лише в першому матчі або при першому завантаженні?

Здебільшого це компіляція шейдерів або створення PSO на вимогу, плюс холодні кеші. Оновлення драйвера також можуть інвалідовувати кеші.
Виправлення — попередня компіляція/розігрів і постійне кешування, а не просто «більше FPS».

4) У чому різниця між «GPU bound» і «driver bound»?

GPU bound означає, що GPU зайнятий виконанням роботи і час кадру слідує за часом GPU. Driver bound означає, що CPU/драйвер не встигають підготувати або подати роботу,
тому GPU чекає. Низьке завантаження GPU при гарячому render thread — класична підказка.

5) Чи справді оверлеї такі важливі?

Так. Багато оверлеїв хукають Present, додають роботу для композиції або вводять синхронізацію. Вони також можуть змінити режим present або заважати VRR.
Для діагностики — вимикайте їх. Для релізу — передбачайте, що користувачі їх запускатимуть, і зробіть шлях present стійким.

6) Чому «плавність» змінюється, навіть якщо середній FPS незмінний?

Кадрування — це про дисперсію, а не про середнє. Поведінка черги present, таймінги композитора і планування можуть зробити кадри нерівними.
Драйвери можуть змінювати це оновленнями, бо вони модифікують евристику таймінгів і синхронізації.

7) Чи варто казати користувачам завжди ставити останній драйвер?

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

8) Чи можуть драйвери включати оптимізації і обходи для конкретних ігор?

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

9) Який найшвидший спосіб знайти вузьке місце?

Корелюйте спайки часу кадру з або часом подачі на CPU, або часом виконання GPU, або затримкою present. Якщо лічильників недостатньо —
захопіть ETW‑трейс (WPR/WPA) і подивіться черги GPU та події Present.

10) Чи це «шахрайство», коли драйвери оптимізують під конкретні шаблони?

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

Одна операційна принципова ідея варта запам’ятовування

Парафразована ідея, приписувана Gene Kim: покращуйте потік і скорочуйте цикли зворотного зв’язку; малі, вимірювані зміни кращі за героїчні здогади.
Це застосовується до регресій драйверів і роботи з продуктивністю не менше, ніж до аварій.

Висновок: наступні кроки, які дійсно дають результат

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

Практичні наступні кроки:

Перестаньте діагностувати на відчуттях. Підтвердьте шлях API, версію драйвера, збірку ОС і режим present перед порівняннями.
Класифікуйте вузьку чергу. CPU/драйвер vs GPU vs резидентність vs present. Потім оптимізуйте правильну річ.
Зробіть компіляцію нудною. Prebuild PSO, розігрівайте шейдери та зберігайте кеші, щоб «перший запуск» не був кошмаром.
Ставтесь до драйверів як до залежностей. Фіксуйте версії, етапно розгортайте, тримайте останню відому хорошу версію.
Коли лічильники брешуть — використовуйте трейси. ETW — дорослий підхід, коли кадрування веде себе дивно.

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