ATI до AMD: інша школа графічної інженерії

Дві школи графічної інженерії (і чому це важливо для операцій)

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

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

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

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

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

Жарт, бо ми це заслужили: драйвери GPU схожі на прогнози погоди — достатньо точні, щоб планувати, але ніколи не ставте на них реліз.

Конкретні історичні факти, які можна використовувати

Ось короткі, операційно релевантні факти й контекстні моменти про ATI до AMD. Жодних музейних екскурсій — лише ті шматки, що пояснюють реальну поведінку в полях.

1. Лінійка Rage передувала Radeon, а ранній імпульс Radeon частково був про очищення враження «ми тепер вміємо 3D, обіцяємо» від пізніх акселераторів 90-х.
2. ATI придбала ArtX (2000), команду з глибоким досвідом консольної графіки (помітно пов’язану з GPU Nintendo GameCube). Цей вплив проявився в подальшій архітектурній впевненості та дорожніх картах фіч.
3. Radeon 9700 Pro (R300, 2002) став переломним: дизайн класу DX9, який змусив ринок рухатися вперед і, що важливо для операцій, значно ускладнив драйвери разом із програмованим шейдингом.
4. Catalyst став єдиним брендом драйверів на початку 2000-х. Уніфіковане пакування звучить нудно, доки вам не доведеться відтворити баг на трьох образах ОС і п’яти «випадкових» OEM-форках драйверів.
5. ATI активно пройшла перехід AGP→PCIe. Мости та взаємодії з чіпсетом мали значення; «це той самий GPU» часто було брехнею на рівні системи.
6. Ера X1000 (середина 2000-х) орієнтувалася на Shader Model 3.0 і складне планування. Чудово, коли працювало; важче дебагувати, коли драйвер помилявся.
7. Історія ATI на Linux тривалий час була хиткішою, ніж на Windows, з пропрієтарними драйверами, що часто існували ніби в окремому всесвіті від еволюції DRM ядра.
8. ATI була придбана AMD у 2006 році. Перед-AMD роки відображають пріоритети ATI: швидкість додавання фіч і широка орієнтація на споживача, іноді за рахунок чистих меж абстракцій.

Це не тривіальність. Вони пояснюють, чому ви й досі бачите певні класи проблем на застарілих Radeon: некоректна поведінка AGP aperture, хиткі крайові випадки OpenGL ICD і невідповідності пакування драйверів, що відчуваються як дрейф конфігурації — бо це і є дрейф конфігурації, але з GPU.

Що ATI будувала до AMD: вибори архітектури, які проявляються у відмовах

Програмованість змінила профіль інцидентів

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

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

Епоха ATI до AMD перебувала саме в цьому переході. Деякі дизайни були попереду свого часу. Деякі просто випереджали свої драйвери.

AGP і міф «просто шина»

Системи з AGP були пасткою надійності, замаскованою під приріст продуктивності. GPU міг DMA-вати текстури з системної пам’яті, і чіпсет із BIOS мали свої погляди на те, як це має працювати. Якщо ви діагностуєте стару робочу станцію або промислову систему з застарілим Radeon, не сприймайте конфігурацію шини як дрібницю. Це перший підозрюваний.

Мости, варіанти та операційний податок SKU

ATI мусила поставляти продукцію на ринок, що вимагав абсурдної кількості SKU: різні об’єми пам’яті, типи пам’яті, планування плат і інтерфейси шини. Мости при переході з AGP на PCIe (і пізніше їх очищення) створили ситуації, коли дві «однакові моделі» поводились по-різному під навантаженням. З точки зору SRE, це класична проблема «петів, що видають себе за скотину»: ви створюєте образ машини і припускаєте однорідність; GPU-плата каже інакше.

Якість зображення проти передбачуваності

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

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

Історія драйверів: Catalyst, ICD та вартість сумісності

Catalyst як об’єкт операцій, не просто завантаження

Catalyst був не просто драйвером. Це був пакет: частини в режимі ядра, шари в режимі користувача, панелі керування та застосункові евристики. Перед-AMD ATI мусила підтримувати хаотичну екосистему Windows (різні версії DirectX, сервіс-паки, OEM-кастомізації) і Linux-екосистему, яка ще визначала відповідальності DRM/KMS.

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

OpenGL ICD і «працює на моїй машині»

