Як 3dfx програв: найсумніше падіння короля

Епоха творця королів: чому 3dfx були важливі

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

Потім з’явився Voodoo Graphics. Він додав не просто кадри в секунду. Він визначив, що таке «добре»: фільтровані текстури, плавний рух, стабільна ціль для розробників. Якщо ви робили ігри, ви хотіли те, що купували гравці. Якщо ви купували GPU, ви хотіли те, для чого будували ігри. Це економіка маховика, лише живиться вона трикутниками.

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

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

Факти та контекст, які варто пам’ятати

Це конкретні пункти, що допоможуть розуміти падіння без міфологізації.

1. Voodoo Graphics (1996) був карткою лише для 3D — можна було лишити 2D-карту й використовувати пасстрough-кабель для 3D. Було незручно, але працювало.
2. Glide — це був пропрієтарний API, спроектований близько до заліза. Розробники любили його за продуктивність і передбачуваність; ринок пізніше покарав за закритість.
3. Direct3D швидко доріс у зрілості наприкінці 1990-х. Коли Microsoft еволюціонував, теза «пиши один раз для Windows-геймінгу» стала реальною загрозою для Glide.
4. 3dfx придбали STB Systems (1998) — виробника плат — рух у бік вертикальної інтеграції, що змінило стосунки з партнерами з AIB.
5. NVIDIA невпинно ітераційно працювала, пройшовши від RIVA 128 до TNT до GeForce із агресивними темпами й міцною OEM-реалізацією.
6. Voodoo2 популяризував SLI (scan-line interleave), дозволивши двом картам ділити рендер. Це було винахідливо й дорого — не виграшне довгострокове рішення за собівартістю.
7. Voodoo3 інтегрував 2D і 3D, усунувши проблему пасстрough. Це був потрібний крок, але планка конкуренції піднімалася.
8. Якість драйверів стала фактором відмінності. Стабільність, сумісність з іграми й часті оновлення почали цінуватися так само, як пікові бенчмарки.
9. Виконання дорожньої карти 3dfx згодом підвело, тоді як конкуренти синхронізували релізи силікону з OEM-циклами — часування теж функція.

Короткий жарт для перепочинку: проблема 3dfx була не лише в пропущеній даті релізу — вони ставили до дати релізу як до необов’язкової залежності.

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

Якщо відкинути ностальгію, 3dfx програли, бо не могли тримати стабільність енд‑ту‑енд: від прийняття розробниками до місця на полиці OEM, від виробництва до драйверів і наступного покоління силікону. Ось план, який можна повторно використовувати для будь‑якої ситуації «ми маємо найкращу технологію, чому програємо?».

По‑перше: чи обирає вас екосистема?

• Перевірте площу поверхні для розробників: Ви — цільовий API/SDK за замовчуванням? Якщо ні — ви платите податок, який конкуренти уникають.
• Перевірте матрицю сумісності: Скільки багів «працює чудово на X» відкрито? Якщо відповідь потребує таблички зі смаками, ви вже позаду.
• Перевірте ритм оновлень: Ви шлете виправлення щотижня/щомісяця чи квартальні «скиди драйверів» і молитви?

По‑друге: чи працює канал з вами чи навколо вас?

• Перевірте OEM‑design wins: Якщо великі виробники ПК не відвантажують вас за замовчуванням, ваш обсяг крихкий, маржа — фантазія, а бренд робить неоплачувану роботу.
• Перевірте стимули партнерів: Якщо ви лише змінили правила для ваших платних партнерів, припустіть, що вони почнуть фінансувати дорожню карту вашого конкурента з образи й самозбереження.
• Перевірте передбачуваність постачання: Чи можете ви доставити одиниці, коли ринок їх купує? Пропустіть один сезон «до школи» або святковий цикл — і будете відчувати це роками.

По‑третє: чи виконуєте нудні частини?

• Перевірте пропускну здатність виробництва і QA: Блискучий чіп, що відвантажується із затримкою, — це чутка, а не продукт.
• Перевірте ризики дорожньої карти: Чи накопичуєте ви кілька великих змін одночасно (новий процес, архітектура, стратегія плат)? Так ви породжуєте затримки.
• Перевірте фінансову подушку: Якщо ваша готівка залежить від «флагмана наступного кварталу», ви не робите інженерію — ви граєте в рулетку.

Як 3dfx програли: п’ять режимів відмов

