3dfx Voodoo: плата, що зробила 3D мейнстримом

До Voodoo: чому 3D був хаосом

У 1995 році «3D на ПК» означало лотерею чіпсетів, драйверів і напівзавершених API. Ви могли купити швидкий процесор, пристойну 2D‑плату
і все одно отримати слайдшоу в момент, коли гра спробує текстурувати щось. Більшість систем рендерили 3D програмно на CPU.
Це працювало, певною мірою, і лише якщо ви були щедрі щодо того, що означає «працює».

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

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

Що насправді було Voodoo (а чого не було)

Початковий споживчий хіт зазвичай пам’ятають як «Voodoo Graphics» (часто згодом названий Voodoo1).
Це був прискорювач 3D, а не повноцінна графічна плата в сучасному розумінні. Вам все одно потрібна була окрема 2D‑плата для Windows.
Voodoo сидів на шині PCI, чекав, коли гра його викличе, і тоді перехоплював відеосигнал через зовнішній passthrough‑кабель.

Цей зовнішній кабель звучить як хак, бо ним і був. Але це був стратегічно свідомий хак: він дозволив 3dfx вийти на ринок
без боротьби з 2D‑десктоп‑екосистемою і без необхідності бути єдиною картою, яка має працювати в кожному режимі Windows.
Якщо ви колись ізолювали ризиковий підсистему за фічфлагом або проксі, ви бачили той же архітектурний інстинкт.

Це також означало, що Voodoo міг зосередитися на тому, що важливо для ігор: текстурування, Z‑буфер, фільтрація і змішування,
налаштовані під типові тодішні роздільності. Йому не треба було бути універсалом. Він мав бути швидким там, де насправді жили люди.

Епоха двох плат і чому це був розумний компроміс

Налаштування «дві плати + кабель» зараз виглядає смішно, але це було чисте розділення обов’язків:
стабільний 2D‑десктоп з одного боку і спеціалізований 3D‑конвеєр з іншого.
Це зменшувало радіус ураження, коли щось йшло не так. Якщо гра падала, ви не втрачали весь десктоп.
В часи, коли драйвери могли валити ОС разом із собою, це мало значення.

Жарт №1: Пасстру‑кабель був оригінальною service mesh — хіба що без спостережуваності, і він міг назавжди застрягнути за вашим столом.

Як це працювало: конвеєри, пасстру та чому це важливо

Підхід Voodoo був простим: прискорити ті частини, які дорогі в програмному виконанні. CPU міг справлятися з логікою гри, фізикою (такою, яка була)
і подачею трикутників. Плата обробляла растеризацію і текстурування зі швидкістю, якої не дістав би середньостатистичний CPU середини 90‑х.
Це поділ праці сьогодні здається очевидним. Тоді в споживчому сегменті це таким не було, особливо за прийнятною ціною.

Ключова практична деталь: конвеєр Voodoo був спроектований під апарат із фіксованою функціональністю. Розробники не писали шейдерів.
Вони вибирали режими. Вони керували текстурами. Вони жили в межах обмежень.
Це дуже схоже на керування розподіленим сховищем даних із фіксованою моделлю запитів: продуктивність чудова, доки ви поважаєте форму системи.
Боротьба з нею призведе до поразки.

Перемикання пасстру: «просто працює», поки не перестане

Зовнішній passthrough‑кабель Voodoo переносив аналогові VGA‑сигнали з 2D‑плати у Voodoo і потім на монітор.
Коли гра переходила в 3D‑режим, Voodoo перемикала вивід на себе. Це було просто й дивовижно надійно, але додавало нові режими відмов:
пом’якшення якості зображення, фантоми, погані кабелі та запитання «чому мій монітор чорний?», які зовсім не піддавалися налагодженню програмно.

Тут зустрічаються журналістський і SRE‑мозок. Фіча блискуча. Режим відмови — користувачеві ворожий.
Ви можете бути праві і все одно отримати page‑alert.

Чому це відчувалося як революція

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

Glide: швидка смуга з платним проїздом

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

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

