Оновлення вкрали мої FPS: міф, реальність і нудна правда

Міф і реальність: коли оновлення дійсно заважають

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

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

Кошик 1: реальні регресії (так, вони трапляються)

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

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

Кошик 2: «ефекти прогріву» (кеші шейдерів і компіляція пайплайнів)

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

Якщо скарга — «заїки, а не зниження середнього FPS», думайте спочатку про кеші. Якщо «середній впав на 20%», шукайте іншу причину.

Кошик 3: скиди налаштувань і приховані перемикання

Оновлення люблять скидати налаштування. Ігри, драйвери й ОС роблять це. Ваш масштаб роздільності змінився. Увімкнувся трасування променів. План живлення скинувся на «збалансований». Драйвер GPU вирішив, що вам підходить «optimal power».

Це найпоширеніша «регресія», бо насправді не є регресією. Це амнезія.

Кошик 4: пом’якшення безпеки й зміни ядра

Деякі апдейти навмисно знижують продуктивність, особливо заходи безпеки для проблем спекулятивного виконання. Вплив сильно відрізняється в залежності від навантаження. Для багатьох ігор вплив невеликий; для певних CPU-інтенсивних тайтлів чи двигунів з великою кількістю системних викликів — він може бути помітним.

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

Кошик 5: фонові завдання, яких ви не просили

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

Кошик 6: плацебо уваги

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

Люди відмінно відчувають дискомфорт і вкрай погано проводять контрольовані експерименти. Ваш GPU байдужий до вражень.

Цитата, щоб бути чесним із собою: ідея Пітера Друкера (парафраз): те, що не вимірюєш, не можеш керувати. Вимірювання — це те, що зупиняє суперечки з вашою пам’яттю.

Що насправді змінюють патчі (і чому FPS крихкий)

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

Ігри: контент, шейдери та CPU-робота

Патчі ігор можуть змінювати:

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

Драйвери: зміни компілятора й поведінки живлення

Драйвери GPU — це по суті компілятори плюс планувальник і менеджер потужності. Оновлення драйвера може:

• змінити вихід компіляції шейдерів для конкретних ігор (інколи швидше, інколи ні);
• модифікувати поведінку boost-годинників за певних теплових або енергетичних умов;
• скидати профілі для конкретних ігор, включаючи лімітери кадрів та режими низької затримки;
• змінювати спосіб збереження й повторного використання кешів пайплайнів DX12/Vulkan.

Оновлення ОС: ядро, планувальник і «корисні» служби

Оновлення ОС можуть змінювати планування, об’єднання таймерів, обробку page fault, шляхи файлової системи, політики стиснення пам’яті та заходи безпеки. Навіть якщо сукупні витрати невеликі, вони можуть проявитись як нестабільність часу кадру — особливо на процесорах, що вже працюють на межі.

А потім є нудна річ: патч запустив фонове сканування диска, яке насичує чергу SSD, і від цього затримуються стріми ресурсів — от і стутер. Це не «регресія графіки». Це черга зберігання, що каже «ні».

Жарт №1: Патч не «вкрав» ваш FPS; він просто «перерозподілив» його у відділ фонової індексації.

Ментальна модель: знайдіть найдовший кілок у мішку кадру

Кожен кадр має бюджет. При 60 FPS у вас 16.67 мс. При 120 FPS — 8.33 мс. Перевищте бюджет — і ви отримуєте підлагування, пропущені кадри або те й інше.

Питання не в тому «чи знизився FPS після патчу?» Питання: «яка стадія тепер перевищує бюджет?» Головний потік CPU? Потік рендерингу? GPU? Диск I/O? Накладні витрати драйвера? Переривання/DPC? Тротлінг через температуру?

Інженерія продуктивності — це переважно відмова: відмова гадати, відмова ганятися за примарами, відмова виправляти те, чого ви не виміряли.

Цікаві факти й історичний контекст (те, що люди забувають)