1) Ставка на Glide: сьогоднішня швидкість, завтра — борг прийняття

Glide мало сенсу спочатку. Він був швидким, відносно чистим і давав розробникам стабільну ціль, поки ширша Windows 3D‑стека була недорозвинена. В термінах ops Glide був внутрішнім RPC‑протоколом, який дозволяв команді доставляти фічі без очікування комітету стандартів. Чудовий хід — поки ним не скористалися.

Коли Direct3D покращився, а OpenGL залишався важливим для певних робочих навантажень, світ змінився. Розробники не хочуть трьох шляхів рендерингу, якщо лише один не приносить їм реального ринку. Коли конкуренти запропонували «достатньо хорошу» продуктивність на стандартних API, Glide перетворився на тягар підтримки. 3dfx тягли індивідуальні витрати інтеграції, тоді як конкуренти отримували екосистему безкоштовно.

Це не про те, що «пропрієтарне — погано». Пропрієтарне добре, коли дає час, який ви витрачаєте на покупку наступної переваги. Пропрієтарне фатальне, коли воно стає ідентичністю, бо ідентичності не рефакторяться.

2) Вертикальна інтеграція через STB: володіти платою, втратити канал

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

До STB 3dfx продавали кристали. Партнери по платах займалися брудною справою з виготовлення карт, дистрибуції, бандлінгу й просування в роздрібі та OEM‑угодах. Після придбання партнерам довелося ставити питання: «Ми допомагаємо постачальнику чи фінансуємо конкурента?» Багато хто вирішив зменшити експозицію.

Пошкодження каналу повільне спочатку, а потім раптове. Воно виглядає як «дивний спад попиту», потім «неочікувано сильна присутність конкурента», потім «чому всі OEM‑дизайн‑вінди йдуть кудись ще?» Це не загадка; це наслідок.

3) Виконання і часування: фіча, яку не виміряєш бенчмарком

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

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

4) Драйвери і сумісність: надійність — це продукт

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

Коли ігри диверсифікувалися й API зближувалися, коректність драйверів і швидкі виправлення стали річчю, яка захищає ринок. Це логіка SRE: найшвидший сервіс — той, що не бере вас в 2:00 ночі. Ринок GPU вивчив ту саму істину іншою мовою.

5) Конкурентна стратегія: NVIDIA грала всю дошку

NVIDIA не лише будувала GPU; вони будували операційну модель. Вони розуміли OEM‑стосунки, інструменти для розробників і реліз‑треїни. Вони оптимізувалися під ітерацію і вирівнювання платформи. 3dfx оптимізувалися під те, щоб бути правими.

Бути правим приємно. Бути тим, що може відвантажити — краще.

Другий короткий жарт (і останній, бо правила — вони правила): у апаратному забезпеченні «ми виправимо це в софті потім» — як «ми виправимо це в DNS» — технічно можливо й емоційно дорого.

Операційне дзеркало: що 3dfx навчає SRE та інженерів зберігання

Цю історію можна сприймати як ретро‑техдраму. А можна — як постмортем для сучасних систем. Раджу друге: воно платить за оренду.

Цитата про надійність, яку варто повісити на стіну

Парафразована думка від Gene Kranz: «Будьте твердими й компетентними.» В термінах ops: не панікуйте й не імпровізуйте.

Урок A: ваша «стратегія API» — просто інша форма управління залежностями

Glide був залежністю. Потужною, але такою, що вимагала підтримки, євангелізації й постійного доказу, що вона того варта. Коли Direct3D став життєздатним, Glide треба було або (a) плавно декомісувати, або (b) сховати як внутрішню реалізацію за стандартами, або (c) зробити настільки переконливим, щоб він став стандартом. 3dfx жодного з цих сценаріїв не довели до кінця.

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

Урок B: вертикальна інтеграція — це розширення радіуса вибуху

Покупка STB — не просто виробнича опція. Вона змінила контракти, стимули партнерів і режим відмов компанії. Це схоже на рішення запускати власний датацентр, власну дистрибуцію Kubernetes і власну прошивку SSD. Можна це робити. Але тепер кожен аутейдж — ваш, кожна затримка — ваша, і кожен партнер підозріло ставиться до ваших намірів.

Урок C: часування й каденс перемагають одноразову досконалість

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

Урок D: «найкраща продуктивність» нічого не значить без «кращого досвіду»

