Інтегрована графіка: від «лише для офісу» до дійсно корисної

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

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

Що змінилося: чому iGPU перестали бути «лише для офісу»

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

Ключова зміна: сучасні iGPU — це не просто кілька шейдерів на кристалі CPU. Це повноцінні графічні підсистеми з виділеними блоками
для кодування/декодування (медіа-движок), трубами дисплея і дедалі більш сильними обчислювальними шляхами. Вони все ще ділять пропускну здатність пам’яті з CPU,
що й є основним компромісом. Але для великого спектра реальних робочих навантажень iGPU тепер — найкращий «безкоштовний» прискорювач, який у вас вже є.

Також дискретні GPU стали дорогими, енерговитратними і іноді недоступними саме в момент, коли всі вирішили, що віддалені зустрічі мають бути
завжди у 1080p/4K. Це підштовхнуло виробників інвестувати в надійність медіа та дисплеїв на iGPU, бо кількість звернень в службу підтримки ставала критичною.

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

• Лінійка інтегрованої графіки Intel має десятиліття історії, але сучасна ера «практичного iGPU» прискорилася, коли GPU перемістили на пакет CPU, а потім на кристал, зменшивши затримки і споживання енергії.
• Quick Sync Video (Intel) ввів ідею, що «слабкий» GPU може бути чудовим відеотранскодером, бо медіа-блок — спеціалізоване залізо, а не загальні шейдери.
• Стратегія APU від AMD трактувала інтегровану графіку як фічу першого класу: CPU + GPU — це продукт, а не компроміс.
• Експерименти з eDRAM (як у Intel «Crystalwell») коротко намагалися вирішити проблему пропускної здатності спільної пам’яті за допомогою кeшу на підкладці. Працювало, коштувало грошей і не стало універсальним.
• Стандарти дисплеїв вимагали компетентності: керувати високими частотами оновлення, HDR і кількома 4K панелями — це менш про «геймінг», більше про надійні дисплейні труби і підрахунок пропускної здатності.
• Vulkan і сучасні драйвери зменшили пастку «один вендор — одне API». Коли API стає послідовним, якість драйверів вирішує все.
• Прийняття Wayland підштовхнуло Linux-десктоп до більш прямих шляхів рендерингу, і iGPU виграли, бо вони найпоширеніші в Linux-ноутбуках і корпоративних флотах.
• Навантаження браузерів вибухнули: сучасні вебзастосунки рутинно навантажують GPU для композитингу, декодування відео та WebGL. Ваш «офісний» робочий процес тихо став GPU-орієнтованим.
• AI-інференс на периферії знову штовхає iGPU в роль обчислювача — іноді через вендорні рантайми, іноді через загальні API — бо не кожен пристрій отримає дискретний прискорювач.

Як iGPU насправді працюють (і де вони програють)

Спільна пам’ять: угода, яку ви підписали (навіть якщо не хотіли)

Визначальна риса iGPU — спільна пам’ять. GPU не має власного VRAM; він використовує системну оперативну пам’ять. Це дає дешеву,
енергоефективну конструкцію і уникає копіювання даних між CPU та GPU в деяких випадках. Податок — це пропускна здатність і конкуренція за неї.

Один корисний ментальний образ: iGPU — компетентний GPU, прив’язаний до підсистеми пам’яті, яка в першу чергу проєктувалась для CPU.
Коли ви насичуєте пропускну здатність пам’яті (або збільшуєте затримку через режими енергозбереження), iGPU не «трохи сповільнюється».
Він падає з обриву, бо рендеринг і медіа-пайплайни потребують великої пропускної здатності й часто працюють у реальному часі.

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

Медіа-движки: чому iGPU б’ють вище своєї ваги

Для відео секретна зброя iGPU — виділені апаратні блоки. Декодування/кодування — це не просто «GPU compute». Це спеціалізоване силіконове залізо, яке може
працювати з форматами на кшталт H.264/HEVC/VP9/AV1 (залежно від покоління) з низьким навантаженням CPU і передбачуваною продуктивністю.

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

Дисплейні труби і математика пропускної здатності

Багатомоніторні налаштування — місце, де міфи про iGPU швидко руйнуються. Керувати трьома дисплеями не завжди складно; складніше — керувати трьома високороздільними,
високочастотними панелями з HDR і глибоким кольором. Обмеження — це суміш:

