3dfx: Злет і падіння ігрової легенди

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

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

Що 3dfx зробили правильно: простий продукт, який влучив у реальне вузьке місце

ПК середини 1990-х були дивною твариною: багато амбіцій у CPU, багато амбіцій у програмному забезпеченні, а графічні конвеєри трималися на тимчасових рішеннях.
Розробники хотіли мапування текстур, z-буферизації, фільтрації та вищих роздільностей, не перетворюючи кожен кадр на слайд-шоу.
Тим часом споживачі хотіли те, що завжди хочуть: «Зробіть так, щоб виглядало як на скриншоті на коробці».

Ранній геній 3dfx не був містичним. Це була операційна майстерність. Вони звузили постановку задачі.
Спочатку вони не намагалися бути повноцінним контролером дисплея й картою для 2D робочого столу. Вони поставили прискорювач, який зробив «гарячий шлях» швидким:
растеризація трикутників, застосування текстур, достатньо плавне відтворення, щоб люди перестали думати про рендерер і почали думати про гру.

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

Дев’ять фактів, що пояснюють епоху (без ностальгічного туману)

• Перший хіт 3dfx, Voodoo Graphics (1996), був насамперед 3D-додатком; його часто під’єднували через пас-через кабель до окремої 2D-карти.
• Glide був пропрієтарним API 3dfx; багато ігор для Windows мали Glide-рендерери, бо це було практично й передбачувано на обладнанні Voodoo.
• Voodoo2 (1998) популяризував споживче масштабування з кількома платами через SLI («scan-line interleave»), розбиваючи альтернативні горизонтальні лінії між двома картами.
• «3D-акселерація» стала категорією покупок швидше, ніж багато OEM-виробників могли переробити системи; додаткові карти були найкоротшим шляхом на ринок.
• RIVA TNT та пізніше GeForce 256 від NVIDIA агресивно рухалися до інтегрованих 2D/3D рішень і швидшого циклу випусків, зменшуючи привабливість окремого 3D-прискорювача.
• 3dfx придбали STB Systems (1998), виробника плат, перейшовши від моделі постачальника чипів до створення та продажу фірмових плат самим.
• Якість драйверів і швидкість випуску стали конкурентним виміром, а не післядумовою—особливо коли ігри на Windows вийшли з хобі в масовий ринок.
• Voodoo3 був сильний у деяких реальних робочих навантаженнях, але відставав, коли швидко змінювалися списки особливостей (зокрема очікування 32-бітного кольору і маркетинг T&L).
• Наприкінці 2000 року NVIDIA придбала активи 3dfx, завершивши існування 3dfx як самостійного конкурента і закривши визначну главу історії ПК-графіки.

Як Voodoo фактично працював: архітектурні рішення, що мали значення

Ранній успіх Voodoo був не лише «швидкий чип». Це був тип продуктового обмеження, який цінують SRE:
вузька, чітко означена служба, що робить одну річ надзвичайно добре.
Плата Voodoo Graphics фокусувалася на 3D-конвеєрі, тоді як 2D залишали на існуючу графічну карту.
Звучить незручно зараз, але в той час це зменшило складність і скоротило час виходу на ринок.

Дизайн з пас-через кабелем означав, що ви не замінювали весь відеопідсистему; ви її доповнювали.
Це знизило опір у споживачів і OEM. Це також обмежило сферу 3dfx — недооцінена перевага.
Менше функцій для реалізації означає менше режимів відмов. Це не гламурно, але це відвантажується.

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

Потім світ змінився. «Межа служби» (акселеротор лише для 3D) стала тягарем, коли інтеграція покращилася.
Система захотіла один пристрій для 2D + 3D, більш щільні стек драйверів, менше кабелів, менше проблем сумісності.
Те, що починалося як чистий інтерфейс, почало виглядати як тимчасове рішення.

Операційний погляд: межі, відповідальність і вартість клею

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

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

Glide: API, що постачав ігри (і технічний борг)

Glide був прагматичною відповіддю на реальну проблему: фрагментацію API і слабку, непослідовну підтримку драйверів для загальніших стандартів.
Розробникам не потрібна була філософія. Їм потрібні були кадри в секунду і передбачувана поведінка на споживчих машинах.
Glide дав їм прямий шлях до обладнання Voodoo з меншими сюрпризами.

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

