Драйвери Arc: як покоління GPU виправляють публічно

November 26, 2025 • February 3, 2026 • Читання: 6 хв • Views: 0

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

Біль: ви купили нове покоління GPU, а воно поводиться як бета‑продукт. Ігри підгальмовують. Енкодери пропускають кадри. Ваші графіки моніторингу брешуть, бо драйвер показує «99% GPU», а потім нитка процесора тихо «горить».

Intel Arc — особливо публічний кейс, бо він з’явився на ринку з очікуванням «встановив драйвер — працює». Натомість Arc змусив усіх — включно з Intel — заново пригадати старий урок: GPU — це не просто чіп, це програмна платформа, яка випадково містить чіп.

Що насправді означає «виправляють публічно»

Коли люди кажуть «драйвери Arc виправляють», вони часто уявляють якусь монолітну команду, що просто переключає кілька перемикачів. Реальність складніша й цікавіша.

Сучасний «драйвер» GPU — це стек:

Kernel mode driver: планування, управління пам’яттю, живлення, перемикання контекстів. На Linux для Arc це i915 (для Alchemist) та суміжні компоненти.
User mode driver: реалізація API (Direct3D, Vulkan, OpenGL), компілятор шейдерів, кеші пайплайнів, перекладні шари.
Firmware: внутрішній контролерний код GPU. Так, ви можете випустити «новий кремнієвий» продукт і пізніше виправляти поведінку прошивкою, у межах можливостей.
Runtime layers: DXVK, vkd3d-proton, власні кеші шейдерів ігор, інжектори оверлеїв, хук‑античит.
Platform constraints: налаштування BIOS як Resizable BAR, особливості материнської плати, поведінка планувальника Windows, топологія PCIe.

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

Arc зробив це помітним, бо це був перший серйозний дискретний GPU Intel за довгий час, і він потрапив у сучасне очікування, що DX11, DX12, Vulkan, OpenGL, відео‑енкод/декод, стрімінг, захоплення, оверлеї та дивні ігри з 2009 року мають працювати з першого дня. Це очікування нереалістичне, але саме так ринок виставляє контракт.

Чому Arc вийшов сирим (і чому це не дивно)

Якщо ви керуєте продакшеном, ви знаєте патерн: нова платформа виходить з правильною «основною функціональністю», але крайові випадки й сумісність із «успадкованим» ПЗ — саме там дзвонить ваш пейджер. GPU — це храм крайових випадків.

Ранні проблеми репутації Arc були не просто «багами». Вони були структурними:

1) DX11 не «старий», це інша філософія

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

Архітектура та софт‑стек Arc орієнтувалися на сучасні явні API (DX12/Vulkan), де рушії самі оркеструють більше. Коли ви транслюєте DX11‑навантаження на сучасну парадигму, ви можете заплатити накладні витрати саме в невірному місці: у нитці CPU, що підгодовує GPU.

2) Resizable BAR на практиці не був опціональним

Arc надзвичайно вигравав від Resizable BAR (ReBAR). Без нього ви отримуєте більше перемапування PCIe і менш ефективні шаблони доступу до пам’яті між CPU і GPU. Багато ранніх звітів «Arc повільний» насправді були «Arc без ReBAR повільний», що зовсім інша діагностика.

3) Компіляція шейдерів і кеші пайплайнів — джерело «стутера»

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

4) Матриця тестування абсурдна

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

Парафразована ідея, приписана John Allspaw: Надійність будують, навчаючись на провалах у реальних умовах, а не на припущенні, що можна протестувати кожну можливість наперед.

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

Стек драйвера: хто за що відповідає і де ховаються баги

Якщо ви хочете дебажити Arc як SRE (а не як форумний тред), вам потрібна ментальна мапа стеку й типовіх режимів відмов.

Windows stack (спрощено)

WDDM kernel driver: планування, пейджинг пам’яті, таймаути (TDR), поведінка преземпції.
User mode driver: D3D11/D3D12/Vulkan реалізація; компілятор шейдерів; управління станом пайплайнів.
DirectX runtime і рушій гри: можуть ховати роботу в викликах драйвера; можуть викликати патологічні варіанти шейдерів.

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

Linux stack (спрощено)