• Фізичні виходи (версії HDMI/DP, alt-mode по USB-C, чіпи в доках)
• Ліміти дисплейного движка (труби, частоти)
• Пропускна здатність пам’яті (фреймбуфери й композитинг)

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

Драйвери: ваш реальний GPU — це програмний стек

iGPU живуть і вмирають від зрілості драйверів. Тут Linux значно покращився — але й залишилися гострі краї:
версії ядра, бінарні прошивки, версії Mesa, поведінка композитора та налаштування енергоменеджменту.

Одна перефразована ідея від James Hamilton (Amazon), яку фахівці з експлуатації вчать на власному досвіді: «надійність приходить від проєктування систем, які терпіти відмови, а не від удавання, що компоненти не ламаються» (перефразована).
Ставтеся до драйверів GPU так само. Припускайте, що ви зрештою натрапите на регресію. Побудуйте діагностику й шляхи відкату.

Навантаження, де iGPU справді корисні

1) Корпоративні кінцеві точки та VDI-клієнти

RDP, Teams, Zoom, браузерні IDE, дашборди — ці навантаження активують декодування відео, композитинг і іноді прискорене GPU-рендеринг.
Сучасний iGPU може зробити тонкий клієнт «чутливим», а не «ледь справляється».

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

2) Медія-сервери та пайплайни транскоду

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

3) Легкий геймінг та інді-проєкти

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

Жарт №1: iGPU не запустить ультра-настройки в 4K, але й ваш проектор для переговорних кімнат цього не підтягне — тому очікування вже відрегульовані.

4) Розробницькі робочі процеси з GPU-прискоренням

Browser WebGL демо, робота з UI, попередній перегляд рендерів, навіть деякі шляхи ML-інференсу можуть виграти. iGPU не універсальний прискорювач,
але часто достатній для «потрібно швидко локально», не блокуючи дискретний GPU або віддалений сервер.

5) Безпечна, нудна надійність у змішаних флотах

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

Швидкий план діагностики: знайти вузьке місце за хвилини

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

Перше: підтвердьте, який GPU активний і який драйвер використовується

• Якщо у вас ноутбук з гібридною графікою, підтвердьте, що ви справді на iGPU чи dGPU (або на софтовому рендерері).
• Шукайте ознаки «llvmpipe» або «Software Rasterizer» — вони перетворюють кожну операцію UI на навантаження CPU.

Друге: перевірте навантаження CPU і пам’яті в момент «гальм»

• Якщо CPU завантажений, GPU може бути ок, а вузьке місце — у декоді, композитингу або в процесі, що втік.
• Якщо пам’ять підточується або пропускна здатність конкурує, продуктивність iGPU руйнується.

Третє: перевірте частоту GPU і завантаження (специфічно для iGPU)

• Енергоменеджмент може фіксувати частоти на низькому рівні.
• Теплові обмеження можуть тихо тротлити iGPU (і CPU разом).

Четверте: підтвердьте, що апаратне декодування/кодування відео справді використовується

• «Відеодзвінок деренчить» часто означає софтове декодування, а не «поганий інтернет».
• «Транскодинг повільний» часто означає, що медіа-движок не задіяний або кодек не підтримується апаратно.

П’яте: перевірте узгодження дисплея і шлях композитора

• Доки і адаптери часто брешуть.
• Wayland проти Xorg впливають на розриви, затримки та стабільність.

Практичні завдання з командами: діагностика, рішення, рух далі

Мета команд — не збирати цікавинки. Мета — прийняти рішення. Кожне завдання нижче містить (1) команду, (2) що означає вивід,
і (3) що робити далі.

Завдання 1: Визначити GPU(и) і kernel driver

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
00:02.0 VGA compatible controller [0300]: Intel Corporation Iris Xe Graphics [8086:9a49]
	Subsystem: Lenovo Device [17aa:5087]
	Kernel driver in use: i915
	Kernel modules: i915

Значення: У вас Intel iGPU з драйвером i915, що і є бажаним для сучасної інтегрованої графіки Intel.

Рішення: Якщо бачили «Kernel driver in use: nouveau» для NVIDIA dGPU або «vfio-pci» несподівано, ви вирішуєте іншу проблему.
Якщо драйвер відсутній або встановлено загальний framebuffer-драйвер, виправте це перед зміною налаштувань продуктивності.

