Чому процесори створюють вузьке місце для GPU на 1080p (а не на 4K)

Головна ідея: хто задає темп для кадру

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

Частота кадрів задається повільнішою стороною. Якщо процесору потрібно 8 мс, щоб підготувати роботу для наступного кадру, а GPU рендерить її за 5 мс,
ви не отримаєте 200 FPS. Ви отримаєте 125 FPS (і GPU простоює, очікуючи нові команди від CPU). Якщо GPU потребує 12 мс, а CPU 6 мс — ви маєте 83 FPS і CPU чекає.

Тому «завантаження GPU» — це пастка, коли люди дивляться на нього як на спідометр. GPU може бути недовантажений через:
(1) очікування на CPU, (2) очікування на пам’ять або передачі PCIe, (3) обмеження гри або ввімкнений vsync, або (4) серіалізацію роботи драйвером, яку ваш моніторинг не показує чітко.
Завантаження — це доказ. Це не діагноз.

Чому 1080p — це «територія CPU», а 4K — «територія GPU»

Роздільність змінює роботу GPU більше, ніж CPU

Перехід з 1080p (1920×1080) на 4K (3840×2160) учетверює кількість пікселів. Не «трохи більше». У чотири рази більше пікселів.
Це підсилює роботу GPU, яка масштабуються з кількістю пікселів: фрагментний шейдинг, проходи постобробки, певні режими згладжування, пропускна здатність для запису у цільові буфери та вартість високоякісних пер-піксель ефектів.

Що не сильно залежить від роздільності? Багато роботи CPU: крок логіки гри, крок фізики, рішення ШІ, оцінка графа анімацій,
рішення видимості, обходи сценового графа та накладні витрати на подачу викликів малювання й прив’язки ресурсів. Ці витрати залежать від кількості об’єктів і того, як рушій організовує роботу, а не від числа пікселів.

На 1080p GPU швидко завершує роботу, а потім чекає

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

Це і є «вузьке місце процесора». Ніякої містики. Це голодування. Ви купили дуже швидку кухню (GPU), але офіціант (CPU + драйвер) приносить інгредієнти по одному.

На 4K GPU нарешті має досить роботи

На 4K час GPU на кадр збільшується драматично. Багато сцен стають обмеженими GPU, бо домінують шейдинг та пропускна здатність пам’яті.
Процесор все ще виконує ту саму оркестрацію, але тепер GPU — повільніша ланка. Завантаження GPU піднімається до 95–99%, і частота кадрів вирівнюється з очікуванням згідно бенчмарків відеокарт.

Пастка змагання за FPS

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

Жарт №1: Купувати флагманську відеокарту для 1080p на низьких налаштуваннях і чекати чудес — це як поставити реактивний двигун на візок для покупок: технічно вражає, але експлуатаційно дивно.

Що насправді робить процесор у сучасній грі

Щоб зрозуміти, чому процесор може створювати вузьке місце на 1080p, припиніть думати про «процесор» як про одну річ. У реальних рушіях навантаження CPU
розподілене по багатьох потоках з нерівномірною паралельністю та неприємними точками синхронізації.

1) «Головний/ігровий потік» і серійні пляшкові горла

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

Коли люди кажуть «одне ядро завантажено на максимум», зазвичай йдеться саме про це. 16-ядерний процесор не допоможе, якщо обмежувальний потік не розпаралелюється.
Паралельні робітники можуть бути на 20% простою, тоді як головний потік горить на 100% і GPU терпляче чекає.

2) Підготовка рендерингу: відсікання, сортування та формування команд

Сучасний рендеринг — це не просто «надсилаємо трикутники». Це: визначити видимі об’єкти, вибрати LOD, побудувати списки рендеру, відсортувати щоб зменшити зміни стану,
зв’язати ресурси і сформувати командні буфери. Це — робота CPU.

Рушії, що покладаються на багато дрібних викликів малювання, можуть «розчавити» CPU на 1080p, бо подача викликів і валідація стану коштують дорого, особливо в старіших графічних API або коли драйвер серіалізує роботу.