Kernel: i915 (для Arc Alchemist): GEM/TTM управління пам’яттю, завантаження прошивок GuC/HuC, планування.
Mesa user space: ANV (Vulkan), iris (OpenGL), бекенди компілятора.
Translation layers: DXVK (DX9/10/11 через Vulkan), vkd3d-proton (DX12 через Vulkan).
Compositor: Wayland/Xorg; VRR; тут теж можуть з’являтися дивні ефекти фреймпейсу.

Де ховаються баги: невідповідності kernel/firmware, розбіжності версій Mesa, відсутня прошивка, затримки композитора та ігри, що розраховують на специфічну поведінку вендора.

Історія «виправлень публічно» для Arc часто виглядає так:

Користувачі повідомляють: «Гра X має жахливі 1% lows».
Вендор проводить триаж: це вузьке місце CPU, кеш шейдерів, накладні витрати DX11 чи TDR?
Виправлення з’являється в одному шарі (зміна кешу шейдерів у user mode).
З’являється регресія (інша гра потрапляє у новий шлях або інвалідовано кешування).
Виправлення шліфують, іноді через кілька шарів (драйвер + прошивка + профіль гри).

Факти й історичний контекст для розмови за вечерею

Факт 1: Intel випускав дискретні GPU задовго до Arc — згадайте i740 наприкінці 1990‑х — але Arc — це перший масштабний крок за десятиліття з сучасними ігровими очікуваннями.
Факт 2: Resizable BAR — це розширення поведінки адресації PCIe; «стара ідея, що стала практичною», оскільки платформи нарешті стандартизували її в споживчих платах.
Факт 3: DX11‑драйвери історично виконували багато «допоміжної» роботи, бо ігри на це розраховували; явні API (DX12/Vulkan) перенесли цю відповідальність на рушії, змінивши місце прояву проблем продуктивності.
Факт 4: Стутер від компіляції шейдерів існує з появою шейдерів; змінилися лише складність шейдерів і вибух пермутацій через сучасні рендер‑фічі.
Факт 5: Прошивка GPU оновлюють радше як прошивку NIC, аніж мікрокод CPU — часто, таргетовано і у зв’язці з драйвером.
Факт 6: DXVK і vkd3d-proton зробили «Windows‑ігри на Linux» життєздатними у великому масштабі і водночас стали випадковими інструментами діагностики якості драйвера, забезпечуючи альтернативні шляхи виконання.
Факт 7: Послідовність часу кадрів (1% lows) часто важливіша для відчуття плавності, ніж середній FPS; драйвери можуть покращити «відчуття», майже не змінюючи загальних бенчмарк‑чисел.
Факт 8: Багато GPU‑«проблем продуктивності» насправді пов’язані з плануванням CPU або синхронізацією — spinlock, mutex‑контенція та однопотокова відправка команд на рендер.

Жарт №1: Реліз драйвера GPU — це єдине місце, де «поліпшили стабільність» може означати «ми перестали її мати при 12 FPS».

Плейбук швидкої діагностики

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

Перше: класифікуйте відмову

Краш: падіння програми, скидання драйвера, чорний екран, TDR, зависання GPU.
Стутер: піки часу кадру, підгальмовування при повороті камери, періодичні паузи.
Низька продуктивність: постійно низький FPS, низька завантаженість GPU, CPU на піку.
Візуальні артефакти: артефакти, мерехтіння, відсутні текстури, некоректне освітлення.
Проблеми з енкодом/декодом: пропущені кадри, десинхрон, високе навантаження CPU під час енкоду.

Друге: вирішіть, платформа, драйвер чи навантаження

Перевірки платформи: ReBAR увімкнено, BIOS оновлено, швидкість слота PCIe правильна, живлення підключено, температури в нормі.
Санітарність драйвера: правильна версія, чиста інсталяція при потребі, відсутність конфліктних оверлеїв, відсутні застарілі runtime‑файли.
Шлях навантаження: DX11 vs DX12 vs Vulkan; спробуйте альтернативні рендер‑API; на Windows можна тестувати DXVK як контроль, якщо ви знаєте, що робите.

Третє: зберіть два таймлайни

