Гладкість — не FPS: час кадру за 2 хвилини

November 26, 2025 • February 3, 2026 • Читання: 4 хв • Views: 0

Було корисно?

У вас 144 FPS. Лічильник хвалиться. Проте гра все одно час від часу наче наступає на конструктор LEGO.
Ви знижуєте налаштування. Оновлюєте драйвери. Жертвуєте козла до записів змін. Все ще ривки.

Ось що треба зрозуміти: гладкість — це не «високий FPS». Гладкість — це «сталий час кадру».
Якщо запам’ятати один показник після цього — запам’ятайте час кадру.

Час кадру за два хвилини (єдине визначення, яке має значення)

FPS — це швидкість: кадрів за секунду. Час кадру — це тривалість: скільки зайняв один кадр на виробництво.
Ваш мозок відчуває тривалість безпосередніше, ніж швидкість. Ось і вся суть.
Усе інше — деталі та приписування провини.

Перетворення FPS у час кадру

Час кадру (мілісекунди) ≈ 1000 / FPS.

60 FPS → ~16.67 ms на кадр
120 FPS → ~8.33 ms на кадр
144 FPS → ~6.94 ms на кадр
240 FPS → ~4.17 ms на кадр

Якщо кожен кадр приходить рівно за 6.94 мс при 144 FPS, рух виглядає дуже плавним.
Якщо більшість кадрів приходять кожні 6–7 мс, але раз у кілька секунд один кадр займає 40 мс, ви відчуєте ривок.
Середній FPS може залишатися «високим». Ваш досвід — ні.

Що насправді означає графік часу кадру

Графік часу кадру — це просто хронологія «наскільки пізно був цей кадр».
Рівна лінія — добре. Сплески — погано. Пилкоподібні патерни зазвичай означають проблеми з таймінгом, чергуванням або синхронізацією.
Випадкові розсипані сплески часто викликані фоновою роботою (компіляція, IO, GC, антивірус, телеметрія, оверлеї).

«Але мій лічильник FPS каже 140!» Так. Якщо взяти 139 кадрів по 7 мс і 1 кадр на 40 мс, середнє все одно виглядає добре.
Ваші очі запам’ятають 40 мс зраду.

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

Чому FPS бреше (і чому ваші очі — ні)

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

Три числа, що важливіші за середній FPS

1% low FPS: FPS для найповільніших 1% кадрів. Кращий індикатор стутеру, ніж середній.
0.1% low FPS: найповільніші 0.1%. Ловить проблему «раз на хвилину підлагування».
Перцентиль часу кадру: наприклад, 99-й перцентиль часу кадру. Це «наскільки погано буває».

Що ви насправді помічаєте: дисперсія

Людина помічає нерівномірність. Стабільні 60 FPS можуть здаватися плавнішими за бурхливі коливання 90–180 FPS.
Відчуття здебільшого про точність подачі кадрів: рівний інтервал між кадрами.

Чому «більше FPS» іноді робить гірше

Нескінченний FPS може навантажити CPU рендер-потік, створити більші черги і збільшити затримку. В результаті ви отримуєте:

Більше тепла → тротлінг → періодичні сплески часу кадру
Більше конкуренції → планувальні джитери ОС
Більше споживання енергії → коливання GPU boost (особливо на ноутбуках)
Більше артефактів swapchain та синхронізації → нерівномірне чергування

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

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

VSync спочатку був для уникнення розривів, а не для «гладкості». Він синхронізує презентацію з частотою оновлення дисплея,
але може вводити підлагування, якщо кадри пропускають дедлайн і чекають цілий цикл оновлення.
«1% lows» стали популярні, бо середні приховували стутер. Бенчмаркерщики почали звітувати lows, коли потужне залізо зробило «середнє» маргінальним щодо сприйняття.
Ранні 3D-ігри часто були зав’язані на CPU, а не на GPU. Трансформації і освітлення раніше робилися на CPU,
тож патерни стутеру виглядали інакше: спайки у симуляції замість шейдерних просідань.
Компіляція шейдерів — сучасна класика стутеру. Двигуни, що компілюють шейдери по вимозі, можуть підлагувати при першому появі ефекту.
Кешування допомагає, але лише якщо пайплайн реалізовано й зберігається правильно.
VR зробив подачу кадрів неприйнятною як-небудь. Дискомфорт у VR змусив індустрію трактувати пропущені дедлайни кадрів як критичну проблему,
а не як естетичний недолік.
Баги з подачею кадрів існували навіть при «добрим» FPS. Деякі старі драйвери та рушії давали нерівномірну презентацію
(multi-GPU AFR був сумнозвісним), приводячи до «мікростутеру» попри високий середній FPS.
Сучасні планувальники ОС можуть створювати джиттер під навантаженням. Фонові завдання, управління живленням і інтеррупт-шторм можуть відбирати
часові слоти в неправильний момент і проявлятися як сплески часу кадру.
Сховища стали швидшими, але IO-затримки не зникли. NVMe зменшив середній час завантаження, але одиночний заблокований IO на невірному потоці
все ще може спричинити помітний ривок, якщо рушій не вміє правильно стрімити ресурси.

