Загублені 2D-гіганти: Matrox, S3, Tseng — і чому вони мали значення

Що насправді означало «2D-прискорення» (і що воно давало)

До того, як кожен інтерфейс став композитною сценою, «робочий стіл» переважно складався з прямокутників. Прямокутники, заповнені пікселями. Прямокутники, що копіювалися з одного місця в інше. Прямокутники з відбитими текстовими гліфами.
Якщо ви могли виконувати ці операції швидко — і послідовно — ви перемагали. Ось що таке 2D‑прискорення: знімання нудних примітивів з CPU на спеціалізований контролер, який міг штовхати пікселі
без переговорів з кешами, прогнозувачами переходів чи чимось іншим, чим CPU вже жалкував.

Ключові примітиви були не гламурні:

• BitBLT (bit‑block transfer): копіювати прямокутник пікселів звідусіль куди‑небудь ще, часто з растровими операціями (ROP).
• Заливка суцільним кольором і патернами: швидко малювати прямокутники (фони вікон, виділення, елементи інтерфейсу).
• Малювання ліній і контурів прямокутників: кістяк ранніх віджетів UI.
• Апаратний курсор: невелика накладна площина, щоб вказівник залишався плавним навіть коли решта екрану зайнята.
• Шляхи прискорення тексту: кешовані гліфи і розгортання монохромних гліфів у кольорові пікселі для шрифтів.

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

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

Одна перефразована думка, що я тримаю на ментальному панелі приладів, належить Вернеру Фогелсу: «все ламається, тому проектуйте під відмову, а не робіть вигляд, що її не буде» (перефразована ідея).
2D‑гіганти це усвідомили. Вони будували карти і драйвери, які терпіли б дуже брудні реальні робочі столи.

Чому Matrox, S3 і Tseng стали стандартом 2D

Matrox: чітке зображення, дисциплінована інженерія і репутація «просто працює»

Matrox здобула прихильність від людей, яким важила якість зображення і стабільність: користувачі CAD, видавництва, трейдери з кількома екранами і IT‑команди, які мусили змусити все це працювати.
Їхні 2D‑движки були не тільки швидкими; вони були передбачуваними. Коли ти розгортаєш сотні чи тисячі робочих столів, передбачуваність — це продуктивність.

Matrox також ставився до цілісності сигналу як до важливої речі. Бо так воно й було. Аналоговий VGA не був «добрим» за замовчуванням; він був добрим, коли трасування плати, якість DAC і фільтрація не були відсторонь.
Ось чому люди пам’ятають Matrox як «чіткий». Вони цього не уявляли.

S3: тиха імперія всередині кожного бежевого боксу

S3 не завжди був предметом захоплення ентузіастів. S3 був найкращим другом OEM: компетентний 2D, широка сумісність, низька вартість і драйвери, що — більшість часу — не створювали тікетів у підтримці.
Якщо ви користувалися ПК в офісі 90‑х, є велика ймовірність, що S3 шарив ваші пікселі.

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

Tseng Labs: демон швидкості в DOS і ранньому Windows

Tseng — ім’я, що змушує старожилів усміхатися, бо серія ET4000 мала репутацію: вона була швидкою. Особливо в сценаріях DOS VGA/SVGA, де сира пропускна здатність і компактні кодові шляхи мали значення.
Сила Tseng полягала у вичавлюванні продуктивності з шини і підсистеми пам’яті так, що це відчувалося одразу в реальних навантаженнях.

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

Короткий жарт №1: ET4000 був такий швидкий в DOS, що деякі ігри, мабуть, намагалися подати скаргу в HR.

Конкретні історичні факти, що пояснюють хайп

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