Бенчмарки — лабораторні тести. Реальний світ — це завантаження, дивні крайові випадки й нудна обробка помилок. Саме тому існує SRE. Урок 3dfx у тому, що клієнти купують результати, а не пікові графіки.

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

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

Середня компанія запускала конвеєр збірки з прискоренням GPU для рендерингу й ML‑інференсу. У них було два вендори в грі, і команда припустила, що «CUDA vs not‑CUDA» — єдиний релевантний диференціатор. Припущення: коли SDK вендора працює, залізо — взаємозамінне.

Вони підписали угоду на постачання, спираючись на пікові бенчмарки з одного чистого тесту. Потім нові карти вставили в кластер, де завдання були імпульсними, а патерни алокації пам’яті — хаотичні. Через кілька днів хвостова латентність злетіла, і планувальник почав трястися. Команда звинуватила Kubernetes, потім ядро, потім «випадковий шум».

Справжня проблема була в поведінці драйвера під тиском пам’яті в поєднанні зі тонкою взаємодією в їхньому контейнерному рантаймі. Новий драйвер відновлювався інакше при транзієнтних помилках алокації. Він не був «гіршим» в бенчмарку; він був гіршим у їхній продакшн‑реальності.

Виправлення вимагало зафіксувати версії драйверів, змінити правила пакування завдань і створити canary‑пул зі строгою матрицею сумісності. Головне: вони перестали вважати GPU просто GPU. Екосистеми — це продукти, а не аксесуари.

Міні‑історія 2: Оптимізація, що відскочила назад

Компанія e‑commerce вирішила «оптимізувати» сховище артефактів, агресивно дедуплікуючи й перейшовши на стисливу файлову розкладку. Мета була благородна: зменшити витрати на зберігання і прискорити завантаження, кешуючи більше артефактів на менше NVMe‑нодів.

Впроваджували швидко, з використанням розумного хеш‑індексу в пам’яті, який періодично скидали на диск. Стрес‑тести виглядали чудово. У продакшні нічні пікові CI спричинили шторм: компакти накладалися на піковий читальний трафік, насичуючи I/O і збільшуючи час збірок. Розробники помітили першими, потім керівники. Усі порахували, і математика була жорсткою.

Провал полягав не в ідеї стиснення або дедупа — а в тому, що це робили без суворої I/O‑ізоляції і без моделювання поведінки компактації як першокласного навантаження. Вони оптимізували під середній випадок і заплатили за хвостову біль.

Потрібні були банальні виправлення: відокремити вузли компактації від вузлів обслуговування читання, встановити явні I/O cgroups і лімітувати швидкість технічної роботи. Також вони навчилися трактувати фонову роботу як продакшн‑навантаження з SLO.

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

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

Одного дня баг прошивки спричинив, що підмножина SSD почала кидати некориговані помилки під певний патерн запису. Не всі одночасно — лише стільки, щоб тихо пошкодити кілька об’єктів, перш ніж вищі шари помітили.

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

Урок простий й наступальний: репетируйте. Надійність — не документ; це звичка.

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

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

Завдання 1: Ідентифікуйте GPU і версію драйвера (базова істина)

cr0x@server:~$ nvidia-smi
Tue Jan 13 10:14:21 2026
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.15    Driver Version: 550.54.15    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  A10               On      | 00000000:65:00.0 Off |                  Off |
| 30%   52C    P2    118W / 150W|  18342MiB / 23028MiB |     92%      Default |
+-------------------------------+----------------------+----------------------+

Що це значить: Тепер ви знаєте точну версію драйвера й чи близькі ви до лімітів потужності/пам’яті.

Рішення: Якщо інциденти корелюють зі змінами драйвера, зафіксуйте цю версію й тестуйте оновлення в canary‑пулі спочатку.

Завдання 2: Перевірте ширину/швидкість PCIe (тихий вбивця пропускної здатності)

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

Що це значить: Карта здатна на PCIe Gen4 x16, але працює як Gen3 x8.

Рішення: Дослідіть налаштування BIOS, riser‑кабелі, проводку слота або термічне тротлінгування. «Іноді нормально бенчмаркує» — саме так це ховається.

Завдання 3: Підтвердіть, що модуль ядра завантажений і здоровий

cr0x@server:~$ lsmod | grep -E "^nvidia|^amdgpu"
nvidia_drm             86016  2
nvidia_modeset       1318912  3 nvidia_drm
nvidia_uvm           3649536  0
nvidia              62713856  86 nvidia_uvm,nvidia_modeset