На Windows OpenGL часто працює через Installable Client Driver (ICD). Якщо ви ніколи не налагоджували невідповідність OpenGL ICD, уявіть собі динамічне зв’язування плюс налаштування реєстру плюс застосункові відкатники, а потім додайте панель керування вендора, яка може перевизначити дефолти. Коли це ламається, може відкотитися до програмної реалізації від Microsoft або до суміснісного шима — означаючи, що ваш GPU «в порядку», а продуктивність впала.

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

Таймаути, скидання та захист ОС

Сучасний Windows має Timeout Detection and Recovery (TDR). У перед-AMD епосі ATI екосистема ще конвергувала до робастних механізмів відновлення. Довге завдання на GPU могло заморозити UI і захопити всю коробку. Навіть сьогодні ви бачите спадщину: ОС скидає драйвер, щоб зберегти інтерактивність, що добре для десктопів і погано для безголових обчислень або довгих рендерів, якщо ви цього не налаштували.

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

Цитата, бо це й досі найкраща рамка для цієї роботи: Надія — не стратегія. — Генерал Гордон Р. Салліван

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

Нижче — реальні задачі, які я би виконував при діагностиці проблем з GPU класу ATI/Radeon на Linux-системах (і кілька загально корисних перевірок хоста). Кожна містить команду, приклад виводу, що це означає, і яке рішення ви приймаєте.

1) Визначити GPU і який драйвер зв’язано

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+4p'
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RV770 [Radeon HD 4870] [1002:9440]
	Subsystem: Sapphire Technology Limited Device [174b:e610]
	Kernel driver in use: radeon
	Kernel modules: radeon, amdgpu

Що означає вивід: У вас ATI GPU (ID вендора 1002). У ядрі наразі використовується драйвер radeon, але amdgpu також доступний як модуль.

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

2) Підтвердити ширину і швидкість PCIe лінку (класичний прихований вузький пляш)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1
LnkSta: Speed 2.5GT/s (downgraded), Width x4 (downgraded)

Що означає вивід: Карта може працювати на PCIe Gen2 x16, але наразі працює на Gen1 x4. Це не «трохи повільніше». Це самозавданий інцидент.

Рішення: Перевірте налаштування BIOS, посадку карти, riser-адаптери, розгалуження ліній і вибір слотів материнської плати. Якщо це флот, аудитуйте всі вузли на предмет зниження лінку.

3) Перевірити логи ядра на предмет скидань/зависань GPU

cr0x@server:~$ sudo dmesg -T | egrep -i 'radeon|amdgpu|gpu reset|ring|timeout' | tail -n 20
[Mon Jan 13 09:41:22 2026] radeon 0000:01:00.0: GPU lockup (current fence id 0x00000000000a3f1b last fence id 0x00000000000a3f1c on ring 0)
[Mon Jan 13 09:41:22 2026] radeon 0000:01:00.0: ring 0 stalled for more than 10240msec
[Mon Jan 13 09:41:22 2026] radeon 0000:01:00.0: GPU softreset: 0x00000000
[Mon Jan 13 09:41:23 2026] radeon 0000:01:00.0: GPU reset succeeded, trying to resume

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

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

4) Перевірити, який DRM-драйвер завантажено і з якими параметрами

cr0x@server:~$ cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-6.5.0 root=UUID=... ro quiet splash radeon.modeset=1

Що означає вивід: Параметри завантаження ядра включають директиву modeset для radeon.

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

5) Підтвердити пристрої DRM і права доступу (поширена пастка для headless/VDI)

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

Що означає вивід: Ноди пристроїв існують; render-нод належить групі render. Ваш сервісний користувач може не бути в render або video.

Рішення: Додайте сервісний акаунт до відповідної групи або налаштуйте правила udev. Якщо ви «виправите» це через chmod 666, ви створюєте інцидент безпеки, щоб вирішити інцидент продуктивності.

6) Подивитися, чи Mesa використовує апаратне прискорення

cr0x@server:~$ glxinfo -B | egrep 'OpenGL vendor|OpenGL renderer|OpenGL version'
OpenGL vendor string: Mesa
OpenGL renderer string: AMD RV770 (DRM 2.50.0 / 6.5.0, LLVM 15.0.7)
OpenGL version string: 3.3 (Core Profile) Mesa 23.2.1

Що означає вивід: Mesa керує GPU через DRM; ви не відкотились до програмної візуалізації llvmpipe.

Рішення: Якщо бачите llvmpipe або softpipe, припиніть оптимізацію додатку. Спочатку виправте вибір драйвера і стек GL.

7) Негайно виявити програмне рендерення (швидка перевірка)