1. Windows 3.x і ранній Windows 95 сильно покладалися на 2D‑прискорення через драйвери, які відвантажували GDI‑операції на карту (blit‑и, заливки тощо).
2. VESA BIOS Extensions (VBE стандартизували SVGA вищих роздільностей для DOS‑ера софту, але якість реалізації все одно відрізнялася між картами.
3. Лінійка ET4000 від Tseng стала відомою завдяки високій пропускній здатності SVGA у час, коли ефективність шини і таймінги пам’яті часто важили більше за «фічі».
4. Сімейство Trio від S3 інтегрувало RAMDAC і інші функції, щоб знизити вартість і складність плати — ідеально для масових OEM‑впроваджень.
5. Плати Matrox ери Millennium отримали високу оцінку за якість аналогового виходу, коли CRT робили шум сигналу дуже помітним (мерехтіння тексту, розтікання кольорів, нечіткі контури).
6. 2D‑движки зазвичай підтримували широкий набір растрових операцій (ROP), бо фреймворки UI покладалися на них для ефектів, схожих на композитинг, ще до появи справжнього композитингу.
7. Апаратні курсори важили більше, ніж визнають: плавний вказівник маскував багато проблем із затримкою інтерфейсу й знижував сприйняту латентність.
8. Переходи PCI проти ISA/VLB змінили список переможців, бо вузьке місце перейшло від GPU‑ядра до мастерінгу шини і поведінки пам’яті.
9. Ранні мульти‑моніторні конфігурації були нішевими і ламкими; вендори, які могли робити це надійно (або хоча б з адекватними драйверами), здобували лояльність від цінних користувачів.

Зверніть увагу, чого тут немає: рейтрейсингу. Ніхто про нього не думав. Людям було потрібно, щоб Excel прокручувався не як фліпбук.

Незахоплююча інженерія: пропускна здатність, blits, курсори й шрифти

2D — це переважно пропускна здатність пам’яті і поведінка шини

Типова 2D‑операція — це проблема переміщення пам’яті. Скопіювати цей прямокутник. Заповнити той прямокутник. Розгорнути монохромні гліфи в кольорові пікселі.
Обмеження часто полягає в тому, наскільки швидко можна читати і записувати пам’ять фреймбуфера і наскільки ефективно це робиться по системній шині.

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

Драйвери були половиною продукту

В еру 2D драйвер був по суті обіцянкою: «коли ОС попросить BitBLT з цим ROP, я не розмажу екран, не протечу дескриптори і не заблокуємо UI‑потік».
Деякі вендори були просто кращими у виконанні цієї обіцянки за різних дивних поведінок додатків і при тривалій роботі.

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

Апаратний курсор: маленька фіча з величезним операційним ефектом

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

Рендеринг шрифтів був фічею продуктивності

В офісах не тестують трикутники. Вони рендерять шрифти. Дуже багато. Кешування гліфів і прискорення розгортання монохромних гліфів робили ранні GUI відчутно швидкими.
І тут важила «стабільність виходу»: один баг у кеші гліфів міг зробити один додаток нечитаємим і породити тиждень тікетів.

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

Чому вони згасли (і чому це не те ж саме, що «вони зазнали поразки»)

2D‑гіганти не зникли, бо забули малювати прямокутники. Вони згасли, бо ринок змінив визначення «достатньо добре» і зсунув пул прибутків.
Як тільки 3D стало фічею, яка продавала ПК — і як тільки інтегровані графіки стали «досить» для 2D — конкурентна перевага перемістилася.

Декілька сил зробили важку роботу:

• 3D API та попит на ігри: споживачі купували кадри в секунду, а не чистий VGA‑вихід.
• Консолідація OEM: об’ємні угоди на користь вендорів з інтегрованими чипсетами й тісними платформними стосунками.
• Складність драйверів зросла: композитинг, декодування відео, управління живленням і підключення кількох дисплеїв примножили режими відмов.
• «Достатньо хороший» 2D став невидимим: коли все компонується, ви припиняєте помічати 2D‑досконалість, поки вона не зникне.

Matrox повернулася до ніш (мультидисплеї, вбудовані рішення, індустріальні застосунки). Бренд S3 жив у різних формах. Tseng не пережив перехід у пізньо‑90‑ті гонку 3D.
Це не моральна поразка; це жорстока фізика переходів платформи.

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

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

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

Середня компанія оновила парк десктопних робочих станцій, які використовували для бек‑офісних операцій: ERP‑екрани, RDP‑сесії й самописний Java‑додаток, що дуже агресивно перемальовувався.
Закупівля стандартизувала на сучасній інтегрованій GPU‑платформі. На папері — явний виграш: достатньо обчислень, сучасні кодеки й «очевидно» краще за десятирічну дискретну карту.

Через тиждень черга тікетів наповнилася дивною скаргою: «Миша відчувається липкою». Не лагкою. Липкою. Оператори повідомляли, що не можуть надійно клікати дрібні елементи UI.
Тим часом використання CPU було низьким, RAM — в надлишку. IT спочатку звинуватили Java‑додаток, бо так роблять, коли хочуть, щоб проблема зникла.

Хибним припущенням було те, що інтегрована GPU завжди працюватиме з увімкненими правильними шляхами прискорення. Насправді образ був задеплойований з консервативним пакетом драйверів.
При певних EDID моніторів і док‑станцій стек переключався в режим сумісності, який вимикав апаратний курсор і примушував частини UI рендеритись програмно.

Виправлення не було героїчним: підтвердити правильну версію драйвера, переконатися, що DRI і modesetting активні, і стандартизувати прошивку док‑станції.
Важливим був культурний елемент: вони оновили чекліст розгортання, щоб включити комбінації периферії (док + монітор) як першочергові тест‑кейси.

Операційний урок: не припускайте, що «новіший GPU» означає «кращий 2D‑досвід». В продакшені стек — це продукт: прошивка, драйвер, композитор, протокол віддаленого доступу і монітори.

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

Інша організація тримала VDI‑середовище, де тонкі клієнти відображали Windows‑десктопи через віддалений протокол. Хтось помітив, що ввімкнення певної «візуальної» налаштування в шаблоні VDI
зменшило середнє навантаження CPU на хості. Графіки виглядали добре. Зміна була затверджена.

Через два тижні хелпдеск почав отримувати скарги на «випадково розмитий текст» і «прокрутка перетворюється на кашу».
Проблема була непостійною; вона з’являлася в пікові години і здебільшого у користувачів з кількома моніторами. Графіки CPU все ще виглядали добре, що робило проблему ще дратівливішою.

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

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

Урок: оптимізації, що покращують метрику, можуть знищити фактичну роботу користувача. Якщо ваші «перемоги» вимагають, щоб користувачі перестали читати текст, ви не перемогли.

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

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

Одного ранку вендор випустив рутинне оновлення ОС, яке також оновило компонент графіки. Кілька пілотних машин встановили його вночі.
О 9:05 пілоти повідомили про тонку, але смертельну проблему: вікна інколи перемальовувалися чорною на долю секунди під час швидкого переключення вікон.
Не краш. Достатньо, щоб оператори почали не довіряти тому, що бачать.

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

Нічого героїчного не сталося. Ось у чому суть. Нудна практика запобігла інциденту з бізнес‑наслідками, не створивши більшого інциденту через панічні експерименти.

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

Коли хтось каже «робочий стіл повільний», вам потрібен дисциплінований підхід. Не ганяйтесь за відчуттями. Знайдіть вузьке місце.

Перше: це локальне рендеринг, віддалене рендеринг чи USB‑тип рендерингу (display‑link)?

• Якщо це віддалене (RDP/VDI), вузьке місце може бути в пропускній здатності, кодуванні, серверній композиції або декоді на клієнті.
• Якщо це USB‑графіка/доки, ви можете бути завантажені CPU через стиснення і транспорт.
• Якщо локальне — переходьте до перевірок GPU/драйвера/композитора.

Друге: чи ми фактично використовуємо апаратне прискорення?

• Підтвердіть, який ядровий драйвер в роботі (modesetting/i915/amdgpu/nouveau/nvidia тощо).
• Підтвердіть, що DRI активний і рендерер не «llvmpipe» (програмний).
• Перевірте, чи апаратний курсор увімкнений; заїкання курсора — показник.

Третє: чи система голодна (CPU, пам’ять, I/O), чи це специфічно графічний шлях?

• Високий CPU під час прокрутки часто означає програмний рендеринг або наклад віддаленого кодування.
• Великі page fault‑и або активність сваппінгу роблять будь‑який UI жахливим.
• Фіксована частота GPU (енергозбереження) може імітувати «поганий GPU».

Четверте: мульти‑монітор і високий DPI змінюють гру

• Більше пікселів — більше пропускної здатності і більші області перерисовки.
• Несумісні частоти оновлення можуть спричиняти тремтіння і дивне погодження кадрів.
• Доки й адаптери додають режими відмов (EDID, обмеження пропускної здатності, особливості формату кольору).

П’яте: валідуйте відтворюваний мікротест

• Тест переміщення/зміни розміру вікна, прокрутки тексту і відстеження курсора — базові, але показові.
• Фіксуйте логи одразу після відтворення; не чекайте «пізніше».

Практичні завдання: команди, виводи, що вони означають і яке рішення приймати

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

Завдання 1: Ідентифікуйте GPU і який драйвер прив’язаний

cr0x@server:~$ lspci -nnk | grep -A3 -E "VGA|3D|Display"
01:00.0 VGA compatible controller [0300]: Matrox Electronics Systems Ltd. MGA G200eW WPCM450 [102b:0534]
	Subsystem: Super Micro Computer Inc Device [15d9:0834]
	Kernel driver in use: mgag200
	Kernel modules: mgag200

Значення: У вас пристрій Matrox класу G200, зв’язаний з mgag200. Це серверний шлях, орієнтований на 2D.

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

Завдання 2: Перевірте, чи випадково ви запускаєте програмний рендеринг (Mesa llvmpipe)

cr0x@server:~$ glxinfo -B | egrep "OpenGL renderer|OpenGL vendor|OpenGL version"
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 15.0.7, 256 bits)
OpenGL version string: 4.5 (Compatibility Profile) Mesa 23.0.4

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