Куди зникає час кадру: типові патерни вузьких місць

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

CPU-bound: головний потік запізнюється

Симптоми: використання GPU низьке або флюктує, один ядро CPU завантажене на максимум, сплески часу кадру під час ІІ, фізики, стрімінгу світу,
збору сміття або в сценах з великою кількістю draw call.

Практичний підхід: зменшити вартість симуляції, зменшити кількість draw call, обмежити FPS або перенести роботу з головного потоку.
Якщо ви гравець, ви не перепишете рушій, але можете змінити налаштування, що впливають на CPU: дальність огляду, щільність натовпу,
фізика/частинки, побудова BVH для трасування променів (так, це теж може вдарити по CPU).

GPU-bound: рендеринг запізнюється

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

Практичний підхід: знизити роздільність, спочатку вимкнути дорогі ефекти (RT, об’ємні ефекти, тіні), використати DLSS/FSR/XeSS якщо доступно,
і уникати нескінченного FPS, якщо це викликає термо-тротлінг.

Проблеми з подачею кадрів / синхронізацією: пайплайн нерівномірний

Симптоми: середній FPS високий, але графік часу кадру показує періодичні сплески з регулярним інтервалом (наприклад, кожну секунду або кратно оновленню).
Часто пов’язано з VSync, triple buffering, режимом безрамкового вікна, оверлеями, програмами запису або поганими лімітерами FPS.

IO і сховище: ривок, який не «знизити графіку» допоможе

Симптоми: сплески при вході в нові зони, швидкому повороті, відкритті меню або після тривалого ігрового сеансу.
Черга диска зростає, стрибки page fault, система відчувається «липкою» у різних додатках.

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

Мережа і серверні тики: онлайн-ігри теж можуть підлагувати

Не весь «стутер» — це час кадру. Втрата пакетів та джиттер можуть виглядати як ривки, бо рух гравця скаче або відбувається rubber-banding.
Розрізняйте рендерний стутер (сплески часу кадру) від симуляційного/мережевого (час кадру стабільний, але рухи непослідовні).

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

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

Перше: підтвердьте, що це час кадру, а не мережа або сприйняття

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

Друге: вирішіть, чи ви CPU-bound чи GPU-bound

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

Третє: усуньте «зовнішній саботаж»

Вимкніть оверлеї (запис, чат, моніторинг, ПЗ RGB).
Перевірте фонові задачі: сканування антивірусом, оновлення, індексація, телеметрія.
Перевірте стан сховища та сторінкування: мало ОЗП і page fault — фабрики ривків.

Четверте: застосуйте найшвидші стабілізатори

Обмежте FPS (краще вбудований ліміт гри). Ціль: трохи нижче частоти оновлення (наприклад, 141 на 144 Гц).
Увімкніть VRR (G-Sync/FreeSync) якщо підтримується; поєднуйте з адекватними лімітами.
Виберіть план живлення, який не занижує частоти агресивно при транзієнтному навантаженні.

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

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

Це написано як runbook SRE, бо саме такою є розробка продуктивності: інцидент з графіками,
гіпотезами та ізоляцією. Більшість команд — у стилі Linux, бо вони відтворювані й чесні.
Якщо ви на Windows, ментальна модель все одно працює: ви шукаєте насичення CPU, простої GPU, черги IO та тиск пам’яті.

Завдання 1: Підтвердити частоту оновлення і поточний режим

cr0x@server:~$ xrandr --current
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DP-1 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 596mm x 335mm
   2560x1440     143.91*+
   1920x1080     143.85
HDMI-1 disconnected (normal left inverted right x axis y axis)