Таймлайн часу кадру: перевірте, чи стутер корелює з компіляцією шейдерів або стрімінгом ресурсів.
Системний таймлайн: CPU, диск I/O, використання VRAM, такти GPU, пропускна спроможність PCIe.

Четверте: прийміть рішення швидко

Якщо ReBAR вимкнений: увімкніть його, повторіть тест. Якщо не можете — ввімкніть режим управління очікуваннями.
Якщо лише DX11 працює погано: пріоритетізуйте DX12/Vulkan де можливо; інакше тестуйте версії драйверів, відомі поліпшеннями DX11‑шляхів.
Якщо стутер збігається з новими локаціями/сценами: кеш шейдерів/пайплайнів; попередня компіляція; зменшіть налаштування, що підвищують кількість пермутацій (RT, тіні).
Якщо краші збігаються зі стрибками тактів: управління живленням; спробуйте консервативний ліміт потужності або відключіть агресивний буст.

Практичні завдання: команди, виводи, рішення

Це реальні «зробіть зараз» завдання. Кожне включає: команду, приклад виводу, що це означає і яке рішення прийняти. Міксуйте залежно від Windows vs Linux. Не запускайте випадкові скрипти з інтернету; запускайте таргетовані команди, що відповідають на питання.

Task 1 (Linux): Confirm the GPU and driver binding

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,/Kernel modules/p'
00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:56a0] (rev 05)
	Subsystem: Device [8086:1020]
	Kernel driver in use: i915
	Kernel modules: i915

Значення: Kernel використовує i915 для Intel GPU. Якщо ви бачите «vfio-pci» або відсутній драйвер — ви не тестуєте реальний шлях.

Рішення: Якщо це не i915, виправте прив’язку (або зупиніться — ваша проблема не «драйвери Arc», а присвоєння пристрою).

Task 2 (Linux): Check whether GuC/HuC firmware actually loaded

cr0x@server:~$ dmesg | grep -E "i915|GuC|HuC" | tail -n 12
[    2.143210] i915 0000:00:02.0: [drm] Finished loading DMC firmware i915/dmc_ver2_20.bin
[    2.198341] i915 0000:00:02.0: [drm] GuC firmware i915/guc_70.5.1.bin version 70.5.1
[    2.198379] i915 0000:00:02.0: [drm] HuC firmware i915/huc_7.10.3.bin version 7.10.3
[    2.207511] i915 0000:00:02.0: [drm] GuC submission enabled

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

Рішення: Якщо завантаження прошивки не вдалось — встановіть правильний пакет linux‑firmware для вашого дистрибутива й перезавантажтеся; не бігайте з бенчмарками на зламаній конфігурації.

Task 3 (Linux): Validate Vulkan driver and device exposure

cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275

Devices:
========
GPU0:
  apiVersion         = 1.3.275
  driverVersion      = 24.1.3
  vendorID           = 0x8086
  deviceID           = 0x56a0
  deviceName         = Intel(R) Arc(TM) A770 Graphics
  driverID           = DRIVER_ID_INTEL_OPEN_SOURCE_MESA
  deviceType         = PHYSICAL_DEVICE_TYPE_DISCRETE_GPU

Значення: Mesa ANV використовується, Arc видно як дискретний, і Vulkan працює.

Рішення: Якщо пристрій показаний як llvmpipe або програмний растризатор — зупиніться і виправте графічний стек. Якщо Vulkan працює, а DX11‑ігри підгальмовують — підозрюйте шар трансляції або кеш шейдерів.

Task 4 (Linux): Confirm OpenGL driver path (iris vs something wrong)

cr0x@server:~$ glxinfo -B | sed -n '1,25p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Intel (0x8086)
    Device: Intel(R) Arc(TM) A770 Graphics (DG2) (0x56a0)
    Version: 24.1.3
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Arc(TM) A770 Graphics (DG2)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 24.1.3

Значення: Апаратне прискорення активне, Mesa — рендерер.

Рішення: Якщо «direct rendering: No» або рендерер — «llvmpipe», ви дебажите не те. Виправте Mesa/DRM перед подальшою діагностикою.

Task 5 (Linux): Watch GPU frequency and power behavior under load