3) Накладні витрати драйвера і модель API

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

DirectX 11 відомий вищими накладними витратами на виклики малювання в багатьох навантаженнях через те, як управляється стан і як драйвери змушені виконувати роботу.
DirectX 12 та Vulkan перекладають більше відповідальності на рушій, що може зменшити накладні витрати якщо рушій правильно їх використовує.
«Перехід на DX12» не дає автоматичної вигоди. Це шанс не програти.

4) Стрімінг ресурсів і керування пам’яттю

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

5) ОС: DPC, переривання, фонові служби

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

Що змінюється з роздільністю (і що ні)

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

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

Але для більшості сучасних проєктів 4K штовхає вас у режим, де домінують фрагментний шейдинг, постобробка та пропускна здатність. Саме тоді GPU стає лімітуючою ланкою і недоліки CPU ховаються.

Робота CPU прив’язана до «складності світу», а не до роздільності

CPU не хвилює, відрендерено сцену в 1080p чи в 4K: йому все одно потрібно вирішити, що видно, симулювати тих же NPC і сформувати ту саму кількість викликів малювання.
Якщо ви зберігаєте ті ж налаштування графіки і ту ж сцену, завантаження CPU часто залишається близьким до сталого.

Чому зниження налаштувань може зробити вас «більш обмеженим CPU»

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

Час кадру — єдина метрика, яка не бреше

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

Одна практична цитата, яку варто тримати на стікері:
Надія — не стратегія. — генерал Гордон Р. Салліван

Факти та історичний контекст, що пояснюють сучасний безлад

• Факт 1: Мем про «вузьке місце CPU» посилився з появою високочастотних 1080p кіберспортивних режимів; 240 Гц робить видимими джитери CPU.
• Факт 2: Модель immediate context у DirectX 11 часто змушує роботу драйвера виконуватися на CPU; вона була спроєктована в епоху інших очікувань щодо потоків.
• Факт 3: Консольні рушії штовхали агресивні job-системи через фіксоване апаратне середовище; PC-порти іноді успадковують ці патерни коректно, іноді — ні.
• Факт 4: Раніше «ліміти на виклики малювання» були у низьких тисячах в старих API та драйверах; сьогодні рушії можуть подавати значно більше, але лише при ретельному батчингу та багатопоточності.
• Факт 5: Зростання шейдерно-важких постобробних ефектів (TAA, SSR, варіанти AO) зробило 4K непропорційно дорогим, перемістивши вузьке місце на сторону GPU.
• Факт 6: Пропускна здатність PCIe рідко лімітує рендер у стеді-стейті, але спайки завантаження (стрімінг, компіляція шейдерів, runtime PSO-створення) можуть викликати підвисання, що відчувається як вузьке місце CPU.
• Факт 7: SMT/Hyper-Threading підвищує пропускну здатність, але багато ігор обмежені одним або двома «гарячими» потоками, де SMT не подвоює продуктивність.
• Факт 8: Перемикачі «threaded optimization» у драйверах існують, бо накладні витрати драйвера на CPU реальні; вони також крихкі, бо змінюють розклад і блокування.

Швидкий план діагностики

Перше: визначте, чи ви обмежені CPU або GPU за 2 хвилини

1. Змініть лише роздільність (1080p → 1440p → 4K) з тими ж налаштуваннями.
   
   Якщо FPS майже не змінюється зі збільшенням роздільності — ви CPU-bound. Якщо FPS помітно падає з ростом роздільності — ви GPU-bound.
2. Дивіться на час кадру CPU проти GPU (не лише завантаження).
   
   Якщо час кадру CPU > час кадру GPU — обмежує CPU. Якщо час кадру GPU > CPU — обмежує GPU.
3. Перевірте на наявність обмежень та синхронізації.
   
   Якщо ви припритиснуті до 60/120/144/165/240 — можливо, ви вдаряєтесь об обмеження (vsync, ліміт кадрів, VRR-стеля, ліміт драйвера).

Друге: ідентифікуйте конкретний CPU-лімітер