cr0x@server:~$ glxinfo -B | grep -i renderer
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)

Що означає вивід: Ви рендерите на CPU. Ваша «проблема продуктивності GPU» фактично — «GPU не використовується».

Рішення: Перевірте конфіг Xorg, драйвери Mesa, проброс пристрою в контейнері або відсутню прошивку. Не проводьте бенчмарки, поки це не виправите.

8) Перевірити видимість Vulkan (якщо застосовно)

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

Devices:
========
GPU0:
	apiVersion         = 1.2.170
	driverVersion      = 0.0.1
	vendorID           = 0x1002
	deviceName         = AMD RADV RV770
	deviceType         = DISCRETE_GPU

Що означає вивід: Vulkan бачить пристрій і присутній стек RADV (якщо GPU/клас підтримується).

Рішення: Якщо Vulkan-пристрої відсутні, але OpenGL працює, можливо відсутні пакунки Vulkan ICD або апарат просто не підтримується. Вибирайте API відповідно.

9) Перевірити лог Xorg на предмет відкатів драйвера та невідповідностей ABI

cr0x@server:~$ egrep -i 'radeon|amdgpu|failed|fallback|ABI|glamor' /var/log/Xorg.0.log | tail -n 20
[     9.231] (II) Loading /usr/lib/xorg/modules/drivers/radeon_drv.so
[     9.245] (II) RADEON(0): glamor X acceleration enabled on RV770
[     9.246] (WW) RADEON(0): Option "AccelMethod" is not used
[     9.312] (EE) AIGLX: reverting to software rendering

Що означає вивід: DDX завантажено, glamor увімкнено, але AIGLX відкотився до програмного рендерингу. Це напівприскорена конфігурація — часто гірша за повністю апаратну або повністю програмну.

Рішення: Виправте шлях GL/AIGLX (Mesa, права, відповідність libGL). Не задовольняйтесь тим, що «воно стартує».

10) Виміряти навантаження CPU vs очікування GPU (швидкий верхній поділ)

cr0x@server:~$ mpstat -P ALL 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(32 CPU)

09:52:18 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:52:19 AM  all   22.41  0.00  6.13    0.12 0.00  0.51   0.00   0.00   0.00  70.83

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

Рішення: Перейдіть до лічильників/логів з боку GPU (скидання, частоти, VRAM) і профілювання на рівні додатка.

11) Перевірити використання VRAM і GTT на Linux (коли доступно)

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/amdgpu_vram_mm 2>/dev/null || echo "no amdgpu vram mm stats"
no amdgpu vram mm stats

Що означає вивід: Ймовірно, ви не на amdgpu або вузол не експонує ці статистики. Для застарілого radeon структура debugfs відрізняється.

Рішення: Не витрачайте час на пошук лічильників, яких немає. Перейдіть до доступної телеметрії: dmesg скидання, FPS додатку та апаратні сенсори.

12) Зчитати дані сенсорів GPU (терміни/потужність) через lm-sensors

cr0x@server:~$ sensors
radeon-pci-0100
Adapter: PCI adapter
temp1:        +92.0°C  (crit = +105.0°C)

Що означає вивід: 92°C досить гаряче, щоб викликати тротлінг або нестабільність на деяких платах, залежно від охолодження і здоров’я VRM.

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

13) Підтвердити завантажені модулі ядра і можливі конфлікти

cr0x@server:~$ lsmod | egrep 'radeon|amdgpu|drm' | head
radeon               1515520  3
drm_ttm_helper         16384  1 radeon
ttm                   106496  2 radeon,drm_ttm_helper
drm_kms_helper        249856  1 radeon
drm                  622592  6 drm_kms_helper,radeon,drm_ttm_helper,ttm

Що означає вивід: Стек узгоджений: radeon з DRM-хелперами. Якщо ви бачите одночасно radeon і amdgpu, прив’язані до того самого пристрою, у вас проблема конфігурації.

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

14) Перевірити помилки пам’яті і загальне здоров’я PCIe (не ігноруйте AER)

cr0x@server:~$ sudo journalctl -k | egrep -i 'AER|pcie|error|radeon' | tail -n 20
Jan 13 09:41:22 server kernel: pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0
Jan 13 09:41:22 server kernel: pcieport 0000:00:1c.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 13 09:41:22 server kernel: pcieport 0000:00:1c.0:   device [8086:2942] error status/mask=00000001/00002000