Завдання 2: Виявити софтовий рендеринг (мовчазний вбивця продуктивності)

cr0x@server:~$ glxinfo -B | egrep "OpenGL renderer|OpenGL vendor|OpenGL version"
OpenGL vendor string: Intel
OpenGL renderer string: Mesa Intel(R) Iris Xe Graphics (TGL GT2)
OpenGL version string: 4.6 (Core Profile) Mesa 24.0.3

Значення: Апаратне прискорення активне через Mesa; ви не на llvmpipe.

Рішення: Якщо рендерер каже «llvmpipe» або «Software Rasterizer», зупиніться. Виправте драйвери/Mesa, або ви оптимізуєте яму, малюючи смуги на дорозі.

Завдання 3: Підтвердити сесію Wayland чи Xorg (впливає на розриви/затримку/інструменти)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Значення: Ви на Wayland. Деякі старі діагностичні інструменти працюють інакше; характеристики розривів можуть покращитися.

Рішення: Якщо ви переслідуєте розриви на Xorg, можливо, варто протестувати Wayland. Якщо старий додаток ламається на Wayland, тимчасово поверніться на Xorg для сумісності.

Завдання 4: Перевірити повідомлення ядра на зависання GPU, ресети або проблеми з прошивкою

cr0x@server:~$ dmesg -T | egrep -i "i915|drm|gpu hang|reset|firmware" | tail -n 20
[Mon Jan  8 10:12:14 2026] i915 0000:00:02.0: [drm] GuC firmware i915/tgl_guc_70.bin version 70.36.0
[Mon Jan  8 10:12:14 2026] i915 0000:00:02.0: [drm] HuC firmware i915/tgl_huc_7.9.3.bin version 7.9.3
[Mon Jan  8 10:12:15 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0

Значення: Прошивка завантажилась коректно; зависань або ресетів не показано.

Рішення: Якщо ви бачите повторювані «GPU HANG» або «reset», ставте стабільність на перше місце: оновіть ядро/Mesa/прошивку або відкотіться до робочого стека.

Завдання 5: Інспектувати частоти iGPU і троттлінг (Intel)

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/i915_frequency_info | sed -n '1,25p'
Current freq: 300 MHz
Requested freq: 300 MHz
Max freq: 1350 MHz
Min freq: 300 MHz
RP0 (max non-boost) freq: 1250 MHz
RP1 (efficient) freq: 900 MHz
RPn (min) freq: 300 MHz
Throttle reasons: 0x00000000

Значення: GPU зараз ідлить на мінімумі; у цей момент причин троттлінгу не виявлено.

Рішення: Запустіть ту саму перевірку під час піку затримок. Якщо «Throttle reasons» зміниться або Max freq впаде, розбирайтесь із теплом/енергопараметрами замість рахунку шейдерів.

Завдання 6: Спостерігати реальне завантаження GPU-движків (Intel)

cr0x@server:~$ sudo intel_gpu_top -s 1000
intel-gpu-top: Intel TigerLake (Gen12) @ /dev/dri/card0

      IMC reads:   215 MiB/s          IMC writes:    74 MiB/s

   ENG (%)      RCS     CCS     BCS     VCS     VECS
              12.34    0.00    0.00   65.20    4.10

Значення: VCS (движок відео декоду/енкод) завантажений. RCS (рендер) помірний. Виглядає як відеонавантаження, а не 3D-рендеринг.

Рішення: Якщо VCS 0% при великому CPU під час відтворення відео, апаратне декодування ймовірно не використовується — змініть налаштування плеєра, підтвердьте підтримку кодека або виправте VA-API.

Завдання 7: Перевірити можливості VA-API (Intel/AMD iGPU на Linux)

cr0x@server:~$ vainfo
libva info: VA-API version 1.20.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_20
VAProfileH264Main            : VAEntrypointVLD
VAProfileHEVCMain            : VAEntrypointVLD
VAProfileVP9Profile0         : VAEntrypointVLD
VAProfileAV1Profile0         : VAEntrypointVLD

Значення: VA-API працює і драйвер оголошує підтримку декодування для цих кодеків.

Рішення: Якщо vainfo падає або показує обмежені профілі, апаратне декодування/кодування буде ненадійним. Виправте стек VA перед тим, як звинувачувати «інтегровану графіку».

Завдання 8: Підтвердити апаратне декодування в плеєрі (приклад mpv)

cr0x@server:~$ mpv --hwdec=vaapi --msg-level=vd=debug sample_4k_av1.mkv 2>&1 | egrep -i "Using hardware decoding|vaapi|hwdec" | head
[vd] Using hardware decoding (vaapi).
[vd] VO: [gpu] 3840x2160 vaapi[nv12]

Значення: Плеєр використовує VA-API апаратне декодування і виводить дружній до апаратури формат.

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

Завдання 9: Тест апаратного кодування через FFmpeg (Quick Sync / VA-API приклад)

cr0x@server:~$ ffmpeg -hide_banner -vaapi_device /dev/dri/renderD128 -i input.mp4 \
-vf 'format=nv12,hwupload' -c:v h264_vaapi -b:v 5M -c:a copy output_vaapi.mp4
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> h264 (h264_vaapi))
Press [q] to stop, [?] for help
frame=  600 fps=190 q=-0.0 Lsize=   22000kB time=00:00:20.00 bitrate=9011.1kbits/s speed=6.34x