Рішення: Стоп. Виправте DRI/драйвер/композитор так, щоб рендерер мав апаратну опору, або прийміть вищий CPU і налаштуйте відповідно.

Завдання 3: Підтвердіть, що Xorg використовує очікуваний драйвер і метод прискорення

cr0x@server:~$ grep -E "Driver|Acceleration|glamor|DRI" /var/log/Xorg.0.log | tail -n 20
[    18.224] (II) modeset(0): using drv /dev/dri/card0
[    18.224] (II) modeset(0): glamor X acceleration enabled on Mesa DRI Intel(R) UHD Graphics 630
[    18.226] (II) modeset(0): glamor initialized
[    18.241] (II) modeset(0): [DRI2] Setup complete

Значення: Xorg використовує modesetting з glamor‑прискоренням і DRI2 увімкнений.

Рішення: Якщо ви бачите «falling back to shadowfb» або «glamor failed», очікуйте поганої 2D‑продуктивності і розслідуйте відсутні пакети або несумісні драйвери.

Завдання 4: Перевірте композитор і тип сесії (Wayland vs X11)

cr0x@server:~$ echo "$XDG_SESSION_TYPE"
wayland

Значення: Ви на Wayland. Дебаг переміщується до композитора (GNOME Shell, KDE KWin тощо) і DRM/KMS.

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