Що означає вивід: Скориговані помилки PCIe. «Скориговано» не означає «безпечно»; це означає, що ви споживаєте запас і можете бачити тротлінг або повторні передачі.

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

15) Підтвердити тиск файлової системи і поведінку свопу (GPU-проблеми, що є проблемами хоста)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            62Gi        58Gi       1.2Gi       1.0Gi       2.8Gi       2.6Gi
Swap:          8.0Gi       7.9Gi       120Mi

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

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

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

Це план, який я б передав інженеру на виклику о 02:00, коли вузол з Radeon «повільний» або «крешиться». Він упорядкований так, щоб швидко відсіяти найчастотніші причини.

Перше: підтвердити, що шлях GPU реальний (не плацебо)

1. Чи використовує додаток апаратне прискорення? Перевірте glxinfo -B renderer. Якщо бачите llvmpipe, зупиніться і виправте це.
2. Чи прив’язано правильний драйвер? lspci -nnk. Якщо пристрій на неправильному драйвері ядра, ви дебагуєте не ту систему.
3. Чи права блокують render-нод? ls -l /dev/dri. Headless-сервіси часто запускаються без доступу до render.

Друге: перевірити скидання, зависання і проблеми шини

1. Шукайте lockup/скидання GPU в dmesg / journalctl -k. Скидання означають нестабільність або баг драйвера під навантаженням.
2. Перевірте стан PCIe лінку за допомогою lspci -vv. Зниження лінку може виглядати як «таємна регресія».
3. Проскануйте на предмет PCIe AER помилок. Скориговані помилки — ранні попередження, а не хороші новини.

Третє: ізолювати теплові, пам’ятні та дрейф конфігурації

1. Терміни: sensors. Якщо гаряче — підозрюйте це в першу чергу.
2. Тиск хоста по пам’яті: free -h, плюс використання свопу. Пейджинг створює хибні вузькі місця GPU.
3. Дрейф версій: підтвердіть версії ядра/Mesa/драйвера по вузлах. Якщо лише один хост регресував — це дрейф конфігурації, а не «рандом».

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

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

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

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

Нові вузли були на 20–30% повільніші і іноді втрачали кадри у інтерактивному прев’ю. Люди звинувачували новий образ ОС, потім Mesa, потім оновлення додатку. Першою реальною підказкою став інженер, який припинив гадати і запустив lspci -vv на старих і нових вузлах. Нові вузли домовлялися про ширину PCIe вниз до x4 під навантаженням.

Що сталося — не магія. Нова партія плат мала трохи іншу розкладку і характеристики живлення. У конкретному шасі з конкретним riser-ом запас цілісності сигналу був відсутній. PCIe лінк навчався працювати стабільно, але не в тому сенсі, який вам потрібен; він залишався «стабільним», поки не погіршував пропускну здатність.

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

Виправлення було нудним: перемістити плати в інші слоти/різні riser-и, закріпити швидкість лінку в BIOS для тестування валідації і оновити чекліст кваліфікації апаратури, включивши перевірку ширини лінку під тривалим навантаженням. Довгострокове виправлення — культурне: ніколи не приймайте «один і той самий SKU» замість вимірювання.

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

Інша організація запускала VDI-сесії з прискоренням GPU для дизайнерів. У них була суміш GPU і сувора політика: вичавити максимум щільності на хост. Хтось виявив, що зниження налаштувань якості в панелі керування драйвера (і увімкнення набору «performance» перемикачів) підвищує бенчмарк-числа. Зміни розгорнули широко, бо це виглядало як безкоштовна додаткова ємність.

За тиждень черга інцидентів наповнилася періодичними артефактами: тремтячі краї, іноді відсутні текстури і рідкісні — але жорсткі — креші додатків під час обертання вьюпорту. Нічого не було достатньо стабільним для відтворення. Кожного разу, коли користувач ділився екраном, проблема зникала. Класика.

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

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

Висновок: оптимізації, що змінюють кодові шляхи, — це продакшн-зміни. Ставтеся до них як до змін коду з рев’ю, канарками і відкатом, навіть якщо вони в GUI.

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

Мала інженерна організація підтримувала музей застарілих систем для виробничої лінії. Деякі станції залежали від старих OpenGL-аплікацій, валідація яких проводилась роками тому на ATI-залізі. Обладнання було дороге для рекваліфікації, тому вони запускали те, що мали, обережно.

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