Значення: Апаратне кодування активне; швидкість вказує, що медіа-движок виконує роботу.

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

Завдання 10: Підтвердити права на render node (поширена проблема для контейнерів/демонів)

cr0x@server:~$ ls -l /dev/dri
total 0
drwxr-xr-x 2 root root        80 Jan  8 10:12 by-path
crw-rw----+ 1 root video 226,   0 Jan  8 10:12 card0
crw-rw----+ 1 root render 226, 128 Jan  8 10:12 renderD128

Значення: Доступ обмежений групами video та render.

Рішення: Якщо сервісний акаунт або користувач контейнера не може отримати доступ до /dev/dri/renderD128, апаратне прискорення мовчки впаде. Додайте користувача до відповідної групи або пропишіть пристрій у контейнер з потрібними правами.

Завдання 11: Визначити, чи машина з single-channel пам’яттю (тихий вбивця iGPU)

cr0x@server:~$ sudo dmidecode -t memory | egrep -i "Locator:|Size:|Speed:|Configured Memory Speed:" | head -n 20
	Locator: DIMM_A
	Size: 16 GB
	Speed: 3200 MT/s
	Configured Memory Speed: 3200 MT/s
	Locator: DIMM_B
	Size: No Module Installed

Значення: Встановлено одну планку. Це зазвичай означає одно-канальну пропускну здатність пам’яті.

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

Завдання 12: Перевірити масштабування частоти CPU і ознаки теплового троттлінгу

cr0x@server:~$ sudo turbostat --Summary --interval 1 --quiet | head -n 8
CPU Avg_MHz  Busy%  Bzy_MHz  TSC_MHz  PkgTmp  PkgWatt
-   1780     62.5   2848     1896     92      28.4

Значення: Температура пакета висока. На багатьох ноутбуках CPU і iGPU ділять один тепловий бюджет.

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

Завдання 13: Швидко перевірити використання композитора й процесів GPU

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head -n 10
 4123 chrome       128.4  6.2
 2311 gnome-shell   42.1  2.1
 1987 Xwayland      18.3  0.9
 5210 ffmpeg        12.7  0.3

Значення: Браузер — основний споживач CPU; композитор також вагомий.

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

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

cr0x@server:~$ xrandr --verbose | egrep -A2 " connected|Link Status|Bandwidth|Max bpc" | head -n 30
DP-1 connected primary 3840x2160+0+0 (0x48) normal (normal left inverted right x axis y axis) 597mm x 336mm
	Max bpc: 12
	Link Status: Good
HDMI-1 connected 1920x1080+3840+0 (0x4e) normal (normal left inverted right x axis y axis) 510mm x 287mm
	Link Status: Good

Значення: Дисплеї підключені з хорошим статусом лінку. «Max bpc» підказує про можливу глибину кольору.

Рішення: Якщо Link Status «Bad» або режими обмежені (наприклад, 4K застрягло на 30Hz), підозрюйте кабель/договір з доком. Виправте фізичний рівень спочатку; жоден драйвер не перетанцює дешевий адаптер.

Завдання 15: Помітити ресети або зависання GPU в журналі (systemd)