Direct3D і OpenGL: хаотичні, але неминучі

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

Що змінилося за одну ніч: очікування користувачів і індустріальна гравітація

Коли прискорення класу Voodoo стало видимим, назад дороги не було. Ефекти освітлення, фільтрація текстур,
вищі частоти кадрів — це вже не були «приємні доповнення». Вони стали базою того, як має виглядати PC‑геймінг.
Плата не лише продавалася сама; вона продавала ідею, що для серйозного геймінгу потрібне 3D‑апаратне забезпечення.

Це тонкий культурний зсув: коли можливість стає масовою, вона перестає бути фічею й стає залежністю.
Залежності створюють зобов’язання: сумісність, драйвери, підтримка, передбачувана продуктивність. Епоха Voodoo змусила екосистему ПК
серйозно сприймати споживчий 3D і потягла за собою ОС, моделі драйверів і інструментацію для розробників.

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

Цікаві факти й контекст для бару (або постмортему)

• Voodoo Graphics був прискорювачем тільки для 3D: вам потрібна була окрема 2D‑плата і VGA‑пасстру до монітора.
• Glide став де‑факто ціллю: багато ПК‑ігор виходили з окремими 3dfx/Glide‑рендерами через очевидний приріст продуктивності.
• Voodoo2 ввів scan‑line interleave (SLI): дві плати могли розділити навантаження рендеру, змінюючи рядки сканування для вищої продуктивності.
• «SLI» спочатку означало scan‑line interleave: пізніше перезапуск назви в сучасних GPU споріднений за духом, але не тотожний реалізацією.
• Ринок повернувся до одно-платних 2D+3D рішень: споживачі не хотіли назавжди дві плати і кабель; перемогла інтеграція.
• Якість драйверів стала конкурентною зброєю: важлива не лише швидкість, а й «не падає» і «працює в цій грі» — це важливіше за маркетинг.
• Аналогова цілісність сигналу була реальною: дешеві passthrough‑кабелі й шумні плати могли помітно погіршити якість 2D на CRT.
• API з часом консолідувалися: пропрієтарні швидкі шляхи поступались місцем широко підтримуваним API через вартість сумісності для розробників.

Уроки SRE від графічної карти 1996 року

1) Вузька ціль переважає над ідеальною широкою

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

2) Сумісність — це фіча, а не податок

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

3) Вимірюйте час кадру, а не відчуття

Люди сперечалися про FPS тоді так само, як сперечаються про перцентилі латентності зараз. Інтуїція правильна: користувацький досвід формується послідовністю,
а не середніми значеннями. Стабільні 45 FPS часто відчуваються краще за 90 FPS із піками. Так само із сервісами:
стабільний p95 кращий за героїчний p50. Не оптимізуйте число, яке змушує вас почуватися добре.

4) «Швидкий шлях» — це зобов’язання

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

5) Дрібні фізичні деталі можуть стати найбільшим джерелом проблем

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

6) Цитата, яку варто повісити на стіну

«Hope is not a strategy.» — генерал Гордон Р. Салліван

Епоха Voodoo винагороджувала команди, які тестували реальні ігри на реальних машинах, а не ті, що сподівались, що драйвер поведеться.
Та сама логіка сьогодні. Надія не надсилає алерти; реальність — надсилає.

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

Ці завдання припускають, що ви оперуєте Linux‑робочою станцією, ретро‑геймінг‑хостом або лабораторною машиною для бенчмаркінгу/емуляції.
Суть не в тому, щоб запустити Voodoo на сучасному Linux; суть у формуванні м’язової пам’яті:
інвентаризувати апаратне забезпечення, підтвердити драйвери, валідовати шлях рендерингу, а потім знайти вузьке місце на підставі доказів.

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

cr0x@server:~$ lspci -nnk | sed -n '/VGA compatible controller/,+4p'
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:11c3]
	Kernel driver in use: nvidia
	Kernel modules: nvidiafb, nouveau, nvidia_drm, nvidia