Але рахунок приходить. Пропрієтарні API створюють тиск блокування, і ринки рано чи пізно карають блокування, коли альтернативи дозрівають.
Коли Direct3D і OpenGL стабілізувалися і покращилися, Glide перестав бути «безпечним варіантом» і став «особливим випадком».
Особливі випадки — це місця, де ваша ротація on-call помирає.

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

SLI: масштабування до того, як «multi-GPU» стало маркетинговим мемом

SLI у Voodoo2 — scan-line interleave — був хитрим і дуже 1998 рішенням. Розділити вихід рендеру по чергуваних горизонтальних рядках:
карта A рендерить один набір, карта B — інший. Ви отримуєте більше пропускної здатності заповнення, більше текстурної пропускної здатності й кращу продуктивність у вищих роздільностях.

З позиції SRE, SLI — це горизонтальне масштабування з жорстким обмеженням: ідеальна синхронізація і передбачуване розподілення.
Коли воно працює, це красиво. Коли ні — отримуєте артефакти, ривки, дивну поведінку драйвера й тікети підтримки, написані ВЕЛИКИМИ ЛІТЕРАМИ.

Є й економічна історія. Налаштування з декількома платами перекладають витрати на ентузіастів. Це прийнятно, коли ентузіасти визначають ринок.
Менш прийнятно, коли масовий покупець хоче одну карту, яка «просто працює», а OEM прагнуть простіших BOM і меншої кількості відмов.

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

Поворотні точки: де траєкторія нахилилася вниз

3dfx не померли тому, що перестали бути розумними. Вони загинули тому, що система навколо них еволюціонувала швидше за їх операційну модель.
Кілька накопичувальних змін мали значення:

• Ритм став стратегією. Конкуренти ітераціонуали швидше. Фічі, драйвери, плати — усе рухалося швидше.
• Інтеграція перемогла. Клієнти та OEM хотіли рішення «все в одній платі» з меншими змінними сумісності.
• Зацікавлення розробників змінилося. Підтримувати пропрієтарний API прийнятно, коли це приносить клієнтів; дратує, коли це приносить випадки на краю.
• Конфлікт каналів реальний. Купівля виробника плат і продаж власних плат змінює стосунки з екосистемою, що раніше розповсюджувала ваші чипи.
• Тиск виконання зріс. Коли конкуренція загострилася, «майже готово» стало «неактуальною».

Класична пастка постмортему — вибрати одного злодія: «Вони мали б зробити X.»
Реальність більш дратівлива. Вони мали кілька взаємопов’язаних ставок, кожна виправдана, і разом вони зменшили гнучкість.
У термінах надійності: вони створили скорельовані домени відмов.

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

Три корпоративні міні-історії: припущення, відкат, нудна перемога

Міні-історія 1: Інцидент через неправильне припущення (ментальність «пас-через кабелю»)

Середня студія — назвімо її Студія A — мала ПК-титул, що наближався до релізу. Їхній внутрішній таргет продуктивності базувався на одному припущенні:
«Більшість наших гравців матимуть увімкнений швидкий шлях.» У термінах 1997 року це означало Glide-рендерер на Voodoo-карті.

Вони оптимізували пайплайн контенту й складність сцени під цей профіль. У QA це виглядало чудово, бо машини QA були, що й не дивно,
тими машинами, про які команда дбала: обладнаними Voodoo, налаштованими і благословенними богами нового обладнання.

Потім вони відправили гру. Черга підтримки запалала повідомленнями від гравців на не-3dfx картах (або без 3D-акселератора), які скаржилися на непрацездатні частоти кадрів.
Не «трохи підлагує». Непрацездатні. Запасний Direct3D-шлях трактували як чекбокс сумісності, а не як повноцінний рендерер.

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

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

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

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

На синтетичних тестах і в кількох популярних тайтлах продуктивність підскочила. Маркетинг був у захваті.
Оптимізація була реальною, вимірюваною і одразу видимою в оглядових чартах. Усі отримали свою порцію бонусів.

Потім почалися звіти про баги: мерехтливі текстури, часом неправильний туман, z-fighting, якого раніше не було.
Це не відбувалося на кожній машині. Не в кожному рівні. Достатньо часто, щоб підтримка не могла відтворити проблему стабільно.

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

Це як ринкова, так і інженерна наука: коли продуктивність — ваш бренд, коректність — частина продуктивності.
Швидкий кадр, що неправильний, — все одно неправильний. Гравці помічають. Розробники пам’ятають.

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

Інша студія — Студія C — ставилася до рендер-путів як до виробничих сервісів. Вони підтримували два основні рендерери (один пропрієтарний швидкий шлях, один за стандартним API)
і ввели правило: обидва мають запускатися в CI при кожному коміті контенту.