cr0x@server:~$ sudo intel_gpu_top -s 2000
intel-gpu-top: Intel DG2 (Gen12.7) @ /dev/dri/card0

      Render/3D    Blitter     Video     VideoEnhance     EU Array     Frequency
         78.22%      0.00%      2.13%          0.00%        76.90%       2050 MHz

Значення: Ви фактично насичуєте render; такти піднімаються. Якщо render низький, але FPS низький — ви прив’язані до CPU або заблоковані синхронізацією/накладними витратами драйвера.

Рішення: Низький render + низький FPS → розгляньте нитку CPU, накладні витрати DX11 або фреймпейсинг; високий render + низький FPS → GPU‑bound, зменшіть налаштування або перевірте терміки/потужність.

Task 6 (Linux): Check for GPU hangs/resets in the journal

cr0x@server:~$ sudo journalctl -k -b | grep -E "i915|GPU HANG|reset" | tail -n 20
Jan 21 10:14:22 server kernel: i915 0000:00:02.0: [drm] GPU HANG: ecode 12:1:85dffffb, in game.exe [4123]
Jan 21 10:14:23 server kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0
Jan 21 10:14:24 server kernel: i915 0000:00:02.0: [drm] game.exe[4123] context reset due to GPU hang

Значення: Справжнє зависання/скидання GPU, а не «гра впала». Це може бути драйвер, прошивка або нестабільне живлення/розгін.

Рішення: Відтворіть на стокових тактах, оновіть kernel/Mesa/firmware, і якщо це одна гра — спробуйте інший API‑шлях. Якщо зависання тривають у різних навантаженнях — розглядайте як проблему стабільності платформи.

Task 7 (Windows, via PowerShell): Confirm driver version and date

cr0x@server:~$ powershell -NoProfile -Command "Get-WmiObject Win32_VideoController | Select-Object Name,DriverVersion,DriverDate"
Name                                  DriverVersion       DriverDate
----                                  -------------       ----------
Intel(R) Arc(TM) A770 Graphics        31.0.101.5592       20250110

Значення: У вас є конкретна збірка драйвера; це ваша базова лінія для тестування регресій.

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

Task 8 (Windows): Detect TDR events (driver resets) in Event Viewer logs

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; ID=4101} -MaxEvents 5 | Format-Table TimeCreated,Message -AutoSize"
TimeCreated           Message
-----------           -------
1/21/2026 10:02:11    Display driver igdkmdn64 stopped responding and has successfully recovered.
1/20/2026 22:41:58    Display driver igdkmdn64 stopped responding and has successfully recovered.

Значення: Windows скинув драйвер. Це не «просто краш», це таймаут або зависання.

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

Task 9 (Windows): Verify Resizable BAR status

cr0x@server:~$ powershell -NoProfile -Command "Get-PnpDeviceProperty -InstanceId (Get-PnpDevice -Class Display | Where-Object {$_.FriendlyName -like '*Arc*'}).InstanceId -KeyName 'DEVPKEY_Device_BusReportedDeviceDesc' | Select-Object Data"
Data
----
PCI Express Root Complex

Значення: Це не підтверджує ReBAR напряму; Windows не дає простого one‑liner у всіх випадках. На практиці ReBAR перевіряють в BIOS або з інструментами вендора; на Linux можна інспектувати розміри BAR напряму.

Рішення: Якщо ви не впевнені, чи ReBAR увімкнений — припиніть бенчмарки і перевірте BIOS: Above 4G Decoding + ReBAR увімкнені, CSM вимкнено у багатьох випадках.

Task 10 (Linux): Confirm BAR sizing and whether ReBAR is active

cr0x@server:~$ sudo lspci -vv -s 00:02.0 | grep -E "Region 0|Resizable BAR|BAR 0" -A2
Region 0: Memory at 6000000000 (64-bit, prefetchable) [size=16G]
Capabilities: [200 v1] Resizable BAR
		Resizable BAR: current size: 16GB, supported: 256MB 512MB 1GB 2GB 4GB 8GB 16GB

Значення: BAR 0 змеплений на 16G, що зазвичай бажано для продуктивності Arc.

Рішення: Якщо current size малий (256MB/512MB) а supported більший — увімкніть ReBAR/Above 4G Decoding в BIOS і повторіть тест. Якщо ваша платформа не підтримує — прийміть, що ви не бачите призначеної поведінки карти.