Що це значить: Очікувані модулі завантажені; якщо їх немає — ви не використовуєте той GPU, який вважаєте.

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

Завдання 4: Читайте журнали ядра на предмет скидань GPU або помилок PCIe

cr0x@server:~$ sudo journalctl -k -b | grep -iE "nvrm|amdgpu|pcie|aer" | tail -n 8
Jan 13 09:58:02 server kernel: pcieport 0000:00:03.1: AER: Corrected error received: id=00e1
Jan 13 09:58:02 server kernel: pcieport 0000:00:03.1: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID)
Jan 13 10:02:11 server kernel: NVRM: Xid (PCI:0000:65:00): 31, pid=18722, GPU has fallen off the bus.

Що це значить: «GPU has fallen off the bus» — не баг додатку. Це стабільність: живлення, терміка, прошивка або цілісність PCIe.

Рішення: Ескалюйте до апаратної/прошивкової команди; зменшіть power cap; перевірте кабелі/risers; ізолюйте ноду.

Завдання 5: Перевірте тепловий запас (реальні «зриви продуктивності» існують)

cr0x@server:~$ nvidia-smi -q -d TEMPERATURE,POWER | sed -n '1,120p'
==============NVSMI LOG==============
Temperature
    GPU Current Temp                  : 83 C
    GPU Shutdown Temp                 : 95 C
    GPU Slowdown Temp                 : 87 C
Power Readings
    Power Draw                        : 149.21 W
    Power Limit                       : 150.00 W
    Default Power Limit               : 150.00 W

Що це значить: Ви близькі до температури сповільнення й ліміту потужності; такти можуть бути вже обмежені.

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

Завдання 6: Ідентифікуйте насичення CPU проти GPU

cr0x@server:~$ mpstat -P ALL 1 3
Linux 6.8.0-40-generic (server) 	01/13/2026 	_x86_64_	(64 CPU)

10:14:25 AM  CPU   %usr  %nice   %sys %iowait  %irq  %soft  %steal  %idle
10:14:26 AM  all  82.10   0.00   6.45    0.12  0.00   0.55    0.00  10.78
10:14:26 AM   0  98.00   0.00   1.00    0.00  0.00   0.00    0.00   1.00
10:14:26 AM   1  97.00   0.00   2.00    0.00  0.00   0.00    0.00   1.00

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

Рішення: Профілюйте конвеєр, збільшіть паралелізм або перемістіть CPU‑стадії поза критичний шлях.

Завдання 7: Перевірте латентність сховища (бо «GPU повільний» часто означає «диск повільний»)

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0-40-generic (server) 	01/13/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          52.12    0.00    6.31    8.44    0.00   33.13

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz  aqu-sz  %util
nvme0n1         820.0  65536.0     0.0   0.00   12.40    79.92   410.0  32768.0     0.0   0.00   18.72    79.92   13.22  98.00

Що це значить: NVMe близький до 98% завантаження і очікування в десятках мілісекунд. Це латентність, яку відчуває ваш конвеєр.

Рішення: Додайте диски, розділіть читальні/записні навантаження, підлаштуйте queue depth або кешуйте входи. Не «оптимізуйте GPU‑код», поки сховище кричить.

Завдання 8: Швидко знайдіть топ‑споживачів I/O

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 58.12 M/s | Total DISK WRITE: 41.33 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
18722 be/4  build    45.21 M/s   12.03 M/s   0.00 %  72.10 %  python3 preprocess.py
19211 be/4  build     4.12 M/s   21.88 M/s   0.00 %  38.44 %  zstd -T0 artifacts.tar

Що це значить: Ваш «GPU‑джоб» включає CPU‑передобробку і стиснення, які можуть домінувати в I/O.

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

Завдання 9: Перевірте вільне місце та запас інодів файлової системи (дурна відмова)

cr0x@server:~$ df -h /var /mnt/datasets
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  1.8T  1.7T   62G  97% /
/dev/nvme1n1p1  3.6T  2.1T  1.4T  61% /mnt/datasets

Що це значить: Root на 97%; ви в один лог‑шторм від креативних відмов додатків.

Рішення: Звільніть місце, обертайте логи або перемістіть гарячі шляхи запису з root. Потім поставте алерти на 80/90/95% з людиною на виклику.