Завдання 5: Перегляньте повідомлення ядра DRM про modesetting і проблеми лінку

cr0x@server:~$ dmesg -T | egrep -i "drm|i915|amdgpu|nouveau|edid|hdmi|dp" | tail -n 30
[Tue Jan 13 08:41:02 2026] [drm] Initialized i915 1.6.0 20201103 for 0000:00:02.0 on minor 0
[Tue Jan 13 08:41:03 2026] i915 0000:00:02.0: [drm] fb0: i915drmfb frame buffer device
[Tue Jan 13 08:41:05 2026] [drm:intel_dp_start_link_train] *ERROR* failed to train DP, aborting

Значення: Драйвер GPU працює, але тренування лінку DisplayPort не вдалося — класична проблема переговорів дока/кабеля/монітора.

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

Завдання 6: Перевірте частоти оновлення і режими для кожного монітора

cr0x@server:~$ xrandr --verbose | egrep -A2 " connected|^\s+([0-9]{3,4}x[0-9]{3,4})"
DP-1 connected primary 3840x2160+0+0 (0x4b) normal (normal left inverted right x axis y axis) 597mm x 336mm
  3840x2160 (0x4b) 533.250MHz +HSync -VSync *current +preferred
HDMI-1 connected 1920x1080+3840+0 (0x5c) normal (normal left inverted right x axis y axis) 509mm x 286mm
  1920x1080 (0x5c) 148.500MHz +HSync +VSync *current +preferred