Вони тримали золоті скриншоти для рівня для кожного рендерера. Не тому що це весело. А тому що це ловило мовчуще ушкодження рано:
витік стану шейдера, невідповідність формату текстури, проблема точності буфера глибини, що проявлялася лише на одній родині драйверів.

Пізно в розробці великий апдейт GPU-драйвера змінив поведінку фільтрації текстур.
Студія C виявила це за кілька годин, створила мінімальний репро і випустила прапор-обхід у наступному патчі.
Їхня гра лишалася стабільною, поки конкуренти метушилися на форумах.

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

Жарт №1: Масштабування multi-GPU — як групові проєкти: хтось завжди робить всю роботу, і це ніколи не та людина, яку ви очікували.

Практичні завдання: 12+ команд для діагностики «GPU повільний» у реальному житті

Історія 3dfx про обмеження: пропускна здатність, стабільність драйверів, обмеження шин і операційна реальність гетерогенного апаратного забезпечення.
Сучасні системи не такі вже й відмінні. Замініть «AGP vs PCI» на «PCIe lanes», замініть «Glide vs Direct3D» на «Vulkan vs DX12 vs compatibility layers»,
і ви все одно робите ту саму роботу: виміряти, знайти вузьке місце, змінити одне і виміряти знову.

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

Завдання 1: Визначте, який GPU і драйвер фактично використовуються

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D controller"
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP106 [GeForce GTX 1060 6GB] [10de:1c03] (rev a1)
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:3282]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Значення: Ви підтверджуєте ідентифікатор пристрою та який ядровий драйвер прив’язаний.
Рішення: Якщо очікували інший драйвер (наприклад nouveau vs nvidia), зупиніться і усуньте це перш ніж робити інші бенчмарки — інакше всі показники шум.

Завдання 2: Перевірте завантаження GPU і підказки тротлінгу

cr0x@server:~$ nvidia-smi
Wed Jan 21 10:19:44 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+----------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |         Memory-Usage | GPU-Util  Compute M. |
|                                         |                      |               MIG M. |
|=========================================+======================+======================|
|  0  GeForce GTX 1060 6GB            Off | 00000000:01:00.0  On |                  N/A |
| 35%   79C    P2              116W / 120W |   5450MiB /  6144MiB |     98%      Default |
+-----------------------------------------+----------------------+----------------------+

Значення: 98% завантаження вказує на GPU-bound навантаження; 79C і близько до ліміту потужності натякають на можливе тротлінгування.
Рішення: Якщо стан продуктивності низький (P2/P3) при високому завантаженні, перевірте частоти та теплові ліміти; якщо GPU-Util низький — ймовірно, ви прив’язані до CPU або I/O.

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

cr0x@server:~$ nvidia-smi --query-gpu=clocks.gr,clocks.mem,power.draw,power.limit,temperature.gpu --format=csv
clocks.gr [MHz], clocks.mem [MHz], power.draw [W], power.limit [W], temperature.gpu
1708, 4006, 116.21, 120.00, 79

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

Завдання 4: Підтвердіть ширину та швидкість PCIe (вузькі місця шини все ще реальні)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
LnkSta:	Speed 2.5GT/s (downgraded), Width x4 (downgraded)

Значення: Слот може робити x16 при 8GT/s, але ви працюєте на x4 Gen1. Це величезний обмежувач продуктивності.
Рішення: Пересійте карту, перевірте налаштування BIOS, перемістіть у інший слот, перевірте поділ ліній на материнській платі (NVMe може красти лінії). Заново виміряйте після змін.

Завдання 5: Визначте, чи робота обмежена CPU

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.6.12 (server) 	01/21/2026 	_x86_64_	(16 CPU)

10:20:01 AM  CPU   %usr %nice  %sys %iowait  %irq  %soft  %steal  %idle
10:20:02 AM  all   82.10  0.00  6.15    0.20  0.00   0.45    0.00  11.10
10:20:02 AM    7   99.00  0.00  0.50    0.00  0.00   0.00    0.00   0.50

Значення: Один ядро підпружинене майже на 100% у той час як GPU недозавантажений — класична проблема однопоточного вузького місця (потік драйвера, головний потік гри).
Рішення: Зменшіть накладні витрати на виклики малювання, змініть налаштування рушія або протестуйте інший бекенд API. Оновлення апаратури має відповідати вузькому місцю, а не вашим сподіванням.