1. Одне ядро завантажено? Ймовірно головний потік, потік драйвера або важкий підсистема (ШІ/фізика).
2. Високий DPC/ISR час? Ймовірно затримки драйвера/переривань: мережа, аудіо, зберігання, USB або пристрої захоплення.
3. Підвисання під час обходу сцени? Часто компіляція шейдерів, створення PSO або координація стрімінгу ресурсів.

Третє: зробіть найдешевшу зміну з найвищим очікуваним ROI

• Увімкніть розумний ліміт кадрів нижче вашого оновлення, щоб стабілізувати темп.
• У 4K краще використовувати рекомендований апскейлер рушія замість примусового нативного рендерингу.
• Якщо ваша мета — високий FPS на 1080p, пріоритезуйте частоту/IPC процесора та затримки пам’яті, а не «ще одну відеокарту».

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

Це польові інструменти. Не ідеальні. Але вони послідовні, скриптовані і дають тверді підказки. Хост названий «server», бо я SRE і звички гинуть важко.

Завдання 1: Перевірити модель CPU, поведінку boost і розклад ядер

cr0x@server:~$ lscpu | egrep 'Model name|CPU\(s\)|Thread|Core|Socket|MHz'
Model name:                           AMD Ryzen 7 7800X3D 8-Core Processor
CPU(s):                               16
Thread(s) per core:                   2
Core(s) per socket:                   8
Socket(s):                            1
CPU MHz:                              4482.000

Що означає вивід: Підтверджує кількість ядер/потоків і знімок поточної частоти. Якщо ви бачите низькі MHz під навантаженням, можлива обмеженість по живленню/термічна.

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

Завдання 2: Перевірити governor частоти CPU (Linux) або дрейф політик

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

Що означає вивід: «schedutil» зазвичай підходить; «powersave» може шкодити стабільності при високих FPS.

Рішення: Для бенчмарків тимчасово використайте «performance», щоб усунути варіації, спричинені governor.

Завдання 3: Подивитися навантаження по ядрам (знайти переповнений потік)

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

01:10:01 PM  CPU   %usr  %nice  %sys %iowait  %irq  %soft  %steal  %idle
01:10:02 PM  all  22.10   0.00  3.10    0.10  0.00   0.30    0.00  74.40
01:10:02 PM    6  88.00   0.00  4.00    0.00  0.00   0.00    0.00   8.00
01:10:02 PM    7  12.00   0.00  2.00    0.00  0.00   0.00    0.00  86.00

Що означає вивід: Одне ядро (CPU 6) майже завантажене, інші — ні. Це класична поведінка «головного потоку» або серіалізації в драйвері.

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

Завдання 4: Підтвердити наявність GPU і стек драйверів

cr0x@server:~$ lspci -nn | egrep -i 'vga|3d|nvidia|amd'
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation Device [10de:2684] (rev a1)

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

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

Завдання 5: Перевірити ширину й швидкість PCIe (поширений тихий ліміт)

cr0x@server:~$ sudo lspci -s 01:00.0 -vv | egrep -i 'LnkCap|LnkSta'
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16

Що означає вивід: Ви хочете, щоб LnkSta відповідала LnkCap і за швидкістю, і за шириною. x8 або Gen3 може мати значення в крайніх випадках, особливо при інтенсивному стрімінгу.

Рішення: Якщо бачите x4 або Gen1/Gen2 — перевстановіть GPU, перевірте налаштування BIOS PCIe і впевніться у використанні правильного слоту.

Завдання 6: Спостерігати завантаження GPU і частоти (санітарна перевірка, не діагностика)

cr0x@server:~$ nvidia-smi --query-gpu=utilization.gpu,clocks.gr,clocks.mem,pstate,power.draw --format=csv -l 1
utilization.gpu [%], clocks.gr [MHz], clocks.mem [MHz], pstate, power.draw [W]
62 %, 2730 MHz, 10501 MHz, P0, 220.45 W
58 %, 2715 MHz, 10501 MHz, P0, 214.10 W

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