Значення: Змішані роздільності. Це збільшує вартість композиції і може виявити баги масштабування.

Рішення: Якщо користувачі скаржаться на застригування, протестуйте узгоджені частоти й налаштування масштабу; змішаний DPI часто викликає «джанґл».

Завдання 7: Перевірте завантаження CPU під час «2D» дій

cr0x@server:~$ pidstat -u -p ALL 1 5
Linux 6.5.0 (server) 	01/13/2026 	_x86_64_	(8 CPU)

08:52:10      UID       PID    %usr %system  %CPU  Command
08:52:11     1000      2123   85.00    8.00 93.00  gnome-shell
08:52:11     1000      2788   12.00    2.00 14.00  Xwayland

Значення: gnome‑shell жере CPU. Це часто означає програмний відкат, важкі ефекти або взаємодію драйвер/композитор.

Рішення: Зменште анімації/ефекти, протестуйте інші налаштування композитора і підтвердіть апаратне прискорення (Завдання 2/3).

Завдання 8: Перевірте тиск пам’яті і сваппінг

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
 2  0      0 512000  82000 890000    0    0    12    20  410  900 12  4 84  0  0
 3  1  65536  48000  61000 210000    0  800   100   220 1200 2400 20  8 60 12  0

Значення: Активний swap‑out (so); зростає CPU wait (wa). UI‑джанк може бути простим тиском пам’яті.

Рішення: Додайте RAM, зменште навантаження або виправте витік пам’яті. Не звинувачуйте GPU за те, що зробив пейджер.

Завдання 9: Перевірте використання GPU і частоту (приклад Intel)

cr0x@server:~$ sudo intel_gpu_top -s 1000 -o - | head -n 12
freq  350 MHz  GPU  12%  RC6  75%  RCS  10%  BCS  2%  VCS  0%  VECS  0%
IMC reads:  820 MiB/s  IMC writes:  210 MiB/s

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

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

Завдання 10: Підтвердіть активний енергопрофіль (ноутбуки і деякі десктопи)

cr0x@server:~$ powerprofilesctl get
power-saver

Значення: У вас режим power‑saver. Це може обмежувати GPU/CPU і породжувати «загадкову» повільність.

Рішення: Переключіться на balanced/performance для важливих ролей (трейдери, дизайнери) або свідомо прийміть компроміс.

Завдання 11: Санітарна перевірка віддалених сесій (RDP і мережеві обмеження)

cr0x@server:~$ ss -ti dst :3389 | head -n 12
ESTAB 0 0 10.10.8.21:52144 10.10.20.15:3389
	 cubic wscale:7,7 rto:204 rtt:42.1/8.2 ato:40 mss:1448 pmtu:1500 rcvmss:1448 advmss:1448 cwnd:22 bytes_sent:1849021 bytes_acked:1849010
	 retrans:12/45 lost:0 sacked:0

Значення: Є ретрансляції. Це часто переводиться у візуальні артефакти, затримку і «липку» взаємодію у віддалених десктопах.