Завдання 10: Перевірте втрати/повторні відправлення в мережі (бо розподілені конвеєри брешуть)

cr0x@server:~$ ip -s link show dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
      9876543210  8123456      0    1245       0       0
    TX:  bytes packets errors dropped carrier collsns
      8765432109  7345678      0       8       0       0

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

Рішення: Перевірте кільця NIC, конгестію коммутаторів, несумісність MTU або QoS. Не звинувачуйте додаток, поки пакети не поводяться як треба.

Завдання 11: Підтвердіть, що DNS і service discovery не є вузьким місцем

cr0x@server:~$ resolvectl statistics
DNSSEC supported by current servers: no
Transactions:               124812
Cache hits:                  98110
Cache misses:                26702
DNSSEC verdicts:                 0

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

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

Завдання 12: Слідкуйте за тиском пам’яті на рівні процесів і ризиком OOM

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           503Gi       462Gi        11Gi       2.1Gi        30Gi        18Gi
Swap:            0B          0B          0B

Що це значить: Лише 18Gi доступно на системі з 503Gi — ви на один сплеск від storms reclaim або OOM‑вбивств.

Рішення: Встановіть ліміти пам’яті, зменшіть кількість одночасних завдань, додайте swap (обережно) або масштабуйтесь горизонтально. Уникайте героїчних «просто дати більший бокс» без розуміння форми використання пам’яті.

Завдання 13: Перевірте сигнали тротлінгу ядра й pressure (сучасна реальність)

cr0x@server:~$ cat /proc/pressure/io
some avg10=0.58 avg60=1.21 avg300=0.98 total=23812811
full avg10=0.22 avg60=0.48 avg300=0.39 total=9123812

Що це значить: IO «full» pressure вказує на періоди, коли задачі блокуються на I/O. Це латентнісний податок для всієї системи.

Рішення: Зменшіть конкуренцію за I/O, ізолюйте навантаження або надайте більшу пропускну здатність. Не тюньте GPU‑ядра, поки ОС чекає сховище.

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

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
19211 zstd            612.3  1.2
18722 python3         288.7  3.8
 921  kswapd0          82.4  0.0
 741  nvme_poll_wq     31.0  0.0

Що це значить: Стиснення і reclaim споживають масивні CPU‑ресурси. Ваше «основне навантаження» конкурує з технічними роботами.

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

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

Тут ностальгія відмирає, а формується м’язова пам’ять.

1) Симптом: «У нас найшвидше залізо, але розробники ігнорують нас»

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

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

2) Симптом: «Ми випускаємо чудові продукти, але пропускаємо квартали»

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

Виправлення: Розбийте дорожню карту на менші поставки, впровадьте stage‑gate і вирівняйте запуск із ринковими вікнами. Часування — це вимога, а не побажання.

3) Симптом: «Партнери перестали штовхати наш продукт»

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

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

4) Симптом: «Бенчмарки гарні, а клієнти скаржаться на підлагування/вильоти»

Корінь: Борг сумісності драйверів. Довгий хвіст ігор/додатків карає вас.

Виправлення: Побудуйте лабораторію сумісності, пріоритезуйте топ‑навантаження, шліфуйте часті оновлення драйверів і інструментуйте телеметрію крашів. Робота з надійності — це продуктова робота.

5) Симптом: «Ми оптимізуємо витрати й стаємо повільніші»

Корінь: Фонова робота й компакти/обслуговування конфліктують з піковим попитом. Оптимізація змістила вузьке місце.

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

6) Симптом: «Усе було гаразд, а потім ми раптом не в грі»

Корінь: Конкурентний каденс і зміни платформи. Стандартний API дорослішає, OEM‑угоди рухаються, і ваша диференціація випаровується.

Виправлення: Слідкуйте за провідними індикаторами: прийняття розробниками, дизайн‑вінди OEM, частота драйверів, надійність постачання. Не чекайте, поки прибуток скаже вам правду.

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

Контрольний список 1: Якщо ви ставите на пропрієтарну технологію (пастка Glide)

1. Визначте план виведення вже з першого дня: як ви плавно перейдете на стандарти.
2. Щомісяця вимірюйте прийняття: кількість першокласних інтеграцій, не «зацікавленість».
3. Бюджетуйте роботу з сумісності як постійну команду, а не як штурм перед запуском.
4. Випустіть конформанс‑сьют, щоб партнери могли валідовувати без ваших благань.
5. Зробіть пропрієтарний шлях опціональним: стандартний API має залишатися відмінним.