Рішення: Якщо частоти низькі (P2/P5) під навантаженням — виправте управління живленням або налаштування драйвера перед пошуком CPU-лімітів.

Завдання 7: Перевірити джерела латентності планування CPU (шторми переривань)

cr0x@server:~$ cat /proc/interrupts | head
           CPU0       CPU1       CPU2       CPU3
  0:         52          0          0          0   IO-APIC   2-edge      timer
  1:          0          0          0          0   IO-APIC   1-edge      i8042
 24:    1200345          0          0          0   PCI-MSI 65536-edge      eth0
 27:     450221          0          0          0   PCI-MSI 327680-edge      nvme0q0

Що означає вивід: Якщо одне CPU обробляє величезну кількість переривань (мережа, NVMe), це може відбирати час у «гарячого» потоку гри.

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

Завдання 8: Визначити, чи ви зависаєте на I/O (стрімінговий тиск)

cr0x@server:~$ iostat -xz 1 3
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
         21.14    0.00    3.05    0.80    0.00   74.99

Device            r/s     w/s   rkB/s   wkB/s  %util  await
nvme0n1         120.0    15.0  8200.0  1200.0   35.0   2.10

Що означає вивід: Помірний %util і низький await свідчать, що зберігання не є обмежувачем. Високі піки await корелюють із підвисаннями під час обходу сцен.

Рішення: Якщо await високий — перевірте фонові оновлення, антивірус, або насиченість SSD; інакше зосередьтесь на часі кадру CPU/GPU.

Завдання 9: Відловити термальне тротлінг («невидимий ручник»)

cr0x@server:~$ sensors | egrep -i 'Tctl|Package|Core|temp|fan'
Tctl:         +86.5°C
Core 0:       +84.0°C
Core 1:       +83.5°C
fan1:        1850 RPM

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

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

Завдання 10: Перевірити швидкість пам’яті й чи запущено «безпечний» профіль

cr0x@server:~$ sudo dmidecode -t memory | egrep -i 'Speed:|Configured Memory Speed'
Configured Memory Speed: 4800 MT/s
Speed: 6000 MT/s

Що означає вивід: Номінальна швидкість RAM проти налаштованої швидкості. Ігри, обмежені CPU на 1080p, часто чутливі до затримок і пропускної здатності пам’яті.

Рішення: Якщо налаштована швидкість низька — увімкніть правильний XMP/EXPO профіль і перевірте стабільність.

Завдання 11: Знайти фонові процеси, що крадуть час кадру при високому FPS

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
  PID COMMAND         %CPU %MEM
 4123 game.exe        62.5  8.1
 2311 obs             12.2  3.4
 1990 chrome           6.8  2.1

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

Рішення: Якщо сторонні процеси споживають суттєвий CPU — закрийте їх або перемістіть захоплення на окрему машину, якщо вам важлива стабільність 240 Гц.

Завдання 12: Перевірити, чи ви вдаряєтесь об ліміт кадрів (ви будете здивовані)

cr0x@server:~$ grep -R "MaxFPS" -n ~/.config/game/config.ini | head
42:MaxFPS=144

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

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

Завдання 13: Виміряти затримки на боці CPU і переключення контекстів під час знімання

cr0x@server:~$ pidof game.exe
4123

cr0x@server:~$ sudo pidstat -p 4123 -w -u 1 5
Linux 6.8.0 (server) 	01/21/2026 	_x86_64_	(16 CPU)

01:15:11 PM   UID       PID    %usr %system  %CPU   cswch/s nvcswch/s  Command
01:15:12 PM  1000      4123   58.00    4.00 62.00   1200.00    35.00  game.exe
01:15:13 PM  1000      4123   57.00    4.00 61.00   1400.00    40.00  game.exe

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

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

Завдання 14: Перевірити поведінку hugepages/THP (може впливати на варіативність часу кадру)

cr0x@server:~$ cat /sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

Що означає вивід: Налаштування THP можуть впливати на поведінку пам’яті; деякі навантаження бачать варіативність латентності.