Одного дня станція почала жорстко фризити під час зміни зміни — найгірший можливий час. Вони не почали з перевстановлення ОС або оновлення драйверів. Вони замінили GPU на відомо-робочий запасний, підтвердили стабільність, а потім винесли несправний GPU на стенд. На стенді тепловий режим був на межі, і під навантаженням він почав видавати періодичні скориговані помилки PCIe.

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

Саме у цьому — непомітне серце інженерії надійності: зменшити кількість невідомих, поки залишок не стане очевидним.

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

Це режими відмов, які повторюються в парках Radeon епохи ATI і в змішаних графічних середовищах. Кожен запис каже, як це виглядає, що насправді відбувається і що робити.

1) Симптом: «GPU повільний після оновлення»

Корінь: Відкат драйвера до програмного рендерингу (llvmpipe/softpipe), часто через відсутні пакунки Mesa, неправильний libGL або прогалини в пробросі пристрою в контейнері.

Виправлення: Перевірте за допомогою glxinfo -B. Переконайтеся, що встановлені правильні DRI-драйвери Mesa, правильні права на /dev/dri/renderD* і узгоджений вибір libGL по системі.

2) Симптом: «Випадкові статтери кожні кілька секунд»

Корінь: Тиск пам’яті хоста і свопінг, або конкуренція CPU, що постачає GPU.

Виправлення: Перевірте free -h і завантаження хоста. Зменшіть конкурентність, додайте RAM або переробіть навантаження. Налаштування GPU цього не вирішить.

3) Симптом: «Іноді чорний екран, потім відновлення»

Корінь: Скидання GPU через зависання — терміни, нестабільне БЖ, помилки VRAM або баг драйвера тригерний певним шейдером.

Виправлення: Перевірте dmesg на логи про зависання/скидання. Перегляньте температури (sensors), приберіть розгони, валідуйте напруги БЖ і протестуйте відому стабільну комбінацію драйвер/ядро.

4) Симптом: «Продуктивність відрізняється між “ідентичними” машинами»

Корінь: PCIe лінк домовився вниз (x16 → x4) або працює на меншій швидкості через слот, riser, BIOS або цілісність сигналу.

Виправлення: lspci -vv для LnkSta. Пересядьте плату, перемістіть слоти, оновіть BIOS, протестуйте з пониженою швидкістю і стандартизуйте апаратні шляхи.

5) Симптом: «Ламається лише один додаток; все інше в порядку»

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

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

6) Симптом: «Артефакти з’являються після увімкнення “performance” налаштувань»

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

Виправлення: Відкотіться до відомих добрих дефолтів. Поступово вводьте зміни по одній з репрезентативним навантаженням. Ставтеся до змін у панелі керування як до змін коду.

7) Симптом: «Headless job не має доступу до GPU»

Корінь: Сервісний користувач не має доступу до /dev/dri/renderD* або інструменти засновані на Xorg/Wayland, що робить сценарій крихким.

Виправлення: Додайте користувача до груп render/video; перевірте ноди пристроїв; використовуйте render-нод для обчислень/офскрін там, де можливо; уникайте крихких залежностей від X.

8) Симптом: «Переривчасті зависання під великим навантаженням; логи показують PCIe помилки»

Корінь: Проблеми цілісності сигналу: riser, пил, окислення, слабкість слоту материнської плати або несправність карти.

Виправлення: Пересядьте, змініть слот, приберіть riser-и, покращіть охолодження, і якщо AER триває — замініть підозріле залізо. Скориговані помилки — не функція продуктивності.

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

Чекліст A: Безпечне підняття застарілого вузла ATI/Radeon

1. Зробіть інвентар точної моделі GPU і ID підсистеми (lspci -nn). Запишіть. Не довіряйте маркетинговим назвам.
2. Обирайте драйвер свідомо (radeon vs amdgpu де застосовно). Задокументуйте вибір і зафіксуйте версії.
3. Перевірте здоров’я шини: стан PCIe LnkSta і логи AER.
4. Підтвердьте шлях рендера: переконайтеся, що glxinfo -B показує апаратний рендерер, а не llvmpipe.
5. Встановіть теплову базу: зафіксуйте температури в просте і під навантаженням (sensors).
6. Запустіть тривалий тест навантаження достатній, щоб викликати теплове насичення (не тільки 30-секундний бенчмарк).
7. Збережіть відомо-робочі версії: ядро, Mesa, Xorg/Wayland, пакунки прошивки і будь-які пропрієтарні компоненти.
8. Створіть план відкату: снапшот образу або фіксація пакетів. Пропрацюйте відкат один раз.