Рішення: Виправте мережу (Wi‑Fi, перевантаження, QoS). Не налаштовуйте UI‑ефекти, поки не припините втрату пакетів.

Завдання 12: Заміряйте помилки базового дисплейного конвеєра і поведінку page flip (DRM)

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/i915_display_info | head -n 20
CRTC info
  CRTC 0: active=yes (pipe A)
    output types: DP
    plane 0: enabled, fb=197, visible=3840x2160
    flip_pending=no

Значення: Дисплейний конвеєр активний і фліпи не застрягли в очікуванні. Якби ви бачили повторювані flip_pending або помилки, підозрівав биа композитор або драйвер/лінк.

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

Завдання 13: Перевірте проблеми шляху рендерингу X11 через stderr логи (Xwayland / Xorg)

cr0x@server:~$ journalctl --user -b | egrep -i "xwayland|glamor|failed|dri" | tail -n 30
Jan 13 08:51:44 server Xwayland[2788]: glamor: Failed to initialize EGL.
Jan 13 08:51:44 server Xwayland[2788]: AIGLX: reverting to software rendering

Значення: Xwayland відкотився до програмного рендерингу. Легасі X11‑додатки тягнутимуть сесію вниз.

Рішення: Виправте стек EGL/драйвер або запустіть X11‑сесію, якщо ваша робота тяжіє до X11.

Завдання 14: Перевірте наявність USB‑адаптерів дисплея (DisplayLink), що зміщують вузьке місце на CPU

cr0x@server:~$ lsusb | egrep -i "displaylink|graphics|dl-|evdi"
Bus 002 Device 004: ID 17e9:6006 DisplayLink USB Graphics Device

Значення: Ви використовуєте DisplayLink‑тип рендерингу. Це може працювати, але це не «безкоштовний GPU».

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

Завдання 15: Швидка перевірка ширини/швидкості лінку PCIe (так, це може мати значення)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i "LnkCap|LnkSta"
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L1
LnkSta: Speed 2.5GT/s, Width x4

Значення: Пристрій здатний на x16 при 8GT/s, але зараз працює на x4 2.5GT/s. Це значне падіння пропускної здатності.

Рішення: Пересадіть карту, перевірте налаштування BIOS і розводку слота. Не оптимізуйте софт поверх crippled шини.

Завдання 16: Зробіть знімок «відомо‑добрий» для порівняння (нудний інструмент, що перемагає)

cr0x@server:~$ sudo inxi -Gxxx --filter
Graphics:
  Device-1: Intel UHD Graphics 630 driver: i915 v: kernel
  Display: wayland server: Xwayland v: 23.2.2 compositor: gnome-shell
  resolution: 3840x2160~60Hz, 1920x1080~60Hz
  OpenGL: renderer: Mesa Intel UHD Graphics 630 (CFL GT2) v: 4.6 Mesa 23.0.4

Значення: Компактний знімок GPU, драйвера, дисплейного сервера й GL‑рендера.

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

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

1) Курсор заїкається, але CPU виглядає нормально

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

Корінна причина: Апаратний курсор вимкнений або не працює; шлях програмного курсора прив’язаний до часу перерисовки/композитора.

Виправлення: Підтвердіть підтримку драйвера і композитора, перевірте проблеми з доком/EDID, протестуйте інший тип сесії (X11 vs Wayland) і переконайтеся, що немає відкату до програмного рендерингу.

2) Прокрутка тексту рветься або «розмазується»

Симптом: Прокрутка в терміналі/браузері показує розриви або часткову перерисовку.

Корінна причина: Композитор неправильно використовує vsync, змішані частоти оновлення або пошкоджений шлях прискорення (glamor/EGL відкат).

Виправлення: Узгодьте частоти оновлення де можливо, оновіть прошивку GPU/дока і підтвердіть налаштування композитора; перевірте логи на glamor/EGL‑фолбеки.

3) Високий CPU під час переміщення вікон