Task 11 (Linux): Identify whether you’re CPU-bound in a game via perf sampling

cr0x@server:~$ sudo perf top -p $(pidof game.exe) -n 5
Samples: 1K of event 'cpu-clock', Event count (approx.): 250000000
Overhead  Shared Object        Symbol
  18.42%  game.exe             RenderThread::SubmitDraws
  12.10%  libvulkan_intel.so   anv_queue_submit
   9.77%  game.exe             ShaderManager::GetVariant
   6.31%  libc.so.6            pthread_mutex_lock

Значення: CPU render thread і відправка у чергу гарячі; є contention на mutex. Класичний випадок «накладні витрати драйвера/API зустрічаються з дизайном рушія».

Рішення: Спробуйте інший API (DX12/Vulkan), зменшіть налаштування з великою кількістю викликів відрисовки (дальність видимості, щільність натовпу) і переконайтесь, що версія драйвера вирішує відомі проблеми DX11, якщо це актуально.

Task 12 (Linux): Observe shader cache growth and whether it’s being invalidated

cr0x@server:~$ du -sh ~/.cache/mesa_shader_cache ~/.cache/radv_builtin_shaders 2>/dev/null
1.2G	/home/cr0x/.cache/mesa_shader_cache

Значення: Кеш шейдерів існує і має великий розмір; це нормально для сучасних тайтлів.

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

Task 13 (Linux): Check storage latency when stutter happens

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.02    0.00    5.21    6.11    0.00   70.66

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
nvme0n1         520.0  42000.0     0.0   0.00   8.40    80.77     70.0   9000.0   4.10   2.90   88.20

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

Рішення: Якщо %util підскакує до 100% під час стутерів — перемістіть гру на швидше сховище, переконайтесь, що немає пейджингу, і розгляньте опції попередньої компіляції. Не переслідуйте «драйвер GPU» коли диск тоне.

Task 14 (Windows): Validate GPU scheduling mode and HAGS state (where supported)

cr0x@server:~$ powershell -NoProfile -Command "reg query 'HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers' /v HwSchMode"
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\GraphicsDrivers
    HwSchMode    REG_DWORD    0x2

Значення: Hardware‑accelerated GPU scheduling увімкнено (значення може відрізнятись за версією Windows).

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

Task 15 (Linux): Confirm you’re not accidentally on a software compositor path

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Значення: Ви на Wayland. Це нормально, але якщо конкретна гра підгальмовує, тест на Xorg може відокремити взаємодію композитора.

Рішення: Якщо проблеми зникають на Xorg — знайдено баг композитора/VRR, а не «сирість» GPU.

Task 16 (Linux): Capture a minimal GPU debug report without guessing