Завдання 6: Зловіть очевидні I/O затримки (стримінг ресурсів, кеш шейдерів, page faults)

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.12    0.00    6.02    8.55    0.00   50.31

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1         120.0   14500.0     0.0   0.00    1.20   120.8     95.0   8900.0    2.10    93.7    0.38   32.0

Значення: iowait не тривіальний, але латентність NVMe низька; диск не насичений.
Рішення: Якщо %util близьке до 100% з високим await — ви обмежені сховищем; перенесіть навантаження на швидше сховище або зменшіть стримінг. Якщо ні — дивіться в інші напрямки.

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

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       550Mi       1.2Gi       2.5Gi       1.6Gi
Swap:           16Gi        6.2Gi       9.8Gi

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

Завдання 8: Підтвердіть обмеження композитора / дисплейного сервера (проблеми з тимінгом кадрів)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

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

Завдання 9: Перевірте журнали ядра на помилки PCIe або GPU

cr0x@server:~$ sudo dmesg -T | tail -n 15
[Wed Jan 21 10:18:22 2026] NVRM: GPU at PCI:0000:01:00: GPU-12345678-90ab-cdef-1234-567890abcdef
[Wed Jan 21 10:18:23 2026] NVRM: Xid (PCI:0000:01:00): 79, pid=22119, name=game.bin, GPU has fallen off the bus.
[Wed Jan 21 10:18:23 2026] pcieport 0000:00:1c.0: AER: Corrected error received: id=00e0

Значення: «GPU has fallen off the bus» — це червоний тривожний сигнал стабільності: проблема з живленням, слотом, райзером або драйвером.
Рішення: Припиніть тонке налаштування і почніть стабілізацію: пересійте, перевірте PSU, приберіть райзери, оновіть BIOS, протестуйте інший гілку драйвера. Робота над продуктивністю марна, поки помилки не зникнуть.

Завдання 10: Підтвердіть вибір рендерера OpenGL/Vulkan (іноді вибирається неправильний пристрій)

cr0x@server:~$ glxinfo -B | grep -E "OpenGL vendor|OpenGL renderer|OpenGL version"
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GTX 1060 6GB/PCIe/SSE2
OpenGL version string: 4.6.0 NVIDIA 550.54.14

Значення: Підтверджує, що додаток ймовірно використає дискретний GPU для OpenGL.
Рішення: Якщо тут показано llvmpipe або iGPU-рендерер — виправте налаштування PRIME/offloading; інакше ви бенчмаркуєте не той пристрій.

Завдання 11: Огляньте перелік пристроїв Vulkan (особливо на системах з кількома GPU)

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

Devices:
========
GPU0:
	apiVersion         = 1.3.275
	driverVersion      = 550.54.14
	vendorID           = 0x10de
	deviceName         = NVIDIA GeForce GTX 1060 6GB
GPU1:
	apiVersion         = 1.3.275
	driverVersion      = 23.3.1
	vendorID           = 0x1002
	deviceName         = AMD Radeon(TM) Graphics

Значення: Видно два GPU. Додатки можуть за замовчуванням вибрати неправильний.
Рішення: Примусьте вибір GPU через налаштування додатка або змінні середовища; підтвердіть після змін. Невизначеність між пристроями — це сучасний варіант «неправильного рендерера».

Завдання 12: Вимірюйте стабільність часу кадру, а не лише середній FPS (діагностика підлагувань)

cr0x@server:~$ cat /proc/pressure/cpu
some avg10=0.12 avg60=0.08 avg300=0.05 total=2912301
full avg10=0.02 avg60=0.01 avg300=0.00 total=183921

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

Завдання 13: Переконайтеся, що масштабування частоти CPU не саботує вас

cr0x@server:~$ sudo cpupower frequency-info | sed -n '1,25p'
analyzing CPU 0:
  driver: amd-pstate-epp
  CPUs which run at the same hardware frequency: 0
  available frequency steps: 3.40 GHz, 2.80 GHz, 2.20 GHz
  current policy: frequency should be within 2.20 GHz and 3.40 GHz.
                  The governor "powersave" may decide which speed to use
  current CPU frequency: 2.20 GHz (asserted by call to hardware)

Значення: Governor — powersave; CPU застряг на низькій частоті може створити вузьке місце CPU, що маскується під «повільний GPU».
Рішення: Переключіться на performance для бенчмарків або навантажень чутливих до латентності, потім перевірте знову. Не плутайте «батарейну політику» з можливістю апаратного забезпечення.