Що це означає: Ви дійсно працюєте на 143.91 Гц на DP-1. Добре.
Якщо ви думали, що маєте 144 Гц, а насправді 60 Гц — жодна оптимізація не виправить «відчувається з запізненням».

Рішення: Якщо частота оновлення неправильна, виправте налаштування дисплея/кабель/порт перед тим, як щось міняти.

Завдання 2: Перевірити шлях композитора / vsync (підказка Wayland/X11)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

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

Рішення: Якщо стутер з’явився після зміни типу сесії, протестуйте інший тип сесії як контроль.

Завдання 3: Живий тиск на CPU і насичення по ядрах

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

12:10:01 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
12:10:02 AM  all   28.10  0.00  6.20   0.15 0.00  0.35   0.00 65.20
12:10:02 AM    0   92.00  0.00  5.00   0.00 0.00  0.00   0.00  3.00
12:10:02 AM    1   18.00  0.00  4.00   0.00 0.00  0.00   0.00 78.00

Що це означає: CPU0 майже завантажений, тоді як інші — відносно вільні. Це кричить «вузьке місце головного потоку».

Рішення: Зменшити налаштування, що навантажують CPU, обмежити FPS і перевірити переривання або одноядерні вузькі місця.

Завдання 4: Підтвердити тиск пам’яті (сторінкування викликає ривки)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        27Gi       1.2Gi       1.1Gi       3.0Gi       2.8Gi
Swap:           16Gi       7.8Gi       8.2Gi

Що це означає: Swap активно використовується. Не обов’язково критично, але активний swap під час гри — класична причина стутеру.

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

Завдання 5: Слідкувати за великими page fault в реальному часі

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 812345 1213456 102400 2800000  15   22   120   340 5200 8800 31  7 60  2  0
 3  1 813112 1189000 102400 2792000  80  110   900  1400 6400 9900 35  8 52  5  0

Що це означає: Ненульові si/so означають, що відбувається swap in/out. Це IO на шляху пам’яті.

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

Завдання 6: Виявити чергування IO та насичення диска

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

Device            r/s     w/s   rkB/s   wkB/s  await  %util
nvme0n1          12.0    85.0   640.0  8200.0   6.50  78.00
sda               0.0     2.0     0.0    64.0  25.00   5.00

Що це означає: NVMe зайняте (%util високе). await ~6.5 ms — прийнятно, але сплески мають значення.
Якщо await стрибає до десятків/сотень мс під час ривків — IO залучений.

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

Завдання 7: Шукати файлові та блок-шарові сплески затримок

cr0x@server:~$ sudo dmesg -T | tail -n 8
[Tue Jan 13 00:11:02 2026] nvme nvme0: I/O 123 QID 5 timeout, aborting
[Tue Jan 13 00:11:02 2026] nvme nvme0: Abort status: 0x371
[Tue Jan 13 00:11:03 2026] EXT4-fs warning (device nvme0n1p2): ext4_end_bio:343: I/O error 10 writing to inode 262145 starting block 12345678

Що це означає: Це не просто «стутер», це інцидент зі сховищем. Таймаути та помилки IO проявляться як жахливі ривки і зрештою як втрата даних.

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

Завдання 8: Перевірити NVMe SMART і індикатори термо-тротлінгу

cr0x@server:~$ sudo smartctl -a /dev/nvme0
SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
Critical Warning:                   0x00
Temperature:                       79 Celsius
Available Spare:                   100%
Percentage Used:                   6%
Data Units Read:                   12,345,678
Data Units Written:                9,876,543
Warning Comp. Temperature Time:    0
Critical Comp. Temperature Time:   12

Що це означає: 79°C і ненульовий «critical temperature time» натякають на події тротлінгу.
Тротлінг може створювати періодичні сплески часу кадру через розширення латентності IO.

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

Завдання 9: Підтвердити драйвер GPU та базову статистику GPU (приклад NVIDIA)

cr0x@server:~$ nvidia-smi --query-gpu=name,driver_version,utilization.gpu,clocks.sm,temperature.gpu,pstate --format=csv
name, driver_version, utilization.gpu [%], clocks.sm [MHz], temperature.gpu, pstate
NVIDIA GeForce RTX 4070, 550.54.14, 96 %, 2475 MHz, 73, P0