Симптом: Переміщення вікон викликає стрибок CPU; вентилятори гудіють; метрики GPU здаються холостими.

Корінна причина: Програмний рендеринг (llvmpipe) або віддалений/USB‑графічний шлях з кодуванням на CPU.

Виправлення: Виправте DRI і пакети драйверів; для віддалених сесій налаштуйте протокол і пропускну здатність; для DisplayLink бюджетуйте CPU або використовуйте нативні виходи.

4) Все добре, поки не підключать другий монітор

Симптом: Додавання монітора викликає джанк, чорні спалахи або переривчасті відключення.

Корінна причина: Обмеження пропускної здатності (DP/HDMI режим), нестабільне тренування лінку, прошивка дока або несумісні налаштування масштабу.

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

5) Віддалений робочий стіл стає «розмитим» під навантаженням

Симптом: Текст стає м’яким або блочним у пікові години.

Корінна причина: Адаптивне стиснення/зниження якості в віддаленому протоколі через втрату пропускної здатності або ретрансляції.

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

6) Випадкові чорні прямокутники під час перерисовки додатка

Симптом: Короткі чорні спалахи або відсутні області під час швидкого перемикання вікон.

Корінна причина: Регресія драйвера або баг композитора в відстеженні пошкоджень/page flipping.

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

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

Покроково: діагностуйте «повільний робочий стіл» без шалених змін

1. Класифікуйте середовище: локальний GPU vs VDI/RDP vs USB‑графіка. Задокументуйте це в тікеті.
2. Заберіть ідентичність бази: inxi -Gxxx, lspci -nnk, тип сесії, макет моніторів.
3. Перевірте на програмний рендеринг: glxinfo -B renderer. Якщо llvmpipe — зупиніться і виправте це першочергово.
4. Перегляньте ядро і логи дисплея: dmesg на предмет тренування лінків і помилок DRM.
5. Підтвердіть режими моніторів: xrandr --verbose для оновлень і невідповідностей масштабу.
6. Заміряйте системний тиск: CPU (pidstat), пам’ять (vmstat), і для віддалених сесій — ретрансляції (ss -ti).
7. Відтворіть мінімальним тестом: прокрутка тексту, переміщення вікна, відстеження курсора, перетягування між моніторами.
8. Робіть одну зміну за раз: версія драйвера, тип сесії, прапорці композитора або частота оновлення. Записуйте результат.
9. Стабілізуйте і стандартизуйте: зафіксуйте версії і документуйте відомо‑добрі комбінації (GPU + драйвер + док + монітор).

Чеклист для розгортання: не повторюйте помилок 1997 року з апаратурою 2026

• Тримайте протестований набір GPU‑драйверів зафіксованим для кожного класу заліза.
• Тестуйте з реальними периферіями: доки, адаптери і ті монітори, що люди дійсно мають.
• Відстежуйте типи сесій за замовчуванням (Wayland/X11) і знайте, які додатки де ламаються.
• Майте план відкату, що не потребує героїчних віддалених логінів, коли UI зламаний.
• Встановіть критерії прийнятності «читабельності тексту» для віддалених десктопів, а не лише FPS.
• Задокументуйте політику енергопрофілів; не дозволяйте ноутбукам поставлятися у сталому power‑saver для ролей з високою взаємодією.

Що запозичити з мислення Matrox/S3/Tseng (навіть якщо ви ніколи не торкаєтеся старого заліза)

• Пріоритетність нудної коректності: стабільний, детермінований шлях перевершує швидкий шлях з рідкісними корупціями.
• Оптимізуйте цикл сприйняття: апаратний курсор і передбачувана перерисовка важать більше за пікову пропускну здатність.
• Поважайте рівні сигналу і переговорів: EDID, тренування лінків і кабелі — це частина «продуктивності графіки».
• Будуйте для поведінки флоту: ваша найкраща машина — не метрика; важливі ваші гірші 5%.

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

1) Чи були Matrox, S3 і Tseng «кращими» за сучасні GPU?