Контрольний список 2: Якщо ви розглядаєте вертикальну інтеграцію (урок STB)

1. Перерахуйте партнерів, які втратять маржу при інтеграції; припустіть, що вони відреагують.
2. Вирішіть, чи готові ви їх втратити. Якщо ні — не інтегруйтеся.
3. Побудуйте модель постачання з сценаріями «пропущений квартал»; плануйте гроші відповідно.
4. Інвестуйте в QA‑пропускну здатність і аналіз відмов; інакше ви просто купили біль.
5. Комунікуйте рано й чітко; невизначеність породжує саботаж каналу.

Контрольний список 3: Операційний каденс для конкурентного апаратно‑пЗ/ПО стеку

1. Щотижневий реліз‑трейн драйверів/інструментів з canary і можливістю відкату.
2. Трекінг матриці сумісності: топ‑50 навантажень мають бути зеленими.
3. Дашборди продуктивності: медіана й p99, не лише пікові FPS/продуктивність.
4. Телеметрія постачання й виробництва: lead time, ризик виходу, ризик алокації.
5. Інцидент‑рев’ю, що закінчуються зміною способу релізу, а не лише PDF.

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

1. Змапуйте pipeline: розробник → SDK/API → драйвер → залізо → плата/OEM → роздріб/відвантаження. Позначте передачі.
2. Виберіть три провідні індикатори: цілі розробників, OEM‑design wins, рівень падінь драйверів.
3. Проведіть аудит каденсу: як часто ви шлете виправлення? Як часто конкурент?
4. Знайдіть горлечко: зазвичай не в силіконі. Це сумісність, постачання або довіра каналу.
5. Виправляйте шар за шаром: з’єднувати виправлення в «великий вибух» — як відтворити купу ризиків 3dfx.

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

3dfx програли тому, що NVIDIA мала «кращу технологію»?

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

Чи був Glide помилкою?

Спершу — ні. Це був прагматичний хід, що дав відмінний досвід, коли стандарти були недорозвинені. Помилка — зробити його постійним ровером замість тимчасової переваги.

Чому придбання STB так зашкодило?

Тому що воно змінило стимули. Партнери по платах, що раніше підсилювали 3dfx, тепер мусили конкурувати з ними. У апаратному бізнесі довіра каналу — це компонент ланцюга постачання.

Яку роль відігравав Direct3D у падінні?

Коли Direct3D дозрів, він зменшив цінність пропрієтарного API. Розробники могли таргетувати стандарт і все одно досягти більшості клієнтів з прийнятною продуктивністю.

Чи так сильно драйвери мали вагу в кінці 1990‑х?

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

Який урок SRE із провалу споживчої GPU‑компанії?

Енд‑ту‑енд надійність виграє ринки. Швидкий компонент у ненадійній системі не створює надійного продукту. Трактуйте дистрибуцію, інструменти і підтримку як перші класи виробничих залежностей.

Чи могла 3dfx вижити, лишившись лише виробником кристалів і не роблячи плат?

Можливо. Залишаючись чип‑онлі, вони б зменшили конфлікт у каналі і дозволили партнерам по платах продовжувати просувати продукт. Це не вирішило б усіх проблем, але прибрало б значну самопорану рану.

Вертикальна інтеграція завжди погана?

Ні. Вона потужна, коли ви можете виконувати виробництво, QA і дистрибуцію в масштабі. Вона шкідлива, коли її використовують, щоб «виправити» проблему каналу замість того, щоб вирішити стимули і каденс.

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

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

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

3dfx — застереження для кожної команди, яка вірить, що технічна досконалість автоматично перетворюється на ринкову владу. Це не так. Ні в GPU, ні в розподілених системах, ні в сховищі, ні в платформах.

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

1. Вимірюйте стан екосистеми: прийняття, сумісність і каденс. Якщо ви не можете цього порахувати — ви керуєте відчуттями.
2. Аудитуйте канал і стимули: партнери, внутрішні клієнти і суміжні команди. Якщо хтось втрачає, коли виграєте ви — колись вони вас приберуть.
3. Зробіть надійність критерієм релізу: стабільність драйверів, безпека оновлень, можливість відкату й передбачувані постачання/пропускна здатність. Швидкість без стабільності — просто швидкий шлях до падіння.

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