cr0x@server:~$ journalctl -k -b | egrep -i "i915|amdgpu|drm|hang|reset|timeout" | tail -n 20
Jan 08 10:22:41 server kernel: i915 0000:00:02.0: [drm] *ERROR* GPU HANG: ecode 9:1:85dffffb, in gnome-shell [2311]
Jan 08 10:22:42 server kernel: i915 0000:00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0

Значення: Маєте реальне зависання/ресет GPU. Це не «продуктивність»; це інцидент надійності.

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

Завдання 16: Перевірити, чи встановлені правильні Mesa/Vulkan драйвери

cr0x@server:~$ vulkaninfo --summary | egrep "GPU id|deviceName|driverName" | head -n 10
GPU id : 0 (Intel(R) Iris(R) Xe Graphics)
deviceName     = Intel(R) Iris(R) Xe Graphics
driverName     = Intel open-source Mesa driver

Значення: Vulkan функціональний і використовує Mesa-драйвер.

Рішення: Якщо vulkaninfo падає, деякі додатки впадуть у повільні шляхи або аварійно закриються. Виправте пакети/драйвер-стек перед діагностикою на рівні додатків.

Три корпоративні міні-історії (анонімізовано, але болісно реальні)

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

Середня компанія оновила ноутбуки для відділу, що жив у відеодзвінках і дашбордах. Закупівля оптимізувала під ціну і час автономної роботи,
і специфікація виглядала прийнятно: сучасний CPU, багато RAM, інтегрована графіка «підтримує 4 дисплеї». Док-станції взялися із попереднього флоту.

Тиждень один: повільний інцидент. Не повний збій — гірше. Люди не могли довіряти машинам. Зовнішні монітори мерехтіли, курсор підгальмовував
під час дзвінків, презентації іноді падали до 30Hz. Хелпдеск лаяв Teams. Teams лаяв Wi‑Fi. Wi‑Fi лякав «місцем користувача».

Неправильне припущення було тонким: «Підтримує 4 дисплеї» трактували як «підтримує наш док з 2×4K@60 плюс панель ноутбука».
Насправді внутрішній чіп дока DisplayLink і узгоджені швидкості лінку означали, що iGPU іноді виконував додаткову роботу, іноді через USB-компресію,
іноді через нижчий ніж очікували режим DisplayPort. Під навантаженням система жонглювала декодом відео, браузерним композитингом і дисплейним пайплайном,
що вже був близький до своєї пропускної межі.

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

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

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

Інша організація запустила невеликий медіа-пайплайн для внутрішніх навчальних відео. Хтось помітив, що апаратне кодування на iGPU швидке
і суттєво знижує навантаження CPU. Правильно. Потім вирішили — як інженери — масштабувати.

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

Фіаско прийшло від того, що ніхто не графанув: пропускна здатність пам’яті й I/O. Кожне завдання вимагало декодування, фільтрації (скейлінг, субтитри, ватермарк),
а потім кодування. Фільтри не всі були оффлоадені; деякі працювали на CPU, деякі спричиняли зайві завантаження/вивантаження GPU, і спільна шина стала
заторованою перетином. Затримки стрибали, задачі джиттерили, і зрештою пайплайн став непередбачуваним — швидким в середньому, ненадійним у хвостах.

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

Виправили, обмеживши конкурентність на хості згідно емпіричного тестування, відокремивши «фільтр-важкі» роботи на вузли, орієнтовані на CPU,
і відстеживши розподіли кінцевих латентностей замість середнього fps. Апаратне кодування залишилось; overcommit не пройшов.

Урок: прискорення iGPU реальне, але не відміняє фізику. Спільна пам’ять означає, що ваш вузький профіль може бути «усе поміж CPU і GPU».

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

Глобальна компанія мала поступовий розгорток Linux-десктопів зі змішаними Intel і AMD інтегрованими графіками. Їх вже палили регресії стеку графіки — чорні екрани,
зламаний suspend, аварії композитора. Тому вони зробили те, що звучить нецікаво у світі «move fast»:
зафіксували відомо-робочі комбінації ядро + Mesa + прошивка для кожного покоління заліза і використовували поетапні кільця.

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

Оскільки вони розгортали по кільцях, проблема вдарила по ранньому кільцю першою. Вони мали телеметрію про GPU-hang з підписів journalctl,
і просту політику: будь-який GPU reset — стоп-відкат для того кільця. Заморозили реліз, відкотили кільце і відкрили таргетований баг з відтворюваним кейсом.
Решта компанії цього ніколи не побачила.