• Пом’якшення безпеки може бути помітним: після 2018 року заходи проти спекулятивного виконання (наприклад, для Spectre/Meltdown) ввели реальні накладні витрати при переходах користувач/ядро та в IO-інтенсивних сценаріях, і деякі робочі навантаження це помітили.
• Затримки через компіляцію шейдерів — це стара проблема: вона існувала задовго до сучасних API; нові пайплайни просто частіше призводять до її прояву при інвалідації кешів або зміні codegen від драйвера.
• Рівномірність кадрів важить більше за середній FPS: багато рушіїв «відчуваються» гірше після змін, які збільшують варіативність, навіть якщо середнє лишається подібним. Метрика 1% low стала загальноприйнятою не випадково.
• Оновлення Windows можуть скидати плани живлення: функціональні оновлення та деякі інсталяції драйверів часто повертають план живлення або налаштування GPU за замовчуванням, особливо на ноутбуках.
• Драйвери містять профілі для ігор: обидва великі вендори GPU підтримують оптимізації під конкретні тайтли; оновлення можуть допомогти одній грі і нашкодити іншій через евристики та зміни компілятора.
• DX12/Vulkan змістили роботу до додатка: менші накладні витрати драйвера — це обіцянка, але вона також означає, що ігри можуть компілювати пайплайни в незручні моменти, якщо це не було враховано в архітектурі.
• Зберігання стало швидшим, очікування — вищими: NVMe скоротив час завантаження, але це підштовхнуло до агресивнішого стрімінгу. Коли відбуваються глюки з диском, їх видно краще, бо конвеєр став щільнішим.
• Античит заглибився в систему: дедалі більше тайтлів використовують компоненти в режимі ядра. Вони можуть взаємодіяти з драйверами та засобами безпеки, іноді створюючи шум планування або контенцію.
• Фонове «обслуговування» — не новина: індексація, оновлення та сканування завжди були, але сучасні системи роблять це автоматично й частіше.

Швидка діагностика — покрокова схема

Ось порядок дій, яким я користуюсь, коли хтось каже «патч вбив продуктивність», і мені треба відповідь за 15 хвилин, а не вихідні.

Перше: класифікуйте проблему (середній FPS vs стутер vs затримка)

• Середній FPS впав: ймовірно стійке вузьке місце (GPU-bound, CPU-bound, енергетичне/теплове обмеження, нове навантаження).
• Стутер / сплески часу кадру: ймовірно компіляція, стрімінг ресурсів, пейджинг, фоновий I/O, проблеми DPC драйвера.
• Введення відчувається затриманим: може бути через зміни ліміту кадрів, vsync, глибину черги рендерингу, перемикання режимів низької затримки або насичення CPU.

Друге: перевірте, що змінилось (налаштування, драйвери, живлення)

1. Перевірте, що графічні налаштування гри не скинулись (масштаб роздільності, RT, DLSS/FSR, ліміти кадрів).
2. Підтвердіть зміну версії драйвера GPU (і чи скинувся профіль для гри).
3. Підтвердіть, що план живлення ОС не скинувся. На ноутбуках також перевірте, чи ви не на батареї в низькому TDP-режимі.

Третє: ідентифікуйте вузьке місце одним оверлеєм і одним графіком

Використайте інструмент, що показує час GPU, час кадру CPU та використання VRAM/RAM, плюс графік часу кадру. Якщо час GPU вищий за CPU — обмеження по GPU. Якщо CPU вищий — по CPU. Якщо сплески часу кадру корелюють з дисковим I/O або page fault — це стрімінг/пейджинг.

Четверте: усуньте фоновий шум

Після оновлення дайте системі побути простою 10–20 хвилин, підключіть живлення, залиште екран увімкненим, щоб завершились індексації/скани. Потім протестуйте ще раз. Якщо продуктивність «чарівно» повернулась — ви нічого не виправили; ви просто перечекали обслуговування.

П’яте: відтворіть з стабільним тестом

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

Шосте: тільки тоді звинувачуйте патч

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

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

Це реальні перевірки, які я запускаю на Linux-геймінг-боксі або робочій станції з GPU-навантаженнями. На Windows ідеї ті самі, але команди будуть інші. Мета — припинити гадати й почати звужувати причину.

Завдання 1: Підтвердити збірку ядра та ОС (чи ми дійсно патчили?)

cr0x@server:~$ uname -a
Linux cr0xbox 6.5.0-14-generic #14~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

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

Рішення: Якщо продуктивність змінилась одразу після оновлення ядра — протестуйте попереднє ядро з меню завантажувача або інсталюйте LTS-ядро для порівняння.

Завдання 2: Перелік останніх оновлень пакетів (що змінилось вночі)