Що це означає: ви бачите пристрій і який драйвер ним володіє.
Рішення: якщо «Kernel driver in use» відсутній або неправильний, виправте прив’язку драйвера перш ніж шукати проблеми з продуктивністю.

Завдання 2: Перевірити, чи OpenGL рендериться програмно (класична пастка «чому повільно»)

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

Що це означає: ви використовуєте реальний GPU‑драйвер, а не Mesa llvmpipe.
Рішення: якщо renderer показує «llvmpipe» або «Software Rasterizer», зупиніться — виправте драйвер/GL стек спочатку.

Завдання 3: Підтвердити Vulkan‑шлях (корисно для сучасних обгорток/емуляторів)

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

Instance Extensions: count = 20
==============================
VK_EXT_debug_report                    : extension revision 10
VK_EXT_debug_utils                     : extension revision 2
...

Devices:
========
GPU0:
	apiVersion         = 1.3.275
	driverVersion      = 550.54.14
	vendorID           = 0x10de
	deviceID           = 0x1c03
	deviceName         = NVIDIA GeForce GTX 1060 6GB

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

Завдання 4: Виміряти масштабування частоти CPU (номер №1 в загадках продуктивності)

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|MHz'
CPU(s):                               16
Model name:                           AMD Ryzen 7 5800X 8-Core Processor
CPU MHz:                              3699.906

Що це означає: поточна заявлена MHz і топологія.
Рішення: якщо MHz застрягла дуже низько під навантаженням, виправте режим енергозбереження/термальне дроселювання перед тим, як звинувачувати GPU.

Завдання 5: Підтвердити тактові частоти GPU і стан тротлінгу

cr0x@server:~$ nvidia-smi --query-gpu=clocks.gr,clocks.mem,pstate,temperature.gpu,utilization.gpu --format=csv
clocks.gr [MHz], clocks.mem [MHz], pstate, temperature.gpu, utilization.gpu [%]
1770, 4006, P2, 67, 35

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

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

cr0x@server:~$ sudo lspci -vv -s 01:00.0 | egrep -i 'LnkCap|LnkSta'
LnkCap:	Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <1us, L1 <16us
LnkSta:	Speed 8GT/s (ok), Width x16 (ok)

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

Завдання 7: Перевірити системний I/O wait і переключення контекстів під час бенчмарку

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 312456  66240 845320    0    0    12    24  684 1250 12  3 85  0  0
 2  0      0 309812  66240 845988    0    0     0     0  722 1890 28  6 66  0  0
 3  0      0 307220  66240 846112    0    0     0     0  740 2055 35  7 58  0  0
 1  0      0 306900  66240 846220    0    0     0     0  701 1622 25  4 71  0  0
 1  0      0 306500  66240 846330    0    0     0     0  690 1501 18  3 79  0  0

Що це означає: якщо wa високе, ви чекаєте на диск; якщо cs вибухає, можливо ви обмежені плануванням.
Рішення: високе iowait означає, що ваша «GPU‑проблема» ймовірно пов’язана зі стримінгом активів або свапом; виправляйте зберігання/пам’ять.

Завдання 8: Подивитися, які процеси їдять CPU під час бенчмарку

cr0x@server:~$ pidstat -u 1 3
Linux 6.6.12 (server) 	01/13/2026 	_x86_64_	(16 CPU)

12:10:01     UID       PID    %usr %system  %guest   %CPU   CPU  Command
12:10:02    1000     18421   92.00    6.00    0.00  98.00     7  retroarch
12:10:02       0      1542    1.00    2.00    0.00   3.00     1  Xorg
12:10:02    1000      2310    0.00    1.00    0.00   1.00     3  pulseaudio

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

Завдання 9: Підтвердити, чи система свапить (отрута для латентності)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        21Gi       1.2Gi       1.1Gi       9.0Gi        8.7Gi
Swap:          2.0Gi       1.6Gi       400Mi

Що це означає: свап використовується; якщо він зростає під час прогонів, продуктивність буде стрибати.
Рішення: додайте RAM, зменшіть фонові процеси або налаштуйте swappiness; не ганяйтесь за «GPU‑стуттером», поки свап не зникне.