Рішення: Якщо ви женетеся за мікропідвисаннями на Linux — протестуйте режими THP. Міняйте по одній речі і логируйте зміни часу кадру.

Жарт №2: Графіки часу кадру як аналіз крові — ніхто їх не любить, але всі потребують, і результати завжди звинувачують те, чого ви не очікували.

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

Міні-історія 1: Інцидент, спричинений неправильною припущенням

Студія мала ПК-систему, що «виглядала нормально» у лабораторії на 4K. Завантаження GPU було високим, час кадру плавний. Вони випустили конкурентний
пресет, орієнтований на 1080p/240 Гц. Через кілька днів почали надходити скарги: «GPU лише на 60%», «CPU на 40%», «підвисання в сутичках», «моя дорога відеокарта зламана».

Припущення було просте і неправильне: «Якщо загальне завантаження CPU низьке, він не може бути вузьким місцем». Вони дивилися на середнє по 16 ядрах і раділи.
Насправді головний потік насиджував одне ядро, а потік подачі рендеру іноді блокувався на локі в драйвері, коли в полі зору з’являлося багато дрібних об’єктів.

Їхній внутрішній план тестування не містив «низькі налаштування + uncapped FPS + високий refresh», бо в лабораторії тестували кінематично: 4K, максимальні налаштування,
милувалися освітленням і випускали. Клієнти ж намагалися вирізати кожен мілісекунд затримки і виводили на поверхню найгіршу поведінку CPU.

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

Міні-історія 2: Оптимізація, що обернулась проти

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

Потім стало гірше: на 1080p користувачі скаржилися на випадкові підвисання під час руху камери, яких не було раніше. Графіки GPU виглядали «сумними».
CPU раптово підскакував у сплесках, і підвисання корелювали з чатом резидентності активів. Кеш збільшив пам’ять; ОС почав активніше виводити сторінки на машинах із менше RAM.
Кожен рух камери викликав каскад «допоміжної» стрімінгової роботи, яка відбирала час у потоку підготовки рендеру.

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

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

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

Інша команда обслуговувала парк робочих станцій для симуляцій і іноді демонстрацій з геймерським навантаженням на виставках. Вони мали правило:
кожне оновлення драйвера повинно проходити через канарковий пул із повторюваним набором бенчмарків на трьох роздільностях (1080p конкурентний, 1440p збалансований, 4K демонстраційний).

Це було геть не гламурно. Люди скаржились, що це гальмує «інновації». Але команда вела логи: завантаження CPU по ядрах, частоти GPU, стан PCIe-лінку,
процентилі часу кадру і короткий дамп системних переривань. Ті ж скрипти, ті ж машини, та сама процедура. Без героїв.

Одного місяця оновлення драйвера трохи покращило 4K, але внесло спорадичні спайки на боці CPU на 1080p в одному шляхові застосунку. Канаркова прогонка
відразу це виявила: 99-й процентиль часу кадру підскочив, завантаження GPU впало, і контекстні переключення потоку подачі подвоїлися. Вони затримали оновлення
і подали звіт вендору з доказами, що не покладаються на відчуття.

Тиждень виставки пройшов без сорому. «Нудна практика» не про покращення продуктивності; вона про запобігання регресіям, які проявляються лише в CPU-bound режимах.
Користувачі ніколи не побачили, що не сталося — а це найвища похвала для операцій.

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

1) «Завантаження GPU низьке, отже моя відеокарта погана»

Симптоми: 50–70% завантаження GPU на 1080p, плато FPS, одне CPU-ядро близько 100%.

Причина: Обмеження CPU (головний потік або накладні витрати драйвера). GPU чекає на роботу.

Виправлення: Підніміть роздільність або увімкніть важчі GPU-фічі, щоб підтвердити масштабування; зменшіть CPU-важкі налаштування (дальність огляду, натовп);
оновіть CPU/пам’ять, якщо хочете вищого FPS.

2) «Мій CPU лише на 35%, отже він не може бути обмеженням»

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

Причина: Блокування одного «гарячого» потоку; середні значення ховають насичення окремих ядер.