cr0x@server:~$ sudo intel_gpu_top -J -s 500 -o /tmp/intel_gpu_top.json & sleep 5; head -n 5 /tmp/intel_gpu_top.json
{
  "period_us": 500000,
  "device": "Intel DG2",
  "timestamp": 39421.1201,

Значення: У вас є структурований запис використання інженерів GPU для кореляції з моментами стутера.

Рішення: Якщо використання низьке під час «лагу» — припиніть звинувачувати ядерний GPU. Дивіться на відправку з CPU, компіляцію шейдерів або I/O.

Три корпоративні міні‑історії з полів

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

Компанія впроваджувала робочі станції на базі Arc для команди, що займалася відеоенкодингом та легким 3D. Нічого екзотичного. Пілотна група виглядала добре: AV1 енкод працював швидко, десктопи були тихі, і ціна підходила. Закупівля посміхалась. Це мало бути червоним прапорцем.

На другому тижні почалися масові тікети: «UI зависає на 2–3 секунди», «екран чорніє, потім повертається», «дзвінки обриваються при демонстрації екрана». Команда трактувала це як проблему конференц‑застосунку. Перевстановлювали застосунок, оновлювали його, міняли вебкамеру. Класичне перекидання вини.

Неправильне припущення було тонким: вони вважали, що GPU поводитиметься «як просто швидший iGPU». У їхньому середовищі BIOS налаштування стандартизовані роками — CSM увімкнено для сумісності старого завантаження, ReBAR вимкнено бо «ніколи не було важливим», і оновлення BIOS вважалися ризикованими.

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

Виправлення не було магічним: оновлення BIOS, увімкнення Above 4G Decoding + ReBAR, стандартизація версії драйвера і перестаньте змішувати «те, що приніс Windows Update» з ручними інсталяціями. Продуктивність покращилась і чорні екрани зникли. Справжній урок: Arc чутливий до конфігурації платформи тим, чим старі GPU могли маскувати іншу поведінку.

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

Інша організація керувала невеликим рендер‑фардом для прев’ю активів. Вони не робили оффлайн‑рендери; запускали інтерактивні viewport‑рендери і кодували кліпи для рев’ю. Хтось помітив, що кеші шейдерів ростуть до гігабайтів у профілях користувачів і вирішив, що це «марнотратні записи на SSD».

Отже політика: чистити кеші шейдерів при виході з системи і перенаправляти кеші на мережеву домашню директорію, щоб профілі були «безстанні». На папері — охайна IT‑гігієна. У понеділок усі скаржились, що перші 10 хвилин сесії були стутерні, вентилятори ревли і іноді застосунки падали під час «завантаження».

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

Arc звинуватили, бо він був новою змінною, але реґресія була самостійно спричинена. Відновлення локальних кешів, виключення їх з «прибирання» і дозволити їм зберігатись усунуло стутер. Вони впорядкували зростання занятності диска через квоти і чистку лише сирітських кешів, а не гарячих.

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

Лабораторія тестування ігор (не студія; сумісність і QA на аутсорсі) мала валідувати оновлення драйвера по десяткам тайтлів. Вони звикли до вендорської мінливості, тому робили це як rollout операційно, а не як вихідні хобі.

Вони підтримували gold image для кожного класу апаратного забезпечення: фіксована версія BIOS, фіксований статус ReBAR, фіксований build Windows, фіксований драйвер. Кожна зміна — це changerequest з коротким описом причини. Це було агресивно нудно. Але саме так вони уникали привидів.

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

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

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

Цей розділ навмисно конкретний. Якщо ви впізнаєте симптом, ви повинні змогти зробити щось конкретне протягом години.

1) Низький FPS лише в DX11

Симптом: DX12/Vulkan тайтли працюють добре; DX11 показує низьку завантаженість GPU та погані 1% lows.
Корінна причина: CPU‑bound submit викликів і накладні витрати драйвера DX11; інколи шляхи трансляції менш оптимізовані ніж у конкурентів.
Виправлення: Віддавайте перевагу режиму рендеру DX12/Vulkan, якщо доступний. Якщо ні — тестуйте новіші драйвери, відомі поліпшеннями DX11. Зменшіть налаштування, що дають багато draw‑calls (дальність, натовп). Переконайтесь, що ReBAR увімкнено.

2) Стутер, що ніколи не зникає, навіть після кількох прогонів

Симптом: Та сама сцена підгальмовує щоразу; кеш шейдерів не допомагає.
Корінна причина: Кеш шейдерів не зберігається (права, sandboxing, скрипти очищення) або кеш пайплайнів інвалідовується змінами драйвера/конфігурації.
Виправлення: Перевірте, що директорії кешу доступні для запису і зберігаються. Припиніть інструменти «прибирання», що видаляють кеші. Після оновлення драйвера очікуйте одноразової перекомпіляції; якщо вона повторюється — у вас проблема з персистентністю кешу.

3) Рандомні чорні екрани з відновленням

Симптом: Екран чорніє на секунду, потім повертається; Event ID 4101 в Windows або скиди GPU в Linux журналах.
Корінна причина: TDR / відновлення через зависання GPU, спричинене довгими компіляціями шейдерів, нестабільним бустом/живленням або багом драйвера, що вражає конкретне навантаження.
Виправлення: Поверніться до стокових тактів. Спробуйте іншу версію драйвера. Зменшіть піки потужності (обмежте FPS, трохи знизьте ліміт потужності). Якщо відтворюється в одній грі — змініть API‑шлях і відправляйте логі.

4) «GPU на 99%», але відчуття повільності