«Рятунок» не був технічною геніальністю. Це контроль змін і спостережуваність.

Жарт №2: Найнадійніша функція GPU все ще — кнопка відкату, тому я наполягаю тестувати її перед кожним розгортанням.

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

1) Симптом: «Відтворення відео ривками; CPU високий»

Корінна причина: Апаратне декодування не задіяне (неправильний драйвер, невірно налаштований VA-API, кодек/профіль не підтримується).

Виправлення: Запустіть vainfo, підтвердіть підтримку кодека; протестуйте відтворення з mpv --hwdec=vaapi; оновіть Mesa/прошивку. Якщо кодек не підтримується апаратно — транскодуйте джерело або прийміть навантаження на CPU.

2) Симптом: «Все повільно після оновлення; вентилятори крутяться постійно»

Корінна причина: Фолбек на софтовий рендеринг (llvmpipe) або драйвер GPU не завантажено.

Виправлення: Перевірте glxinfo -B; підтвердіть драйвер ядра через lspci -nnk; переконайтеся, що встановлені правильні пакети Mesa; відкотіть до відомо-робочого ядра/Mesa, якщо регресія.

3) Симптом: «Зовнішній монітор застряг на 30Hz»

Корінна причина: Док/кабель узгодили нижчу швидкість лінку або обмеження версії HDMI; іноді 10-бітна глибина кольору змушує знизити пропускну здатність.

Виправлення: Перевірте через xrandr --verbose; поміняйте на сертифікований кабель; використовуйте DisplayPort де можливо; зменшіть глибину кольору або частоту, якщо потрібно; віддавайте перевагу докам, валідаваним з моделлю.

4) Симптом: «Випадковий чорний екран або падіння композитора під навантаженням»

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

Виправлення: Перевірте journalctl -k -b; протестуйте інший композитор/сесію (Wayland vs Xorg); оновіть або відкотіть ядро/Mesa/прошивку як набір; збережіть випадок відтворення.

5) Симптом: «Транскодинг повільніший, ніж очікували, навіть з апаратним кодеком»

Корінна причина: Фільтри змушують софтовий шлях або спричиняють зайві копії; диск I/O або пропускна здатність пам’яті стають обмежувачем.

Виправлення: Пропрофілюйте пайплайн: запустіть кодування без фільтрів; потім додавайте фільтри по одному. Обмежте конкурентність. Переконайтеся, що ви використовуєте render node (/dev/dri/renderD128) а не display node у headless-налаштуваннях.

6) Симптом: «UI підгальмовує коли працює фонова задача»

Корінна причина: Спільний енергетичний/тепловий бюджет і конкуренція за пам’ять між CPU-навантаженням та iGPU/композитором.

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

7) Симптом: «Багатомонітор працює, але переміщення вікон рве або лагає»

Корінна причина: Налаштування композитора Xorg, невідповідні частоти оновлення або опції VRR/tearfree не узгоджені з iGPU/дисплеєм.

Виправлення: Уніфікуйте частоти оновлення між дисплеями; протестуйте Wayland; налаштуйте tearfree-опції для драйвера; уникайте змішування адаптерів, що змушують різні часові режими.

8) Симптом: «Контейнеризований додаток не може використовувати апаратне прискорення»

Корінна причина: Відсутній passthrough пристрою або права на /dev/dri/renderD128; відсутні libva/Mesa всередині контейнера.

Виправлення: Пропишіть render-пристрій у контейнер, додайте групові права і переконайтеся, що користувацькі бібліотеки відповідають драйверу хосту.

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

Чекліст A: Купівля/специфікація машини, де iGPU має бути «достатнім»

1. Почніть з виходів, а не шейдерів. Порахуйте потрібні дисплеї, роздільності, частоти оновлення, потреби HDR і доки.
2. Вимагайте dual-channel пам’яті у стандартній збірці. Якщо закупівля не гарантує цього, очікуйте варіативності продуктивності.
3. Підтвердіть апаратну підтримку кодеків для вашого реального медіа (H.264/HEVC/VP9/AV1, 10-біт там, де потрібно).
4. Закріпіть відомо-робочий програмний стек (ядро/Mesa/прошивка) для кожного покоління заліза.
5. Тестуйте з реальним доком і моніторами. «Підтримує X» на папері не покриває проблем узгодження.