cr0x@server:~$ grep " upgraded " /var/log/dpkg.log | tail -n 8
2026-01-09 03:12:10 upgraded linux-image-6.5.0-14-generic:amd64 6.5.0-13.13~22.04.1 6.5.0-14.14~22.04.1
2026-01-09 03:12:12 upgraded linux-modules-6.5.0-14-generic:amd64 6.5.0-13.13~22.04.1 6.5.0-14.14~22.04.1
2026-01-09 03:12:20 upgraded nvidia-driver-550:amd64 550.54.14-0ubuntu0.22.04.1 550.67-0ubuntu0.22.04.1
2026-01-09 03:12:35 upgraded mesa-vulkan-drivers:amd64 24.0.5-1~22.04.2 24.0.6-1~22.04.2

Що це означає: Конкретні докази змін: ядро, драйвер NVIDIA, Mesa Vulkan.

Рішення: Якщо оновились і ядро, і стек GPU — ізолюйте: залиште ядро незмінним і поміняйте версію драйвера (або навпаки). Не налагоджуйте дві змінні одночасно.

Завдання 3: Перевірити драйвер GPU та стан рантайму (чи здоровий драйвер?)

cr0x@server:~$ nvidia-smi
Sat Jan 10 12:18:44 2026
+-----------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.67                 Driver Version: 550.67         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  NVIDIA GeForce RTX 4070        Off | 00000000:01:00.0   On  |                  N/A |
| 30%   54C    P2              85W / 200W |    2100MiB / 12282MiB  |     12%      Default |
+-----------------------------------------+------------------------+----------------------+

Що це означає: Версія драйвера, стани тактових частот/перформансу GPU, енергоспоживання, використання VRAM. «Perf P2» може вказувати, що в деяких випадках він не підтягується повністю.

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

Завдання 4: Перевірити governor частоти CPU (класичне «чому я повільний після оновлення?»)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
powersave

Що це означає: Ви зафіксовані на консервативному governor. На деяких системах оновлення або демон живлення змінюють це.

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

Завдання 5: Тимчасово перемкнути governor (контрольований експеримент)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

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

Рішення: Перевірте ще раз. Якщо стутер зменшився і FPS повернувся — ваша «регресія від патча» це регресія політики живлення.

Завдання 6: Перевірити, чи є тротлінг CPU (терміни — тихий нотаток патча)

cr0x@server:~$ sudo dmesg | egrep -i "throttl|thermal|overheat" | tail -n 5
[  812.223001] thermal thermal_zone0: throttling CPU, temperature too high
[  812.223114] CPU0: Package temperature above threshold, cpu clock throttled

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

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

Завдання 7: Ідентифікувати тротлінг GPU / поведінку ліміту енергії

cr0x@server:~$ nvidia-smi --query-gpu=clocks.sm,clocks.gr,power.draw,power.limit,temperature.gpu,utilization.gpu --format=csv
clocks.sm [MHz], clocks.gr [MHz], power.draw [W], power.limit [W], temperature.gpu, utilization.gpu [%]
2610, 2550, 198.34, 200.00, 73, 98

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

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

Завдання 8: Виявити тиск пам’яті та swap (сплески часу кадру люблять свап)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        26Gi       1.2Gi       1.3Gi       3.8Gi       3.9Gi
Swap:          8.0Gi       2.1Gi       5.9Gi

Що це означає: Використовується свап і доступної оперативної пам’яті мало. Це рецепт для стутерів, коли під час стрімінгу ресурсів виникають page fault.

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

Завдання 9: Перевірити насиченість дискового I/O під час стутерів

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0-14-generic (cr0xbox) 	01/10/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          18.12    0.00    3.44    6.90    0.00   71.54

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         52.00   8200.00     0.00   0.00    8.20   157.69   40.00   6400.00     0.00   0.00   12.40   160.00   0.78  92.00

Що це означає: NVMe завантажений на 92% з нетривіальними часами очікування. Якщо це співпадає зі стутерами — ви I/O-bound під час стрімінгу або фонових задач.

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

Завдання 10: Знайти фонового порушника (хто б’є по диску?)

cr0x@server:~$ sudo iotop -oPa
Total DISK READ: 35.21 M/s | Total DISK WRITE: 18.77 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
 2143 be/4 root     28.11 M/s   10.22 M/s  0.00 %  7.11 %  updatedb.mlocate
 1987 be/4 root      2.02 M/s    5.41 M/s  0.00 %  2.34 %  systemd-journald

Що це означає: Оновлення бази locate гризе диск. Journald пише також. Таке любить траплятись після оновлень.

Рішення: Дайте йому завершитись, перенесіть на інший час або вимкніть під час ігрових сесій. Не діагностуйте «GPU-стутер», поки диск горить.