Завдання 10: Перевірити dmesg на предмет скидань GPU і помилок PCIe

cr0x@server:~$ sudo dmesg -T | egrep -i 'nvrm|amdgpu|i915|pcie|AER|reset' | tail -n 12
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0: AER: Corrected error received: 0000:00:1c.0
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0:   device [1022:1453] error status/mask=00000001/00002000
[Tue Jan 13 11:58:42 2026] pcieport 0000:00:01.0:    [ 0] RxErr

Що це означає: виправлені помилки PCIe. Не фатально, але тривожно.
Рішення: якщо вони корелюють зі стуттером/крахами, перевірте слот, райзер, стабільність PSU; не витрачайте час на налаштування софту спочатку.

Завдання 11: Виміряти латентність зберігання (стримінг активів реально дає стуттер)

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.12    0.00    4.92    0.21    0.00   76.75

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await aqu-sz  %util
nvme0n1         72.00   9140.00     0.00   0.00    0.35   126.94   15.00   1920.00    0.62   0.03   3.10

Що це означає: r_await/w_await низькі; %util низький: зберігання не ваш вузький елемент.
Рішення: переходьте до синхронізації CPU/GPU і шляху рендерингу; не «оптимізуйте диск» з нудьги.

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

cr0x@server:~$ ulimit -n
1024

Що це означає: максимум відкритих файлів для shell/process — 1024.
Рішення: якщо лаунчер або емульятор завантажує багато активів/плагінів, підніміть ліміти; уникайте «випадкових крахів», що є втомленням FD.

Завдання 13: Перевірити, що ви не працюєте в віддаленій сесії з примусовим програмним рендерингом

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Що це означає: локальний тип сесії. Віддалена X‑форвардинг і деякі вкладені налаштування можуть послабити прискорення.
Рішення: якщо ви працюєте через SSH X11 forwarding або в звуженій VM, проводьте бенчмарки локально або з належним GPU‑passthrough.

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

cr0x@server:~$ sensors | sed -n '1,35p'
k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.9°C
Tdie:         +83.9°C

nvme-pci-0100
Adapter: PCI adapter
Composite:    +44.9°C

Що це означає: температура CPU висока; ви можете підходити до тротлінгу залежно від платформи.
Рішення: виправте охолодження перед оптимізаціями кодових шляхів; тротлінг робить будь‑яке вимірювання брехливим.

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

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

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

Перше: підтвердіть шлях рендерингу і реальність драйвера

• Підтвердіть прив’язку драйвера GPU (lspci -nnk).
• Підтвердіть, що OpenGL/Vulkan апаратні, а не програмні (glxinfo -B, vulkaninfo --summary).
• Перевірте логи на предмет скидань і шуму PCIe/AER (dmesg -T фільтри).

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

Друге: вирішіть, обмежує CPU чи GPU одним проходом вимірювань

• Спостерігайте насичення ядер CPU (pidstat -u).
• Спостерігайте завантаження і тактові частоти GPU (nvidia-smi або відповідник вендора).
• Перевірте свап і тиск пам’яті (free -h).

Контрольний рубіж: якщо одне ядро завантажене, а GPU байдуже, ви обмежені CPU/накладними драйвера.
Якщо GPU завантажений, а CPU має запас — вузьке місце в GPU. Якщо обидва низькі — ви стоїте на синхронізації, I/O або конфігурації.

Третє: усуньте «неочевидні» вузькі місця

• Латентність зберігання (iostat -x), якщо є стримінг/стуттер.
• Ширина PCIe (lspci -vv), якщо продуктивність підозріло обмежена.
• Терміка (sensors, температури GPU), щоб не гаяти час на налаштування під тротлінг.

Контрольний рубіж: якщо терміка або PCIe неправильні, виправте апарат або прошивку перед налаштуванням софту.

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

Чорний екран, коли гра переходить у 3D