Чекліст B: Коли вузол регресував після оновлення

1. Підтвердіть, що це не програмне рендерення (glxinfo -B).
2. Перевірте dmesg/journal на скидання (journalctl -k).
3. Порівняйте стан PCIe лінку (lspci -vv) з робочим вузлом.
4. Порівняйте версії пакунків (стек драйверів і Mesa). Не дивіться в очі — зробіть diff фактичних версій.
5. Перевірте тиск пам’яті хоста (free -h, використання свопу).
6. Відкочуйте по одному виміру: спочатку драйвер, потім ядро, потім Mesa/X стек. Уникайте хаотичних «помірок».
7. Запишіть тригерне навантаження, що показує регресію. Якщо не відтворюється — не можете виправити.

Чекліст C: Зміни драйвера без створення ворогів

1. Запустіть канарку на одному вузлі з реальними навантаженнями, а не лише бенчмарками.
2. Міряйте три речі: продуктивність, стабільність (скидання/зависання) і коректність (артефакти/питання точності).
3. Зберігайте набір відомо-робочих артефактів: скриншоти або детерміністичні рендери для порівняння.
4. Плануйте вікно відкату і переконайтеся, що можете швидко повернутися без перевстановлення образу вручну.
5. Не змішуйте зміни: уникайте одночасного оновлення ядра + Mesa + налаштувань драйвера.

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

1) Чи була ATI «гіршою» за NVIDIA до AMD?

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

2) Чому на застарілих системах ATI проявляється дивна варіабельність між машинами?

Бо GPU — лише одна змінна. Чіпсет, BIOS, тренування PCIe, riser-и, живлення і охолодження можуть змінювати поведінку. Також були поширені OEM-форки драйверів; дрейф версій справжній.

3) Яка найшвидша перевірка, коли продуктивність падає?

Переконайтесь, що ви не на програмному рендерингу. На Linux — glxinfo -B і перевірка рядка renderer. Якщо пише llvmpipe, ваш GPU не вузьке місце — CPU рендерить.

4) Чому ширина PCIe лінку так сильно важлива?

Бо вона фільтрує подачу команд, завантаження ресурсів і зчитування назад. GPU, якому бракує пропуску через зниження лінку, поводиться як повільніший GPU, і це не виправиш налаштуваннями. Це вирішується апаратурою/BIOS-дисципліною.

5) Чи завжди скидання GPU — це баг драйвера?

Ні. Часто це апаратний запас: терміни, нестабільне живлення, старіюча VRAM або цілісність сигналу. Починайте з логів, потім перевіряйте терміни і здоров’я PCIe. Якщо скидання відтворюються на різних образах ОС — ймовірно апаратне.

6) Чому екосистема драйверів ATI здавалася складною?

Бо вона управляла кількома API, версіями ОС і поведінкою конкретних застосунків в час, коли програмовані конвеєри швидко еволюціонували. Складність не була опцією; це була ціна участі в гонці фіч.

7) Для застарілих вузлів Radeon: оновлювати драйвери чи фіксувати їх назавжди?

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

8) Чому «performance» перемикачі іноді викликають артефакти?

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

9) Який надійний спосіб відокремити GPU-bound від CPU-bound проблем?

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

10) Чи має це значення тепер, коли AMD володіє ATI?

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

Наступні кроки, які можна зробити цього тижня

• Аудитуйте свій парк на предмет програмного рендерингу: випадкові перевірки рядків renderer glxinfo -B на репрезентативних вузлах.
• Запустіть аудит здоров’я PCIe лінку: зафіксуйте LnkSta width/speed на всіх вузлах з GPU і відмітьте зниження.
• Встановіть «відомо-робочу» базу драйверів для кожного покоління апаратури і зафіксуйте її. Зробіть відкат дешевим.
• Збирайте докази скидань: централізуйте логи ядра і налаштуйте алерти на шаблони lockup/reset.
• Стандартизуйте охолодження і чистоту: GPU при 92°C — це баг надійності, а не вайб.
• Закріпіть контроль змін для налаштувань драйвера: перемикачі в GUI — це продакшн-зміни. Ставтесь до них відповідно.

ATI до AMD — нагадування, що графічна інженерія — не лише про пропускну здатність; це про те, скільки непередбачуваності ви готові витримати. Якщо хочете менше інцидентів — зменшуйте варіативність: фіксуйте версії, перевіряйте здоров’я шини, стежте за термінами і ніколи не припускайте, що GPU робить те, що ви вважаєте.