Завдання 14: Перевірте трясіння кешу шейдерів і затримки файлової системи

cr0x@server:~$ sudo strace -f -e trace=file -p $(pgrep -n game.bin) 2>&1 | head
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/index", O_RDONLY|O_CLOEXEC) = 42
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/ab/cd/ef...", O_RDONLY|O_CLOEXEC) = 43
openat(AT_FDCWD, "/home/user/.cache/mesa_shader_cache/01/23/45...", O_RDONLY|O_CLOEXEC) = 44

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

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

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

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

Перш за все: переконайтеся, що ви вимірюєте правильний пристрій і правильний шлях

• Підтвердіть прив’язку GPU і драйвера (lspci -nnk).
• Підтвердіть, що рендерер — дискретний GPU (glxinfo -B, vulkaninfo --summary).
• Перевірте тип сесії/композитора і відомі обмеження (echo $XDG_SESSION_TYPE).

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

Друге: вирішіть, чи ви прив’язані до GPU, CPU або I/O

• Завантаження GPU і частоти (nvidia-smi або еквівалент).
• Насичення по ядрах CPU (mpstat -P ALL).
• Латентність і завантаженість сховища (iostat -xz).
• Тиск пам’яті і swap (free -h).

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

Третє: усуньте проблеми стабільності перед тюнингом продуктивності

• Скан журналів ядра на помилки PCIe і GPU (dmesg -T).
• Перевірка швидкості/ширини PCIe (lspci -vv).

Рішення: Будь-які помилки шини, Xid або знижені лінки означають: спочатку виправте апарат/прошивку/налаштування. Налаштування продуктивності на нестабільній платформі — марна витрата часу.

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

Симптом: Чудовий середній FPS, жахливі підлагування

Корінь: Конкуренція CPU (фонові процеси), компіляція шейдерів під час гри або затримки файлової системи для кешів.

Виправлення: Перевірте тиск CPU (/proc/pressure/cpu), перемістіть кеш шейдерів на локальний SSD, препроцесіть шейдери, обмежте фонові задачі.

Симптом: GPU «повинен бути швидким», але завантаження низьке

Корінь: Вузьке місце на головному потоці CPU, накладні витрати драйвера або додаток працює на iGPU/llvmpipe.

Виправлення: Підтвердіть вибір рендерера (glxinfo -B), слідкуйте за навантаженням по ядрах (mpstat), спробуйте інший бекенд API або зменшіть кількість викликів малювання.

Симптом: Раптове падіння продуктивності після додавання NVMe-диска

Корінь: Поділ PCIe-ліній викликає переговори GPU до x4 або Gen1/Gen2.

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

Симптом: Випадкові чорні екрани або «GPU fell off the bus»

Корінь: Нестабільність живлення, поганий контакт райзера/слота, перегрів VRM або невідповідності драйвера/ядра.

Виправлення: Перегляньте dmesg, спростіть апаратний шлях (без райзерів), перевірте запас PSU, протестуйте інші версії драйвера, оновіть BIOS.

Симптом: «На старому драйвері було швидше»

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

Виправлення: Порівняйте частоти/обмеження потужності, валідуйте однакове навантаження й налаштування, майте план відкату й невелику регресійну суїту.

Симптом: Чудова продуктивність в одному API (наприклад, Vulkan), погана в іншому (наприклад, OpenGL)

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

Виправлення: Оберіть бекенд, що стабільний для вашого флоту; стандартизуйте його. Якщо треба підтримувати обидва — тестуйте їх постійно (нудно, але правильно й ефективно).

Контрольні списки / покроковий план

Контрольний список: якщо ви відновлюєте ретро-машину епохи 3dfx (мислення все ще застосовується)

1. Спочатку стабілізуйте платформу: живлення, охолодження, чисті контакти. Продуктивність приходить після «не падає».
2. Контролюйте змінні: одна зміна за раз (версія драйвера, API, роздільність).
3. Підтвердіть шлях рендеру: переконайтеся, що обрано потрібний API/рендерер.
4. Вимірюйте час кадру, а не лише FPS: плавність — метрика надійності.

Контрольний список: якщо ви управляєте сучасними GPU-системами як продакшн-сервісами