У сирій потужності — ні. У передбачуваній 2D‑поведінці під стеками їхньої епохи — часто так.
Вони були оптимізовані під домінуючі навантаження: GDI/X11‑примітиви, стабільні курсори і послідовний вихід.

2) Чому люди пам’ятають вихід Matrox як більш чіткий?

Якість аналогового VGA залежала від трасування плати, якості RAMDAC, фільтрації і електричного дизайну. Деякі вендори ставили це як фічу першої величини.
На CRT різниця була очевидна: менше мерехтіння, чіткіші краї тексту.

3) Чим S3 був таким популярним в офісах?

Дружністю до OEM: низька вартість, інтегровані функції, широка сумісність і драйвери, що працювали через величезний спектр бізнес‑програм.
Це виграє тендери й знижує кількість тікетів у підтримці.

4) Що сучасне відповідає «2D‑прискоренню»?

Продуктивність композитора, відстеження пошкоджень (damage tracking), ефективний swap буферів і надійні GPU/дисплейні драйвери. Примітиви змінили форму, але задача лишається:
передавати пікселі передбачувано і з низькою латентністю.

5) Якщо в мене Wayland, чи я все ще маю турбуватися про 2D‑проблеми?

Так. Wayland змінює місце, де проявляються проблеми (композитор/DRM замість Xorg), але ви все ще можете потрапити на програмний відкат, погані стани енергозбереження, нестабільність лінків і проблеми синхронізації мульти‑екранів.

6) Чому апаратний курсор так важливий?

Бо він відокремлює зворотний зв’язок вказівника від решти конвеєра рендерингу. Люди судять про чутливість за вказівником.
Плавний курсор може зробити повільний робочий стіл терпимим; повільний курсор робить усе відчутно зламаним.

7) Як швидко визначити, чи «графіка повільна» через тиск пам’яті?

Запустіть vmstat 1 5. Якщо ви бачите активність swap‑in/swap‑out і зростаючий I/O wait, ваш UI конкурує з пейджером.
Виправте RAM або навантаження перш ніж налаштовувати стек GPU.

8) Яка найпоширеніша сучасна причина «2D виглядає погано» на пристойному залізі?

Відкат на програмний рендеринг (llvmpipe) — на першому місці, а дуже близько слідом — проблеми переговорів дока/монітора, що викликають нестабільні лінки або дивні режими оновлення/масштабування.
Обидва виявляються швидко за допомогою вищенаведених завдань.

9) Чи варто примусово використовувати X11, бо «воно швидше»?

Не робіть це догматично. Тестуйте. Деякі робочі навантаження і драйвери працюють краще на X11; інші плавніші на Wayland.
Оберіть тип сесії, що дає передбачувану поведінку для вашого набору додатків і флоту заліза.

10) Чому 2D‑гіганти навчили нас про надійність?

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

Наступні кроки

Якщо ви керуєте флотами — десктопами, VDI, тонкими клієнтами, торговими станціями, лабораторіями — візьміть урок у Matrox/S3/Tseng і застосуйте його там, де болить сьогодні:
базовий цикл взаємодії.

1. Побудуйте відомо‑добру графічну базу для кожного класу заліза (GPU + драйвер + док + монітор).
2. Автоматизуйте збір inxi -Gxxx, lspci -nnk, тип сесії і режими моніторів під час провізіонінгу.
3. Розгортайте графічні зміни по кільцях (драйвери, оновлення композитора, прошивка дока). Тримайте відкат детермінованим.
4. Використовуйте швидкий план діагностики, коли приходять тікети. Класифікуйте спочатку, потім вимірюйте, потім змінюйте по одному.
5. Визначте SLO, видимі для користувача: плавність курсора, читабельність тексту в віддалених сесіях і стабільність мульти‑моніторів. Не лише «використання GPU».

2D‑гіганти мали значення, бо вони ставили «намалювати вікно» як місію критичну. Ви теж повинні. Це не ретро. Це операції.