Що це означає: GPU майже завантажено і в P0 (максимальний стан продуктивності). Імовірно в цей момент вузьке місце — GPU.

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

Завдання 10: Перевірити причини тротлінгу GPU (NVIDIA)

cr0x@server:~$ nvidia-smi -q -d PERFORMANCE | sed -n '1,80p'
==============NVSMI LOG==============
Performance State                          : P0
Clocks Throttle Reasons
    Idle                                   : Not Active
    Applications Clocks Setting             : Not Active
    SW Power Cap                            : Not Active
    HW Slowdown                             : Active
    HW Thermal Slowdown                     : Active
    Sync Boost                              : Not Active
    SW Thermal Slowdown                     : Not Active

Що це означає: Thermal slowdown активний. Ваш GPU періодично пригальмовує.
Це створює дуже специфічний патерн «працює добре, потім ривок».

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

Завдання 11: Спіймати фонового CPU-поглинача під час ривка

cr0x@server:~$ top -b -n 1 | head -n 20
top - 00:12:44 up  2:31,  1 user,  load average: 4.21, 3.88, 3.51
Tasks: 329 total,   2 running, 327 sleeping,   0 stopped,   0 zombie
%Cpu(s): 36.3 us,  7.2 sy,  0.0 ni, 55.8 id,  0.5 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  32154.0 total,   1204.0 free,  27680.0 used,   3270.0 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 8421 cr0x      20   0  9812m  5020m  132m R  168.0  15.6  12:31.22 game.bin
 2210 root      20   0  1240m  220m   34m S   45.0   0.7   0:40.11 tracker-miner-fs

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

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

Завдання 12: Перевірити інтеррупт-шторм (запізнення вводу та сплески)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  0:         45          0          0          0   IO-APIC   2-edge      timer
  1:          2          0          0          0   IO-APIC   1-edge      i8042
 24:    1423456    1322211    1209987    1187765   PCI-MSI 327680-edge      nvme0q0
 42:     983221     964112     955001     948887   PCI-MSI 524288-edge      nvidia

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

Рішення: Якщо бачите патологічну дисбаланс або раптові стрибки — перевіряйте проблеми драйверів, налаштування MSI/MSI-X або регресії ядра.

Завдання 13: Перевірити масштабування частоти CPU (спади частоти)

cr0x@server:~$ grep -H . /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:powersave
/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:800000

Що це означає: Губернатор встановлений у powersave і CPU зараз на 800 MHz.
Це добре для енергозбереження і жахливо для стрибків часу кадру.

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

Завдання 14: Застосувати тимчасовий governors продуктивності (тест, не «встановити і забути»)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3
Setting cpu: 4
Setting cpu: 5
Setting cpu: 6
Setting cpu: 7
Setting cpu: 8
Setting cpu: 9
Setting cpu: 10
Setting cpu: 11
Setting cpu: 12
Setting cpu: 13
Setting cpu: 14
Setting cpu: 15

Що це означає: Ви усунули одне велике джерело варіації затримки: агресивне знижування частоти.

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

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

1) Інцидент, спричинений неправильною припущенням: «FPS високий, значить все ок»

Команда дизайну скаржилася, що їх 3D-предперегляд «відчувається липким» на нових висококласних робочих станціях.
IT відповіли очевидним: «GPU топовий; лічильник FPS понад 120; машина не винна».
Тикет пересилали двічі. Моральність не зросла ані на відсоток.

Інженер з підходом SRE сідав з користувачем і зробив нудну річ: подивився час кадру, а не FPS.
Графік був рівним, поки не відкрили важку панель браузера активів, тоді він почав сплескувати кожні кілька секунд як метроном.
Це не випадковий ривок. Періодична зупинка.

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

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

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

Невелика внутрішня команда керувала стіною візуалізації для клієнтського брифінг-центру. Хтось помітив, що додаток інколи просідає нижче частоти оновлення екрана.
Доброзичливий інженер «оптимізував», дозволивши uncapped FPS і відключивши синхронізацію, щоб «дозволити GPU працювати вільно».
Лічильник FPS підскочив. Команда потішилася. Потім клієнти почали питати, чому рух виглядає тремтячим.

Проблема була не в пропускній здатності; вона була в таймінгу. Незакритий рендер створив глибоку чергу кадрів.
Затримка від вводу до фотонів зросла, і дисплей бачив нерівномірну подачу, бо композитор і swapchain тепер управляли потоком кадрів.
Невеликі періодичні паузи (GC, скидання логів, телеметрія) стали помітні як жорсткі ривки, бо не було послідовного каденсу.