Симптом: екран темніє при вході в прискорений режим; десктоп повертається іноді при виході.

Корінна причина: в епоху Voodoo: поганий passthrough‑кабель, неподтримувана частота оновлення або проблеми синхронізації монітора.
У сучасних налаштуваннях: неправильний fullscreen‑режим, конфлікт композитора або скидання GPU.

Виправлення: зафіксуйте безпечну роздільність/частоту; поміняйте кабелі; уникайте екзотичних адаптерів; перевірте логи на скидання GPU; тестуйте ексклюзивний fullscreen проти безрамкового.

Середній FPS хороший, але гра «відчувається» жахливо

Симптом: бенчмарк показує високий FPS, але рухи нерівномірні і ввод відчувається запізнілим.

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

Виправлення: захоплюйте часи кадрів (не лише FPS) за допомогою інструментів; зменшіть фонове навантаження; препроцесіть шейдери коли можливо; тестуйте vsync і обмежувачі кадрів.

Продуктивність обмежена дивно низьким порогом

Симптом: незважаючи на зміни налаштувань, не можливо перевищити низький FPS (наприклад, 30/60/75) або GPU відмовляється бустити.

Корінна причина: Vsync‑кап, невідповідність частоти оновлення, енергоменеджмент, або переговори PCIe вниз (x1/x4).

Виправлення: перевірте частоту оновлення, відключіть vsync для тестів, перевірте ширину/швидкість PCIe, перевірте pstate і налаштування управління живленням GPU.

Краші, що трапляються лише на одній машині

Симптом: той самий білд, та сама гра, але різна стабільність на різних машинах.

Корінна причина: версії драйверів, нестабільні розгони, граничний PSU, виправлені помилки PCIe, що ескалюють під навантаженням, або погана RAM.

Виправлення: зафіксуйте версії драйверів; зніміть розгони; запустіть тести пам’яті; перевірте dmesg на AER; сприймайте «виправлені помилки» як попередження.

«Вчора все було нормально» після рутинного оновлення

Симптом: раптові регресії без змін у коді гри/емулятора.

Корінна причина: зміни в GL/Vulkan стеці, оновлення Mesa/NVIDIA драйвера, оновлення композитора або регресія в ядрі.

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

Зображення виглядає м’яким або шумним (ретро‑специфічне, але корисне)

Симптом: текст на десктопі або 2D‑вивід погіршилися після додавання 3D‑карти (класична скарга на passthrough Voodoo).

Корінна причина: деградація аналогового сигналу через passthrough‑кабель і роз’єми.

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

Три корпоративні міні-історії з шахт сумісності

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

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

Хибне припущення було тонким: «OpenGL доступний» трактується як «апаратне прискорення доступне». На підмножині ноутбуків стек драйверів
тихо давав OpenGL через програмний растеризатор. Технічно це було вірно, але операційно катастрофічно.
CI‑джоби почали тайм‑аутитись; ноутбуки почали звучати як маленькі літаки; інструмент отримав репутацію ненадійного.

Перші спроби налагодження пішли звичними непродуктивними шляхами: звинувачення нового алгоритму, гонитва за витоками пам’яті і суперечки про моделі ноутбуків.
Прорив прийшов, коли одна людина поставила нудне питання: «Що показує glxinfo -B на машинах, що падають?»
Воно показувало «llvmpipe». Справу закрито.

Ми виправили це, покращивши логіку виявлення. Ми більше не питали «чи є OpenGL», а питали «чи це апаратне».
Якщо ні — ми форсували простіший рендер із явними попередженнями. Також додали самотест на старті, що виводить рядок renderer у логи.
Без героїки. Просто коректний предикат.

Це урок Voodoo в сучасному одязі: ви не маєте права припускати, що швидкий шлях активний. Ви його перевіряєте.
Система ввічливо бреше, поки ви не вимагатимете доказів.

Міні‑історія №2: Оптимізація, що зіграла зворотний ефект

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

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