1. Інвентар: зафіксуйте модель GPU, версію драйвера, статус PCIe лінку та версію ядра для кожного хоста.
2. Базова лінія: запишіть еталонний прогін бенчмарка з частотами, потужністю, температурами й завантаженням.
3. Запобіжники: канарні оновлення драйверів на невеликій підмножині; готовність до відкату обов’язкова.
4. Регресійна суїта: виберіть кілька репрезентативних робочих навантажень; автоматизуйте їх.
5. Телеметрія: логувати помилки GPU з журналів ядра; алертувати по повторюваних Xid/AER подіях.
6. Планування ємності: відстежуйте тиск пам’яті і swap; вважаєте swap інцидентом для латентносних навантажень.

Покроковий план: коли команда каже «GPU повільніший, ніж минулого тижня»

1. Підтвердіть шлях пристрою/драйвера (Завдання 1, 10, 11). Якщо неправильно — виправте вибір, не сперечайтеся.
2. Перевірте сигнали стабільності (Завдання 9). Будь-які помилки шини/GPU означають режим інциденту, а не продуктивності.
3. Перевірте переговори PCIe (Завдання 4). Понижені лінки — поширена й руйнівна проблема.
4. Класифікуйте вузьке місце (Завдання 2, 5, 6, 7). Оберіть домінуюче обмеження.
5. Перевірте політичні ручки (Завдання 13). Губернатори потужності та ліміти можуть виглядати як «регресії».
6. Тільки потім починайте тюнінг на рівні коду або рушія.

ЧаПи

Чи була доля 3dfx вирішена, як тільки з’явився NVIDIA?

Ні. Конкуренція не прирікає вас; не гнучкість — так. NVIDIA виконувала швидше й використовувала інтеграцію та стандарти, але в 3dfx були варіанти — просто з часом їх ставало менше.

Чому Glide мав таке велике значення?

Він давав розробникам стабільну ціль у нестабільну епоху. Ця стабільність створювала зворотний зв’язок: більше ігор підтримували Glide, більше людей купували Voodoo-карти, і так далі.
Пізніший ціновий рахунок був стратегічним: пропрієтарні шляхи погано старіють, коли стандарти наздоганяють.

Чи було SLI насправді хорошою інженерією?

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

Чи допомогла покупка виробника плат 3dfx?

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

Який сучасний еквівалент пастки Glide?

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

Як уникнути «бенчмарк-інженерії», що відкатується?

Трактуйте коректність як частину продуктивності. Будуйте регресійні тести, що рендерять реальні навантаження, а не лише синтетичні графіки.
Розгортайте зміни драйверів/оптимізацій канарно і майте швидкий відкат.

Яку єдину метрику ви відстежували б, якби керували флотом GPU?

Спочатку рівні помилок і сигнали стабільності (помилки ядра GPU, помилки PCIe). Продуктивність іде після надійності.
GPU, що «іноді зникає», має безкінечну латентність.

Яка найкраща перша перевірка, коли GPU працює гірше?

Статус PCIe лінку та вибір пристрою. Карта, що працює на x4 Gen1, або додаток, що працює на iGPU, можуть замаскувати десятки інших проблем.

Чи програли 3dfx тому, що не мали кращого апаратного забезпечення?

Апарат важливий, але операційна модель важливіша: ритм релізів, драйвери, підтримка платформи, партнерська екосистема і стратегічна адаптивність.
Ви можете відправити чудовий чип і все одно програти системну гру.

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

3dfx запам’яталися завдяки Voodoo-картам і моменту, коли ПК-ігри перестали виглядати як таблиці з виразом.
Але корисна частина історії — не ностальгія, а моделі відмов.
Вони перемогли на початку, звузивши сферу і зробивши «гарячий шлях» шалено швидким. Вони загубилися пізніше, несучи рішення, що стали дорогими в умовах змін:
пропрієтарні залежності, тертя в екосистемі і повільніша адаптація до інтеграції та ритму.

Якщо ви будуєте платформи — апарат, драйвери, API або внутрішню інфраструктуру — наступні кроки грубі, але корисні:

1. Вимірюйте реальність, а не намір. Зробіть інвентар того, що фактично розгорнуто і які шляхи коду справді використовуються.
2. Стабілізуйте першочергово. Будь-які помилки шини, аварії драйвера або умови пониження означають, що робота над продуктивністю — відволікання.
3. Проєктуйте для міграції. Якщо ви пропонуєте пропрієтарний «швидкий шлях», заплануйте виїзну рампу до того, як ринок її призначить.
4. Відправляйте нудну дисципліну. Регресійні суїти, канарки, плани відкату — це конкурентні переваги, замасковані під рутину.