Найпринизливіше: «оптимізація» також підвищила терміку. Через п’ятнадцять хвилин GPU тротлився.
Час кадру різко підскакував саме в момент «вау» моменти брифінгу.

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

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

Команда виробництва тренувального симулятора мала реліз-кандидат, що «відчувався гірше», ніж попередня збірка.
Жодних падінь, жодних очевидних регресій у середньому FPS. Просто відчуття підлагування при швидкому пересуванні у складному середовищі.
Легко було б сперечатися думками. Правильний шлях — зібрати послідовні трейсинги.

Вони тримали стандартний чеклист захоплення продуктивності: той самий маршрут, ті самі розгони камери, той самий пресет графіки, такий самий стан машини.
Захопили часи кадрів, завантаження CPU/GPU і статистику IO. Потім порівняли перцентилі, а не середні.
Регресія виявилась у погіршеному 99.9-го перцентиля часу кадру, хоча середній FPS не змінився.

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

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

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

1) «Високий FPS, але ривки коли я швидко повертаюсь»

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

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

Виправлення: Увімкніть попередню компіляцію шейдерів, прогрійте кеш шейдерів, перемістіть гру на швидке сховище, уникайте фонового IO, тримайте запас ОЗП.

2) «Гладко перші 10 хвилин, потім гірше»

Симптом: Сплески часу кадру збільшуються з часом.

Корінна причина: Тротлінг по температурі (GPU/CPU/NVMe) або витік пам’яті, що приводить до сторінкування.

Виправлення: Моніторити частоти/температури, покращити охолодження, обмежити FPS, перевірити ОЗП і активність swap, перезапуск як тимчасовий захід.

3) «Періодичний ривок кожну секунду (або кожні кілька секунд)»

Симптом: Сплески часу кадру з регулярною періодичністю.

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

Виправлення: Вимкніть заплановані задачі, спробуйте exclusive fullscreen, використайте адекватний FPS cap і уникайте сторонніх лімітів, що викликають джиттер.

4) «Увімкнення VSync робить повільніше; вимкнення — рве картинку»

Симптом: Або розриви, або липка відповідь.

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

Виправлення: Використайте VRR, якщо є; обмежте FPS трохи нижче частоти оновлення; якщо прив’язані до VSync — налаштуйте, щоб не пропускати дедлайни.

5) «Зниження графіки не допомагає стутеру»

Симптом: Ті самі сплески на низьких налаштуваннях.

Корінна причина: CPU-bound головний потік, IO-зупинки або переривання ОС.

Виправлення: Зменшити налаштування, що навантажують CPU, перевірити фонові процеси, підтвердити тиск пам’яті і перестати автоматично звинувачувати GPU.

6) «Мікростутер лише в безрамковому вікні»

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

Корінна причина: Шлях композитора додає складність планування і буферизації; оверлеї підключаються інакше.

Виправлення: Спробуйте повноекранний ексклюзивний режим, вимкніть оверлеї, протестуйте інші налаштування композитора або тип сесії.

7) «Стутер після оновлення драйвера»

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

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

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

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

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

Чеклист A: стабілізувати подачу кадрів за 15 хвилин

Виміряти: увімкніть графік часу кадру і відтворіть ривок надійно.
Обмежити FPS: використайте вбудований ліміт гри спочатку; встановіть cap на refresh-3 (наприклад, 141 для 144 Гц).
VRR: увімкніть G-Sync/FreeSync; тримайте cap, щоб залишатися в межах вікна VRR.
Оверлеї вимкнути: вимикайте інструменти захоплення/оверлеї по черзі; тестуйте після кожної зміни.
Терміка: спостерігайте частоти і температури GPU/CPU; виправте тротлінг перед тим, як чіплятися до налаштувань.
Запас пам’яті: переконайтеся, що є доступна ОЗП; закрийте браузери і лаунчери, які зростають з часом.
IO-санітарія: переконайтеся, що гра на швидкому локальному сховищі; виключіть з реального сканування, якщо політика дозволяє.

Чеклист B: вирішити «CPU-bound чи GPU-bound» без гадань