Постмортем впирався на вимірювання правильної речі. Середній FPS зріс, але p95 часу кадру погіршився.
Більш важливо — хвостова поведінка корелювала з паузами GC в окремому компоненті і з jitter‑ом мережі.
Оптимізація не усунула вузьке місце; вона прибрала стабілізатор.

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

Паралель з Voodoo: апаратне прискорення давало швидкість, але переможним було відчуття передбачуваності.
Люди пам’ятають «плавність», а не «пік». Оптимізуйте відчуття, а не показове число.

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

Невелика інфраструктурна група підтримувала лабораторію різнорідних машин для QA: різні GPU, різні гілки драйверів
і різні образи ОС. Це було дорого і без нагород. Але це також запобігло дорогому провалу.

Новий білд CAD‑подібного застосунку виглядав нормально на основних робочих станціях розробників. Реліз був запланований.
Лабораторія прогнала набір регресій по «дивних кінцевих» машинах — старі драйвери, альтернативні GPU і кілька систем з нестандартними дисплеями.
З’явилися дві помилки: одна — краш драйвера на певній гілці; інша — корупція рендерінгу, коли певне розширення присутнє.

Команда не кинулась «фіксити драйвери». Вони зробили те, що роблять зрілі ops‑команди: звузили сферу і контролювали змінні.
Вони зафіксували відому‑хорошу версію драйвера для релізу і додали runtime‑виявлення функцій, щоб уникати проблемного шляху з розширенням.
Додаток вийшов без хвилі звернень у підтримку.

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

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

Крок за кроком: оцінка «проблеми прискорення 3D» без марнування післяобіду

1. Інвентар апаратного забезпечення і драйверів.
   Використайте lspci -nnk. Підтвердіть, що правильний kernel driver прив’язаний.
   Якщо ні — виправляйте це перш ніж рухатись далі.
2. Переконайтесь, що апаратне прискорення реальне.
   Використайте glxinfo -B (і vulkaninfo, якщо релевантно).
   Якщо бачите програмні рендерери — зупиніться і відновіть графічний стек.
3. Встановіть базовий прогін.
   Виберіть один відтворюваний сценарій/бенчмарк і запустіть його двічі. Якщо результати сильно відрізняються, середовище нестабільне для налаштувань.
4. Класифікуйте напрямок вузького місця.
   Спостерігайте насичення ядер CPU (pidstat) і завантаження/клоки GPU (nvidia-smi).
5. Виключіть тиск пам’яті.
   Перевірте free -h. Якщо свап рухається — спочатку вирішіть пам’ять.
6. Виключіть I/O‑зависання.
   Використайте iostat -x під час прогону. Якщо очікування зростають і %util підскакує — ви обмежені зберіганням.
7. Перевірте фізичний/прошивковий шар.
   Підтвердіть ширину/швидкість PCIe. Перегляньте dmesg на AER. Перевірте терміки.
8. Тільки потім налаштовуйте параметри.
   Під час налаштувань змінюйте одну змінну за раз і ведіть нотатки. Ставтесь до цього як до експерименту, а не до сесії інтуїції.

Контрольний список: зробити швидкий шлях безпечним (урок Glide)

• Мати явний механізм виявлення, чи активний швидкий шлях.
• Логувати виявлений шлях у місці, яке можна переглянути пізніше.
• Підтримувати запасний шлях, який повільніший, але коректний.
• Регулярно тестувати обидва шляхи; інакше запасний шлях стане міфом.
• Фіксувати залежності для релізів; не «пливіть» із версіями драйверів/інструментів, якщо не любите сюрпризів.

Контрольний список: основи лабораторії сумісності (дешеве страхування)

• Щонайменше одна машина для кожного основного вендора GPU/гілки драйверів, які ви заявляєте підтримувати.
• «Найнижча загальна» машина, що представляє дно вашої бази користувачів.
• Автоматизовані смок‑тести, що перевіряють вибір бекенду рендерингу і логують renderer‑рядки.
• Відтворювані образи ОС або конфігураційне управління для швидкого скидання машин.
• Звичка запускати лабораторний набір перед релізами, а не після інцидентів.

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