Завдання 11: Перевірити вільне місце в файловій системі (мало місця може вбити SSD-продуктивність)

cr0x@server:~$ df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p2  930G  905G   25G  98% /

Що це означає: 98% заповнення. Багато SSD і файлових систем гірше поводяться при майже повній заповненості (менше простору для wear leveling і оновлень метаданих).

Рішення: Звільніть місце. Спробуйте мати принаймні 10–15% вільного на споживчих SSD, більше якщо ви багато записуєте.

Завдання 12: Перевірити розклад TRIM (допомагає стійкій продуктивності SSD)

cr0x@server:~$ systemctl status fstrim.timer
● fstrim.timer - Discard unused blocks once a week
     Loaded: loaded (/lib/systemd/system/fstrim.timer; enabled; preset: enabled)
     Active: active (waiting) since Sat 2026-01-10 09:00:01 UTC; 3h 18min ago
    Trigger: Mon 2026-01-12 00:00:00 UTC; 1 day 11h left

Що це означає: TRIM увімкнено щотижня. Добра базова гігієна.

Рішення: Якщо відключено для SSD — увімкніть. Якщо система була заповнена і щойно очищена, запустіть fstrim і перевірте ще раз.

Завдання 13: Перевірити шторми page-fault (стрімінг ресурсів + мала RAM)

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 214748 1213440 142320 3568120    0    0  8012  6321 3120 8441 21  4 69  6  0
 3  0 214748 1189024 142320 3579000    0    0  9200  7000 3411 9032 24  5 65  6  0

Що це означає: Висока кількість переключень контексту, постійний I/O, мало вільної пам’яті. Якщо ви бачите зростання si/so (swap in/out) — це погано.

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

Завдання 14: Перевірити тиск планування CPU (ми просто перевантажені?)

cr0x@server:~$ uptime
 12:24:11 up  5:42,  1 user,  load average: 11.20, 9.84, 6.91

Що це означає: Load average близький до кількості ядер може бути нормою; значно вище — означає, що runnable задачі чекають. Ігри ненавидять очікування.

Рішення: Ідентифікуйте, що споживає CPU. Якщо патч додав сервіс, який завантажує ядра — вимкніть або обмежте його.

Завдання 15: Знайти топ-споживачів CPU (зазвичай підозрювані)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 4121 game.bin        285.2 18.3
 1981 baloo_file      122.4  2.1
 3777 discord          32.1  1.8
 2190 pipewire         18.7  0.4

Що це означає: Гра важка (очікувано), але індексатор файлів також жере CPU. Це заважає часу кадру.

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

Завдання 16: Перевірити стан пом’якшень ядра (для тих, хто каже «патч безпеки вбив продуктивність»)