Чекліст B: Розгортання апаратного прискорення iGPU у продукції (медіа, VDI або кінцеві точки)

1. Спершу базелайн. Виміряйте навантаження CPU, пропуски кадрів і затримки до вмикання апаратного прискорення.
2. Увімкніть декодування/кодування явно у стеку додатка; не сподівайтесь, що авто-детект працює всюди.
3. Слідкуйте за мовчазним фолбеком. Додайте health checks, що виявляють софтове декодування/кодування і сигналізують.
4. Контролюйте конкурентність. Розглядайте пропускну здатність пам’яті як обмежений ресурс; навантажуйте тестами з реалістичною паралеллю.
5. Розгортайте поетапно. Регресії GPU відбуваються часто, тому «всі одразу» — гра в рулетку з зарплатою.

Чекліст C: План усунення несправностей (коли хтось каже «графіка повільна»)

1. Підтвердьте активний драйвер і рендерер: lspci -nnk, glxinfo -B.
2. Перевірте тип сесії: echo $XDG_SESSION_TYPE.
3. Пошукайте зависання/ресети: journalctl -k -b.
4. Перевірте CPU/тепловий стан: turbostat, ps.
5. Перевірте GPU-движки: intel_gpu_top (Intel) в момент симптому.
6. Перевірте апаратне відео: vainfo, потім відтворення/кодування з відомим тестом.
7. Перевірте дисплеї: xrandr --verbose, поміняйте кабель/док якщо узгодження підозрiле.
8. Лише потім думайте про тюнінг-флаги або заміну заліза.

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

1) Чи достатня інтегрована графіка для більшості офісних задач нині?

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

2) Який найбільший фактор, що обмежує продуктивність iGPU?

Пропускна здатність пам’яті і конкуренція. iGPU ділять ОЗП з CPU. Single-channel пам’ять, повільні модулі або важкі CPU-навантаження можуть відчути GPU на голодному пайку.

3) Чи допомагає швидша пам’ять інтегрованій графіці?

Часто так. Але «правильно встановлений dual-channel» зазвичай дає більше, ніж гонитва за останніми MT/s.
Якщо у вас одна планка, виправте це перед покупкою екзотичних комплектів пам’яті.

4) Чому іноді відтворення відео навантажує CPU на сучасній машині?

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

5) Що обрати — Wayland чи Xorg для десктопа на iGPU?

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

6) Чи можна використовувати прискорення iGPU в контейнерах?

Так, але потрібно пробросити /dev/dri/renderD128 (або еквівалент) і забезпечити права та наявність користувацьких бібліотек.
Більшість випадків «не працює» — просто через відсутній доступ до пристрою або невідповідність libva/Mesa.

7) Коли все ще потрібен дискретний GPU?

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

8) Чому продуктивність так відрізняється між «схожими» ноутбуками?

Охолодження, ліміти потужності, конфігурація пам’яті і налаштування прошивки. Два пристрої з тим самим iGPU можуть поводитися по-різному, якщо один має
single-channel пам’ять або суворіший тепловий пакет.

9) Чи такі важливі доки?

Так. Доки можуть змінити спосіб подачі дисплеїв (рідний DP alt-mode vs USB graphics), обмежити швидкості лінку і ввести компресію.
Багато «проблем GPU» насправді — «проблеми узгодження дока».

10) Яка розумна політика оновлень для флоту з iGPU?

Розгортайте по кільцях, закріплюйте відомо-робочі набори ядро/Mesa/прошивка для кожного покоління заліза і розглядайте GPU-hang/reset як тригер для відкату.
Це нудно, але працює.

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

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

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

1. Уніфікуйте конфігурацію пам’яті (dual-channel) на кожному пристрої, який очікується для багатомоніторної або медіа-інтенсивної роботи.
2. Впровадьте звичку діагностики: тримайте lspci, glxinfo, vainfo і підписування зависань через journalctl в інструментарії першого реагування.
3. Перевіряйте доки і кабелі так само ретельно, як ядра: тестуйте їх з реальною матрицею моніторів, яку розгортаєте.
4. Увімкніть апаратні медіа-шляхи свідомо і відслідковуйте фолбеки — бо «auto» перше і тихо ламається.
5. Розгортайте поетапно оновлення графічного стеку. Єдине гірше за регресію GPU — розгорнути її повсюдно до обіду.