Симптом: Оверлеї показують максимальне завантаження GPU, але фреймпейсинг жахливий.
Корінна причина: Оманливі метрики завантаження під час затримок, або ви насичуєте конкретний інженер (копіювання/відео), а рендер заблокований на синхронізації.
Виправлення: Використовуйте інструменти рівня інженерів (intel_gpu_top) або графіки часу кадру. Корелюйте з CPU та I/O. Не налаштовуйтеся на одне число «GPU %».

5) Продуктивність падає після «прибирання» або профайлеру

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

6) Енкод використовує забагато CPU, хоча є Arc

Симптом: OBS/FFmpeg завантажують CPU; відео‑движки GPU показують низьке використання.
Корінна причина: Невірний енкодер обрано (програмний x264 замість QSV/oneVPL), непідтримуваний кодек‑шлях або несумісність драйвера/рантайма.
Виправлення: Виберіть апаратний енкодер Intel явно. Підтвердіть за допомогою інструментів, що відео‑движки використовуються. Оновлюйте драйвер і медіа‑рантайми як комплект.

7) Linux‑ігри: «Vulkan працює, але Proton падає»

Симптом: Натівні Vulkan‑застосунки працюють; деякі Proton‑титли падають/зависають.
Корінна причина: vkd3d-proton/DXVK взаємодіють зі специфічною версією драйвера/Mesa; відсутні 32‑бітні Vulkan‑бібліотеки; застаріла Mesa у дистро LTS.
Виправлення: Встановіть 32‑бітні Vulkan‑драйвери. Оновіть Mesa (або використайте відомо‑добрий стек). Тримайте kernel + Mesa + firmware у відповідності.

Жарт №2: «Це, мабуть, драйвер» — GPU‑еквівалент «це DNS» — часто правильно, але це не привід пропускати базові перевірки.

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

Чек‑лист A: Встановіть надійну базову лінію (зробіть це раз для машини)

Оновіть BIOS до стабільного релізу вендора; увімкніть Above 4G Decoding і ReBAR.
Підтвердіть, що слот PCIe працює на очікуваній ширині/швидкості (не бенчмаркуйте помилково в x4 слоті).
Встановіть одну відому‑добру версію драйвера; зафіксуйте її (скріншот або текстовий лог).
Вимкніть непотрібні оверлеї/інжектори для базового тестування (інструменти захоплення, RGB‑оверлеї, надлишкові оверлеї продуктивності).
Виберіть 3 навантаження: один DX11, один DX12/Vulkan, один тест енкод/декод.
Запишіть: середній FPS, 1% lows і чи з’являється стутер після другого прогону (теплий кеш).

Чек‑лист B: Якщо підозрюєте регресію

Змініть одну змінну: лише версію драйвера. Не змінюйте Windows build, не змінюйте BIOS, не патчіть гру і т.д.
Повторіть тест у тій самій сцені/бенчмарку двічі (холодний кеш, потім теплий кеш).
Перевірте TDR/скиди GPU (Event ID 4101 у Windows / GPU HANG у Linux journal).
Якщо регресія підтверджена — збережіть обидва інсталятори драйверів і задокументуйте: тайтл, API режим, роздільність, налаштування, кроки відтворення.

Чек‑лист C: Якщо ви ганяєте стутер (фреймпейсинг)

Визначте, чи стутер одноразовий (лише перший прогін) або постійний.
Спостерігайте латентність сховища під час вікон стутера; виключіть I/O‑конфлікт.
Підтвердіть персистентність кешу шейдерів (не видаляйте його; не переміщайте на мережеве сховище).
Обмежте FPS, щоб зменшити стрибки та транзиєнти живлення; повторіть тест.
Здійсніть A/B тест — змініть API (DX11 → DX12/Vulkan).
Якщо стутер постійний і відтворюваний — збирайте логи і надсилайте з точною версією драйвера.

Чек‑лист D: Linux‑специфічна «не марнуйте час» вирівнювання

Kernel, Mesa і linux‑firmware мають бути відносно сучасні й сумісні.
Підтвердіть, що ANV/iris використовуються (не llvmpipe).
Підтвердіть завантаження GuC/HuC (dmesg).
Віддавайте перевагу Wayland або Xorg залежно від відтворюваної поведінки; не сперечайтесь абстрактно.