cr0x@server:~$ grep . /sys/devices/system/cpu/vulnerabilities/* | head
/sys/devices/system/cpu/vulnerabilities/meltdown:Mitigation: PTI
/sys/devices/system/cpu/vulnerabilities/spectre_v2:Mitigation: Retpolines; IBPB: conditional; STIBP: disabled
/sys/devices/system/cpu/vulnerabilities/l1tf:Not affected

Що це означає: Які пом’якшення активні. PTI, retpolines, IBPB тощо. Деякі впливають на переходи ядро/користувач або на певні шаблони навантаження.

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

Жарт №2: Відключити пом’якшення, щоб повернути 5 FPS — це як зняти гальма, щоб поліпшити час кола: технічно ефективно, соціально не рекомендовано.

Три корпоративні міні-історії з реальних випадків

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

У середньому софтверному підприємстві внутрішня «ігрова ніч» використовувалася як ферма для графічного тестування. Це було не для забави: команди валідували GPU-прискорені UI збірки і віддалений рендеринг. Після рутинного циклу патчей усі почали скаржитись, що збірки «відчуваються» гірше. Найгучніша теорія — що патчі безпеки ввели втрати продуктивності ядра. Історія писалася сама собою.

Інженер відкотив ядро на кількох машинах і оголосив перемогу. Графік часу кадру виглядав плавнішим — короткочасно. Це не відтворювалось стабільно. Відкат став ритуалом: «Якщо стутер — завантаж старе ядро». Це не інженерія; це забобон з кнопкою перезавантаження.

Справжньою причиною була дрібніша й дурніша річ: оновлення змінило конфігурацію демона профілю живлення машини. Governor CPU переключився на powersave після ребуту на тій апаратній генерації. Під нерівномірним навантаженням CPU не встигав розігнатись, і головний потік промахувався повз бюджет кадру, викликаючи сплески.

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

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

Інша організація керувала флотом Linux-робочих станцій для художників. Лід вирішив «оптимізувати» нічі патчів, запустивши важкі задачі обслуговування одразу після оновлень: індексацію файлів, перебудову каталогів ресурсів і перевірки цілісності. Ідея була слушна: зробити це раз, у неробочий час, коли ніхто не працює.

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

Вони спробували міняти налаштування драйвера, змінювати композитори й фіксувати старі пакети Mesa. Нічого не допомагало, бо вузьке місце не в GPU. Воно було в чергах зберігання: обслуговування насичувало NVMe малими випадковими I/O, і додатки для творчості конкурували з тими чергами за ті ж ресурси.

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

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

Велике підприємство зі строгим контролем змін підтримувало «золоту образ» для GPU-робочих станцій. Нудна керованість, багато форм. Інженери скептично ставились — поки не прилетіло оновлення, що справді регресувало продуктивність у конкретному шарі трансляції OpenGL/Vulkan, який використовувався внутрішнім інструментом.

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

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

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

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

1) «FPS впав після патча» (але масштаб роздільності скинувся)

Симптом: Середній FPS різко падає; використання GPU зростає; зображення виглядає трохи різкіше.

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

Виправлення: Перевірте налаштування, підтвердіть роздільність рендеру, відновіть попередній пресет і протестуйте ту саму сцену.

2) «Кожні кілька секунд стутер» (диск і індексація)

Симптом: Сплески часу кадру співпадають з дисковою активністю; середній FPS може бути в нормі.

Корінь: Фонова індексація/сканування після оновлень; стрімінг ресурсів конкурує за I/O.

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

3) «Низький FPS лише після перезавантаження» (скид governor/policy)

Симптом: Перша сесія після ребуту повільна; тактові частоти CPU повільно піднімаються; ноутбук відчувається обмеженим.

Корінь: Governor переключився на powersave/balanced або прошивка/демон скинув платформні енергетичні ліміти.

Виправлення: Встановіть відповідний governor/режим живлення, перевірте підключення до мережі і профілі платформи.

4) «1% lows провалюються» (тиск пам’яті та свап)

Симптом: Середній FPS в нормі; раптові підлагування при повороті або завантаженні областей; використання свапу зростає.

Корінь: Патч збільшив використання RAM/VRAM; система почала пейджити.

Виправлення: Знизьте налаштування текстур, закрийте фонові додатки, збільшіть RAM, переконайтесь, що свап не трясеться.

5) «Використання GPU низьке, але FPS теж низький» (CPU-bound або накладні драйвера)

Симптом: GPU сидить на 40–60% при поганому FPS; одне ядро CPU завантажене під зав’язку.

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

Виправлення: Знизьте CPU-важкі налаштування (відстань огляду, натовпи), вбийте фонові CPU-поїдачі, протестуйте інший рендерер (DX11 vs DX12/Vulkan).

6) «FPS в меню нормальний, в грі жахливий» (перебудова кешу шейдерів)

Симптом: Перший матч стутерить, пізніші матчі покращуються; CPU сплески при нових ефектах.

Корінь: Кеші шейдерів інвалідувались через патч або оновлення драйвера.

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

7) «VR стутери після оновлення» (чутливість до таймінгу)

Симптом: Частіші пропуски кадрів/реprojection; невеликі сплески руйнують комфорт.

Корінь: VR нетерпимий до варіативності часу кадру; фонові задачі або зміни в плануванні мають більший ефект.

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

8) «Відкат не допоміг» (декілька змін і кешовані стани)

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

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

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

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

Покроково: доведіть (або спростуйте), що «патч це зробив»

1. Зафіксуйте тест: та сама сцена, та сама роздільність, те саме місце в грі, той самий реплей/демо якщо є.
2. Запишіть версії: збірка гри, версія драйвера, версія ОС/ядра.
3. Захопіть часи кадру: не покладайтеся на середній FPS. Дивіться 1% lows і сплески.
4. Перевірте налаштування: особливо масштаб роздільності, RT, режим апскейлінгу, ліміти кадрів, vsync, режими низької затримки.
5. Перевірте стан живлення: governor CPU, perf state GPU, AC/battery для ноутбука, логи тротлінгу.
6. Припиніть фонові задачі: індексація, антивірусні скани, інструменти синхронізації, служби оновлення.
7. Перевірте стан зберігання: вільне місце, I/O wait, високі часи очікування, розклад TRIM.
8. Перевірте тиск пам’яті: доступна RAM, використання swap, індикатори page-fault.
9. Змінюйте одну змінну: відкат драйвера або заміна ядра або версія гри (якщо можливо). Не всі разом.
10. Перевірте двічі: перший запуск може включати перебудову кешів; другий запуск ближчий до стабільного стану.
11. Прийміть рішення: якщо відтворювана регресія — подавайте баг з числами; якщо проблема в конфігурації/фоні — виправте локально і задокументуйте.

Чек-лист: «Хочу просто повернути плавність» — швидкі дії

• Перезавантажтеся раз (так, один раз), потім почекайте 10 хвилин у просте, щоб фонові завдання завершились.
• Переконайтесь, що режим живлення/governor не застряг у низькопотужному стані.
• Перевірте вільне місце на диску; якщо зайнято понад 90% — виправте це спочатку.
• Вимкніть оверлеї, які не потрібні для тесту (деякі дають помітні накладні витрати).
• Прогрійте кеш шейдерів, програвши ту ж сцену кілька хвилин.
• Якщо проблема почалась з оновлення драйвера — протестуйте попередню версію драйвера.

Чек-лист: що включити у багрепорт, щоб інженери поважали

• Версії до/після (гра, драйвер, ОС/ядро).
• Точні налаштування і роздільність, включно з режимом апскейлінгу та лімітом кадрів.
• Кроки відтворення зі стабільною сценою і часом прогонів.
• Середній FPS плюс 1% low і опис сплесків часу кадру.
• Стислий апаратний огляд (CPU, GPU, RAM, тип зберігання).
• Чи зберігається регресія після другого прогону (кеш прогрітий).

FAQ

1) Чи справді патчі знижують FPS, чи це завжди плацебо?

І те, й інше. Існують реальні регресії. Плацебо також поширене. Різницю дає відтворюваний контрольований тест і послідовні метрики (час кадру, 1% lows).

2) Чому стутер відбувається одразу після оновлення, але згодом все краще?

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

3) Чи треба негайно відкотити драйвер GPU?

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

4) Чи пом’якшення безпеки причина падіння FPS?

Іноді, але рідко це перша підозра для ігор. Спочатку виміряйте. Перевірте політику живлення, фоновий I/O і скиди налаштувань, перш ніж перемикати пом’якшення і брати на себе ризики безпеки.

5) Середній FPS в нормі, але відчуття гірше. Яка метрика важлива?

Стабільність часу кадру. Дивіться 1% lows і графік часу кадру. Сплески — те, що ви відчуваєте як підлагування, навіть якщо середній високий.

6) Чи може мало місця на диску реально спричинити проблеми з FPS?

Так. Стрімінг ресурсів може стукатись об I/O-насиченість, а SSD гірше себе поводить при майже повній заповненості. Якщо ви на 95–99% заповнення — ви просто створили генератор стутерів.

7) Чому використання GPU низьке, коли FPS поганий?

Ймовірно ви CPU-bound або заблоковані іншим (накладні драйвера, однопотокове обмеження, фоновий CPU-контеншн). GPU не може працювати, якщо його не «підгодовують».

8) Чи «оптимізувати», вимкнувши служби й фонові задачі?

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

9) Який найшвидший спосіб зрозуміти, CPU чи GPU обмеження?

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

10) Чому патч змінює мої налаштування взагалі?

Мігрування не завжди проходить гладко, з’являються нові опції, змінюються значення за замовчуванням, профілі скидаються після інсталяції драйвера, конфіг-файли перегенеруються. Це не злоба; це ентропія з реліз-нотатками.

Висновок: наступні кроки, які реально працюють

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

Ось що робити наступного разу, коли FPS провалиться після оновлення:

1. Класифікуйте проблему (середнє падіння vs сплески часу кадру vs затримка введення).
2. Перевірте налаштування і політику живлення (неприваблива, але постійно ламана річ).
3. Шукайте фоновий I/O і CPU-поїдачів (післяпатчеве обслуговування — частий підозрюваний).
4. Вимірюйте з стабільним тестом і збирайте докази до/після.
5. Змінюйте одну змінну одночасно (відкат драйвера, заміна ядра або версія гри — виберіть одну).

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