Виправлення: Перегляньте навантаження по ядрах; знайдіть обмежувальний потік; оптимізуйте для одноядерної продуктивності і зменшіть джерела contention.

3) «Зменшення налаштувань завжди має підвищити FPS»

Симптоми: Зниження налаштувань нічого не дає на 1080p; FPS не змінюється, завантаження GPU падає.

Причина: Ви вже були обмежені CPU. Зниження налаштувань зняло роботу з GPU, але не змінило роботу CPU.

Виправлення: Якщо вам потрібен вищий FPS — сприймайте це як проблему CPU: тюнінг пам’яті, оновлення CPU, налаштування рушія, що зменшують CPU-роботу, або прийміть ліміт.

4) «Підвисання мусить бути через SSD»

Симптоми: Випадкові підвисання, особливо при повороті; SSD «швидкий на папері».

Причина: Часто це компіляція шейдерів на CPU, створення PSO або координація стрімінгу; іноді антивірус сканує директорію гри.

Виправлення: Перевірте await I/O; перевірте фонові задачі; за можливості закомпілюйте шейдери заздалегідь; виключіть директорії гри з реального сканування.

5) «Новий драйвер знизив FPS — значить відеокарта винна»

Симптоми: 4K без змін, 1080p гірше; зростання спайків часу кадру; частоти GPU в нормі.

Причина: Регіресія по накладних витратах на боці CPU у драйвері або інша поведінка планування/локування.

Виправлення: Відкотіть і порівняйте з послідовними тестами; тримайте канарки; звітуйте вендору з даними часу кадру і per-core доказами, а не скриншотами завантаження.

6) «Швидкість PCIe не має значення»

Симптоми: Середній FPS нормальний, але 1% lows гірші; підвисання при інтенсивному стрімінгу; дивна продуктивність після змін апаратного забезпечення.

Причина: GPU несподівано працює на x4/x8, або з’єднався на нижчій генерації через BIOS/слот/кабель/ризер.

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

7) «Необмежений FPS — завжди найкраще»

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

Причина: CPU працює в максимумі; фоновий джитер стає видимим; поведінка черги рендеру може погіршувати затримку.

Виправлення: Використайте ліміт FPS трохи нижче оновлення; налаштуйте 99-й процентиль часу кадру, а не лише піковий FPS.

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

Покроково: доведіть, де вузьке місце (не вгадуйте)

1. Тимчасово вимкніть обмеження: Вимкніть vsync, приберіть ліміти FPS, переконайтесь, що VRR не фіксує вас на стелі.
2. Запустіть повторювану сцену: Та сама карта, той самий шлях камери, однаковий проміжок часу.
3. Протестуйте 1080p → 1440p → 4K: Зберігайте налаштування незмінними. Запишіть FPS і 1% lows.
4. Запишіть часи кадру: Захопіть CPU і GPU час кадру, якщо інструменти дозволяють.
5. Перевірте по ядрам CPU: Шукайте гарячий потік, що насичує ядро.
6. Перевірка термального стану: Переконайтесь, що немає тротлінгу, і частоти стабільні.
7. Перевірка PCIe лінку: Підтвердіть x16 і очікувану генерацію.

Покроково: якщо ви CPU-bound на 1080p і хочете більше FPS

1. Пріоритет — IPC і boost CPU: Висока одноядерна продуктивність важливіша за велику кількість ядер після певного моменту.
2. Виправте конфігурацію пам’яті: Увімкніть XMP/EXPO і забезпечте стабільність; уникайте суміщених комплектів.
3. Зменшіть CPU-важкі налаштування: Дальність огляду, щільність натовпу, деталізація фізики, тіні (частина роботи по тінях на боці CPU), частота симуляції.
4. Зменшіть тиск викликів малювання: Налаштування в грі, що зменшують кількість об’єктів або фоліажу, допомагають.
5. Навмисно встановіть кап FPS: Встановіть кап, який ви можете підтримувати з гарними 1% lows. Стабільні 180 краще за стрибкоподібні 240.
6. Приберіть джерела джитеру: Оверлеї, захоплення, програмне забезпечення RGB, відтворення відео в браузері — усе, що часто прокидається.