Питання й відповіді

Q1: Чому Arc так сильно покращився з часом у порівнянні з деякими іншими запусками GPU?

Тому що Arc прийшов з великою «новою поверхнею стеку» одночасно: нова дискретна платформа, сучасні медіа‑фічі і сильний фокус на явних API. Найшвидші покращення прийшли з оптимізації гарячих шляхів (особливо трансляція/накладні витрати DX11), поведінки кешування шейдерів і специфічних підходів для ігор. Це програмні проблеми — а програмне забезпечення може рухатися швидше за кремній.

Q2: Чи Resizable BAR обов’язковий?

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

Q3: Чому DX11 поводиться гірше за DX12/Vulkan на Arc у багатьох випадках?

DX11 заохочує драйвер робити більше неявної роботи. Це створює накладні витрати CPU і синхронізації, що проявляються у низькій завантаженості GPU та поганих 1% lows. DX12/Vulkan перекладають більшу відповідальність на рушій, що може краще відповідати сильним сторонам Arc, якщо гра добре реалізована.

Q4: Який найшвидший спосіб відрізнити вузьке місце CPU від GPU?

Зменшіть роздільність і графічні налаштування різко. Якщо FPS майже не змінюється — ймовірно CPU‑bound або накладні витрати драйвера. Якщо FPS підскакує — ви GPU‑bound. Підтвердіть за допомогою інструментів рівня інженерів (intel_gpu_top на Linux) і графіків часу кадру.

Q5: Чи завжди треба встановлювати найновіший драйвер?

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

Q6: Чи «оптимізації під ігри» — це поганий хак?

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

Q7: На Linux що важить більше: kernel чи Mesa?

Обидва, але для щоденної продуктивності та сумісності ігор Mesa часто рухає голку швидше (Vulkan/OpenGL драйвер і компілятор). Для стабільності, планування та інтеграції прошивки важливі kernel і linux‑firmware. Розглядайте їх як одиницю.

Q8: Чому я бачу стутер після кожного оновлення драйвера?

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

Q9: Чи доробленість медіа‑движка Arc відповідає доробленості ігрового драйвера?

Не ідеально. Медіа‑пайплайни (енкод/декод) — інші шляхи коду і можуть бути стабільні навіть коли деякі ігри не працюють. Проте вони ділять частини стеку: управління живленням, пам’ять і інтеграція з ОС. Якщо бачите скиди GPU під час енкоду — розглядайте як проблему системної стабільності, а не «тільки OBS».

Q10: Що включити в репорт про баг драйвера Arc, щоб він був дієвим?

Версія драйвера, збірка ОС, версія BIOS, статус ReBAR, точна версія гри, точний режим API (DX11/DX12/Vulkan), кроки відтворення і чи відбувається це під другим прогоном (теплий кеш). Додавайте логи (TDR події / рядки GPU HANG у kernel) і коротке відео, якщо це візуальна корупція.

Висновок: наступні кроки, що справді зменшать біль

Якщо взяти одне: припиніть трактувати «драйвери Arc» як однорідну річ. Це стек, і кожен шар має свої режими відмов. Більшість витраченого часу — від дебагу без попередньої перевірки бази: статус ReBAR, правильна прив’язка драйвера, прошивка завантажена і відтворюваний тестовий кейс.

Зробіть наступне:

Зафіксуйте базу: BIOS + ReBAR + одна версія драйвера. Запишіть це.
Класифікуйте біль: краш vs стутер vs низький FPS vs візуальні баги. Різні інструменти — різні виправлення.
Запустіть плейбук швидкої діагностики: платформа → санітарність драйвера → шлях навантаження. Не пропускайте кроки.
Змінюйте одну змінну одночасно: так ви знайдете регресії і уникнете забобонів.
Тримайте кеші локально й персистентно: ваше майбутнє «я» дякуватиме щоразу, коли сцена швидко звантажиться.

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

Схожі статті

3dfx: Злет і падіння ігрової легенди Відкриті vs закриті екосистеми: чи є насправді рух проти CUDA? NVIDIA: від RIVA до GeForce — як зародилась імперія CUDA: як NVIDIA прив’язала цілу галузь Оновлення драйвера вбило мій FPS: як правильно діагностувати