Чи була оригінальна Voodoo «GPU» в сучасному розумінні?

Функціонально вона прискорювала 3D‑рендеринг, тож у дусі — так. Архітектурно це був додатковий 3D‑адд‑ін, що покладався на окрему 2D‑плату і аналоговий passthrough.
Сучасні GPU зазвичай обробляють і 2D/десктоп, і 3D, з уніфікованими драйверами і цифровими виходами.

Чому 3dfx використав passthrough‑кабель замість того, щоб бути єдиною відеокарткою?

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

Що зробило Glide таким привабливим для розробників?

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

Чи був Glide «поганим», бо пропрієтарний?

Пропрієтарність не автоматично погана; це компроміс. Glide швидко дав реальну цінність користувачам.
Вартість — це замикання в екосистемі і довгострокова крихкість, коли ринок переключається на широко підтримувані API й інтегровані карти.

Що таке Voodoo2 SLI і як це працювало?

Voodoo2 можна було парувати з другою картою через scan‑line interleave: одна карта рендерила чергуючі горизонтальні рядки.
Це покращувало продуктивність і підтримувало вищі роздільності для того часу, але збільшувало вартість, складність і проблеми сумісності.

Чому індустрія відійшла від «спеціалізованих адонів 3D»?

Інтеграція перемогла через вартість, простоту й користувацький досвід. Одна плата, один набір драйверів, менше кабелів, менше режимів відмов.
Коли інтегровані 2D+3D карти стали достатньо хорошими, підхід із двома платами став зайвим ускладненням.

Який найбільш «SRE‑релевантний» висновок з епохи Voodoo?

Підтверджуйте швидкий шлях. Не припускайте його. Інструментуйте його.
Багато відмов і інцидентів — це просто «ми думали, що прискорення/кеш/реплікація активні, але це не так».

Якщо я сьогодні налагоджую стуттер, який сучасний еквівалент проблем з «passthrough‑кабелем»?

Фізичний рівень все ще кусається: ненадійні PCIe‑райзери, граничне живлення, термальне тротлінг, або дивні проблеми з кабелем/адаптером дисплея.
Також: композитори, оверлеї й інструменти захоплення, що вставляються в шлях рендерингу.

Чи змінив Voodoo спосіб, як люди купують ПК?

Так. Він допоміг нормалізувати ідею, що ПК потребує виділеного 3D‑апаратного забезпечення для серйозного геймінгу.
Він також зробив «бренд графічної карти і якість драйверів» мейнстримовим фактором покупки, а не вузькою одержимістю.

Яка «нудна практика» найкраще відображає історію Voodoo?

Фіксуйте і тестуйте драйвери/тулчейни. Підтримуйте матрицю сумісності.
Ринок карав системи, що були швидкі в лабораторії, але нестабільні в дикій природі, і те ж саме справедливо для сучасних продакшн‑стеків.

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

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

Якщо ви будуєте або керуєте чимось чутливим до продуктивності — рендерингом, відео, обробкою даних, «AI», оберіть слово — візьміть ці наступні кроки:

1. Додайте самозвіт про «шлях рендерингу» (або еквівалент індикатора швидкого шляху) у логи й звіти про помилки. Зробіть його непомильним.
2. Базуйте час кадру і хвостову латентність, а не лише середні. Оберіть одну метрику, яку зможете відстояти в постмортемі.
3. Створіть невелику лабораторію сумісності, якщо ви підтримуєте гетерогенні клієнти. Одна дивна машина сьогодні запобігає десятьом тікетам завтра.
4. Фіксуйте залежності для релізів — драйвери, тулчейни, рантайми — і тестуйте оновлення навмисно, а не випадково.
5. Тримайте під контролем свої «passthrough‑кабелі»: маркуйте фізичний шар, аудитуйте його і сприймайте виправлені помилки як ранні сигнали тривоги.

Спадок Voodoo — не ностальгія. Це нагадування, що мейнстримом стає те, коли продуктивність стає надійною — а надійність рідко буває гламурною.