Покроково: якщо ви GPU-bound на 4K і хочете кращої картинки або стабільнішого FPS

1. Використайте апскейлінг: Віддавайте перевагу DLSS/FSR/XeSS, які зберігають деталі без примусового нативного рендеру.
2. Цілтесь у дорогі проходи: Ray tracing, важкий AO, ультра тіні та якісні віддзеркалення часто домінують.
3. Стежте за використанням VRAM: Перевантаження відеопам’яті може викликати підвисання та пейджинг.
4. Віддавайте перевагу стабільним часам кадру: Налаштовуйте під 99-й процентиль часу кадру, зменшуючи налаштування, що спричиняють спайки, а не лише середнє навантаження.

Поширені питання

1) Чи «вузьке місце CPU» те саме, що «мій процесор занадто повільний»?

Не завжди. Це може бути «процесор недостатньо швидкий», але також — накладні витрати драйвера, серійне пляшкове горло в одному потоці або джитер ОС. Симптом — голодування GPU.

2) Чому апгрейд GPU допомагає на 4K, але не на 1080p?

4K збільшує роботу на кадр настільки, що GPU стає найповільнішою ланкою. На 1080p GPU завершує роботу швидко і чекає, коли CPU підготує наступну партію.

3) Якщо я CPU-bound, чи варто підвищувати графічні налаштування?

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

4) Чому зниження роздільності іноді зменшує підвисання?

Це може знизити навантаження на GPU і пропускну здатність VRAM, що згладжує GPU-bound спайки. Але якщо підвисання на боці CPU (компіляція шейдерів, стрімінг), зміни роздільності можуть не допомогти.

5) Чи допоможе більше ядер процесора в 1080p?

Іноді так, але не гарантовано. Багато ігор обмежені одним-двома «гарячими» потоками. Бажана сильна одноядерна продуктивність і низька затримка пам’яті, а не лише кількість ядер.

6) Чи завжди DX12/Vulkan краще для CPU-лімітів?

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

7) Чому завантаження CPU низьке, але FPS все одно обмежений?

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

8) Який найшвидший тест, щоб підтвердити CPU vs GPU bound?

Збільште роздільність, зберігаючи налаштування незмінними. Якщо FPS майже однаковий — CPU-bound. Якщо FPS падає — GPU-bound.

9) Чи справді швидша оперативна пам’ять і затиски таймінгів важливі?

Для CPU-bound сценаріїв з високим FPS вони можуть мати значення. Латентність пам’яті впливає на швидкість, з якою «гарячі» потоки обходять стан гри, формують командні буфери і обробляють дані викликів малювання.
Це не магія, але це вимірюванно.

10) Чи варто ставити ліміт FPS, навіть якщо я хочу низьку затримку?

Часто — так. Розумний ліміт (трохи нижче оновлення) може зменшити черги, стабілізувати час кадру і знизити температуру CPU. Результат може відчуватися більш чутливим, ніж хаотичний uncapped режим.

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

Процесори створюють вузьке місце для GPU на 1080p, бо робота GPU на кадр зменшується, тоді як оркестраційна робота CPU здебільшого не змінюється. На 4K вартість пікселів вибухає,
GPU стає повільною ланкою, і гріхи CPU ховаються за стіною шейдингу та пропускної здатності.

Робіть дисципліновано:

• Доведіть, CPU-bound чи GPU-bound, за допомогою масштабування роздільності та часу кадру.
• Якщо ви CPU-bound на 1080p з високим FPS — інвестуйте в CPU boost/IPC, налаштування пам’яті і параметри, що зменшують навантаження CPU, а не в ще одну відеокарту.
• Якщо ви GPU-bound на 4K — припиніть примусово рендерити натив; добрий апскейлер дасть вам простір без таких великих компромісів.
• Впровадьте нудну, відтворювану рутина бенчмарків. Вона запобігає регресіям продуктивності і рятує від сперечань із графіками завантаження.