Зменшіть роздільність на один крок (або увімкніть апскейлер).
Якщо час кадрів значно покращився: більше GPU-bound.
Якщо час кадрів майже не змінився: швидше CPU-bound або sync/IO-bound.
Зменшіть налаштування, що навантажують CPU (дальність огляду/натовп/фізика).
Якщо час кадрів покращився: CPU-bound підтверджено.

Чеклист C: пакет доказів для ескалації (драйвер/вендор/команда рушія)

Захват часу кадрів з показом сплесків (додайте перцентильні статистики, якщо є).
Частоти/температури/завантаження GPU у момент сплесків.
Використання CPU по ядрах і стан масштабування частот.
Статистика IO (черга/await) і пам’яті (swap/page fault).
Точні кроки відтворення (сцена, маршрут, налаштування, час до відмови).

Нотатка надійності, яку варто запозичити для своїх систем

«Середня затримка заспокоює. Хвости затримки — це клієнтський досвід.» Те саме й про час кадру.
В операціях ми дивимось p95/p99. В рендерингу — 1% і 0.1% lows та сплески часу кадру.

Одна цитата, бо вона актуальна і варта запам’ятовування:
Everything fails all the time. — Werner Vogels

FAQ

1) Якщо в мене монітор 240 Гц, чи потрібні 240 FPS?

Ні. Потрібна стабільна подача. 120 FPS зі сталими ~8.3 мс може відчуватися краще за нестабільні 200–240.
Вища частота оновлення зменшує сприйняту затримку, але лише якщо система тримає стабільні часи кадру.

2) У чому різниця між «стутером» і «затримкою вводу»?

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

3) Чи 1% lows — це те ж, що сплески часу кадру?

Вони пов’язані. 1% lows підсумовують найповільніші 1% кадрів в одне число.
Графіки часу кадру показують точну форму і таймінг. Використовуйте lows для швидкого порівняння; використовуйте графіки для діагностики.

4) Чому обмеження FPS іноді робить гру плавнішою?

Бо воно зменшує варіацію і запобігає runaway-чергам та термо-коливанням.
Кап змушує пайплайн працювати у передбачуваному каденсі. Передбачуваний каденс виглядає плавно.

5) Краще використовувати вбудований ліміт гри, драйвер чи зовнішній інструмент?

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

6) Чи швидша оперативна пам’ять допомагає часу кадру?

Іноді, особливо в CPU-bound сценаріях, де головний потік чутливий до латентності пам’яті.
Але це рідко — чарівна пігулка. Якщо відбувається сторінкування на диск, швидша RAM не врятує. Спочатку вирішіть тиск пам’яті.

7) Чому ривки лише при першому вході в область?

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

8) Чи може сховище справді викликати стутер навіть на NVMe?

Так. NVMe поліпшив середні показники, але не архітектуру. Одиничний синхронний IO на критичному потоці може блокувати кадр.
Також: термо-тротлінг або проблеми прошивки можуть різко підняти латентність IO. Перевіряйте SMART і температури, якщо патерн збігається.

9) Чи завжди VRR (G-Sync/FreeSync) кращий?

Здебільшого — для змінних FPS. Але VRR не виправить великі сплески; він тільки підлаштовує частоту оновлення під подачу кадрів.
Потрібно усунути базові зупинки. Також некоректно налаштований VRR разом з поганими лімітами може давати мерехтіння або дивний таймінг.

10) Який час кадру вважати «добрим»?

Підлаштуйтеся під ціль. Для 60 Гц хочете більшість кадрів < 16.67 ms з мінімальними сплесками.
Для 144 Гц прагніть ~6.94 ms типово і тримайте хвіст вузьким — сплески понад ~20 ms будуть помітні при швидкому русі.

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

Припиніть сперечатися з лічильником FPS. Вимірюйте час кадру.
Мета — не героїчний піковий показник; мета — нудна сталість.
Нудно означає плавно. Плавно — це те, чого ви прагнули.

Зробіть це далі, в порядку

Увімкніть графік часу кадру і відтворіть проблему.
Обмежте FPS трохи нижче частоти оновлення і протестуйте знову.
Класифікуйте вузьке місце: CPU, GPU, IO/пам’ять або синхронізація/таймінг.
Видаліть фонових порушників (оверлеї, індексатори, оновлювачі) і перевірте терміку.
Якщо сплески лишаються — зберіть пакет доказів (перцентилі, частоти, температури, IO, пам’ять) і ескалюйте з даними.

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