FSR пояснено: як AMD зробила апскейлінг мейнстримом

Чому апскейлінг переміг (і чому FSR був важливий)

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

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

AMD зробила апскейлінг мейнстримом не тому, що FSR був «найкращим» у кожному скриншотному порівнянні, а тому, що його можна було розгорнути.
Він був відкритим, крос-вендорним і не вимагавав специфічного шляху з AI-акселерцаторами. Це дозволило студіям ставитися до нього як до функції,
а не як до переговорів з партнером.

Що «мейнстрим» означає в операційному сенсі

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

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

FSR 1, 2, 3: родинне дерево без маркетингового туману

FSR 1: просторове масштабування плюс підвищення різкості

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

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

FSR 2: тимчасова реконструкція (доросла версія)

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

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

FSR 3: генерація кадрів приєднується до розмови

FSR 3 додає генерацію кадрів (інтерполяцію) плюс управління затримкою в стилі anti-lag (залежно від реалізації).
Він може драматично підвищити відображувані FPS, синтезуючи проміжні кадри з руху.
Це не те саме, що «більше продуктивності». Це більше відображуваних кадрів; симуляція може залишатися на старій частоті.

Генерація кадрів — це момент, коли ви перестаєте говорити про середній FPS і починаєте говорити про калібрування кадрів,
затримку введення й артефакти при швидкому русі. Саме тут «мій бенчмарк каже 160 FPS» зустрічається з «чому відчувається як 60?»

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

Як FSR працює під капотом (що йому потрібно, що ламає)

Просторове vs тимчасове: реальна різниця

Просторове масштабування — це перетворення на кадр. Воно бачить пікселі й краї. У нього немає пам’яті.
Саме тому воно надійне і саме тому не в змозі магічно відновити підпіксельні деталі.

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

Вхідні дані, які очікують тимчасові апскейлери класу FSR 2

• Вектори руху, які представляють переміщення пікселів/геометрії між кадрами.
• Буфер глибини для обробки дисоклюжин і рішень щодо реконструкції.
• Зсув джиттера і послідовний шаблон джиттера камери.
• Експозиція / пре-експозиція, щоб змішування історії не вибухало при зміні яскравості.
• Реактивні / прозорі маски, щоб зменшити привиди на частинках, воді та елементах, схожих на UI.

Пропустіть один з них — і ви все ще можете випустити. Ви просто випускаєте загадку.

Де інтеграція зазвичай йде не так

Найбільший режим відмови — це не «алгоритм поганий». Це «вхідні дані брешуть».
Вектори руху, які не включають скіновані анімації. Вектори, згенеровані в іншому просторі, ніж очікується.
Глибина, яка пост-оброблена або інвертована без відповідної конфігурації.
Джиттер застосовано до одного проходу, але не до того, який годує вектори.
UI намальовано до апскейлу і потім поводиться, ніби це частина світу.

Апскейлери схожі на моніторинг: вони чесно підсилюють те, що ви їм даєте, включно з вашими помилками.

Різкість: регулятор якості, що одночасно породжує скарги клієнтів

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

Жарт №1: Поставити різкість на 100% — як кричати на нараді: технічно ви ясніші, але ніхто не щасливий.

Генерація кадрів: чому людям з операцій важливо це знати

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

Одна цитата про надійність, яка має бути в кожному огляді продуктивності:
«Надія — це не стратегія.» — Генерал Гордон Р. Салліван

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

Практичне бенчмаркування: вимірюємо те, що відчувають гравці

Чому середній FPS — пастка

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

Бенчмаркуйте як SRE, не як маркетинговий слайд

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

Приймайте рішення, базуючись на:
медіані часу кадру, p95, p99 і p99.9, якщо можете.
Потім валідуйте вимірюванням затримки введення, якщо використовуєте генерацію кадрів.

Режими якості — це не просто «якість проти продуктивності»

Класичні режими (Quality, Balanced, Performance, Ultra Performance) насправді різні вхідні роздільності й бюджети реконструкції.
Зниження вхідної роздільності може виявити проблеми:
тонка геометрія мерехтить, муар-патерни, агресивний LOD попінг, спекулярний аліасинг.
Іноді «Balanced» виглядає краще за «Performance» не тому, що алгоритм змінюється, а тому, що вхідні дані перестають його голодувати.

Визначте, що ви оптимізуєте

Якщо ви таргетуєте 60 Гц телевізори — оптимізуєте стабільність і послідовне калібрування кадрів.
Якщо орієнтуєтесь на монітори з високою частотою оновлення — оптимізуйте затримку й мінімальні артефакти при швидкому русі.
Налаштування FSR (і використання генерації кадрів) повинні слідувати за цим рішенням, а не навпаки.

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

Це практичні завдання, які ви можете виконати на Linux-геймінг/воркстейшн або на збірці/QA-машині, щоб діагностувати GPU/CPU/драйвер і
проблеми з калібруванням кадрів навколо апскейлінгу. Мета не в тому, щоб «довести, що FSR хороший». Мета — знайти обмеження і виправити пайплайн.

Завдання 1: Підтвердьте базові GPU, драйвер та ядро

cr0x@server:~$ uname -r
6.8.0-41-generic

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

Рішення: Якщо у вас старе LTS-ядро з новими GPU, перед тим як звинувачувати артефакти FSR протестуйте на новішому стеку ядра/драйвера.

cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
03:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 22 [Radeon RX 6700 XT] [1002:73df]

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

Рішення: Використовуйте це, щоб групувати тестові машини; не порівнюйте результати між різними класами GPU й не називайте це «варіацією FSR».

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

cr0x@server:~$ glxinfo -B | sed -n '1,25p'
name of display: :0
display: :0  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: AMD (0x1002)
    Device: AMD Radeon RX 6700 XT (radeonsi, navi22, LLVM 17.0.6, DRM 3.57, 6.8.0-41-generic) (0x73df)
    Version: 24.1.3
OpenGL version string: 4.6 (Compatibility Profile) Mesa 24.1.3

Що це означає: Ідентифікує версію Mesa і шлях драйвера. Багато скарг на FSR — це регресії драйвера або дивні поведінки компілятора шейдерів.

Рішення: Якщо артефакти з’явилися «після оновлення», зафіксуйте або бісектіть версії Mesa/драйвера. Не налаштовуйте різкість, щоб сховати регресію.

Завдання 3: Підтвердьте ідентичність Vulkan-драйвера (FSR часто використовується у Vulkan-іграх)

cr0x@server:~$ vulkaninfo --summary | sed -n '1,40p'
VULKANINFO SUMMARY
==================
Instance Version: 1.3.283

Devices:
========
GPU0:
    apiVersion         = 1.3.280
    driverVersion      = 2.0.310
    vendorID           = 0x1002
    deviceID           = 0x73df
    deviceName         = AMD Radeon RX 6700 XT

Що це означає: Підтверджує версію Vulkan і використовуваний пристрій.

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

Завдання 4: Визначте, чи обмежений ви CPU або GPU під час виконання

cr0x@server:~$ sudo apt-get install -y mangohud
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  mangohud
0 upgraded, 1 newly installed, 0 to remove and 12 not upgraded.

Що це означає: MangoHud дає графіки часу кадру й накладку метрик GPU/CPU для Vulkan/OpenGL.

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

cr0x@server:~$ mangohud --dlsym vkcube
MangoHud: Uploading is disabled (permit_upload = 0)

Що це означає: Ви можете інжектити накладку в Vulkan-додаток. У грі запуск буде через опції запуску Steam аналогічно.

Рішення: Якщо завантаження GPU низьке, а часи кадру високі, не крутить спочатку FSR; швидше за все вузьке місце на CPU/IO.

Завдання 5: Захопіть базові параметри калібрування кадрів (режим презентації та частота оновлення)

cr0x@server:~$ xrandr --verbose | sed -n '1,40p'
Screen 0: minimum 8 x 8, current 2560 x 1440, maximum 32767 x 32767
DisplayPort-0 connected primary 2560x1440+0+0 (0x4a) normal (normal left inverted right x axis y axis) 597mm x 336mm
	2560x1440     165.00*+  144.00    120.00    60.00

Що це означає: Показує частоту оновлення і поточний режим.

Рішення: При оцінці генерації кадрів FSR 3 зафіксуйте тест на фіксовану частоту оновлення (наприклад, 120 Гц), щоб інтерпретувати калібрування кадрів.

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

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

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

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

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

Що це означає: Встановлює governor performance для стабільних тестів.

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

Завдання 7: Підтвердіть, що немає теплового тротлінгу

cr0x@server:~$ sensors | sed -n '1,40p'
amdgpu-pci-0300
Adapter: PCI adapter
edge:         +76.0°C  (crit = +100.0°C, hyst = -273.1°C)
junction:      +92.0°C  (crit = +110.0°C, hyst = -273.1°C)

k10temp-pci-00c3
Adapter: PCI adapter
Tctl:         +83.5°C

Що це означає: Високі температури junction можуть спричинити падіння частот GPU; CPU Tctl може обмежувати буст.

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

Завдання 8: Спостерігайте частоти та завантаження GPU під навантаженням

cr0x@server:~$ sudo radeontop -d - -l 1 | head -n 10
Dumping to stdout
gpu 99.12%  ee 0.00%  vgt 92.45%  ta 88.12%  sx 61.33%  sh 97.44%  spi 72.88%  sc 55.11%
vram  512.00mb  gtt  238.00mb  mclk 2000.00MHz  sclk 2450.00MHz

Що це означає: GPU практично насичений; FSR (зменшення внутрішньої роздільності) може допомогти.

Рішення: Якщо GPU завантажений, тестуйте режими FSR Quality vs Balanced і порівнюйте p99 часи кадру, а не лише середній FPS.

Завдання 9: Перевірте тиск VRAM (статтер, що виглядає як «FSR зламався»)

cr0x@server:~$ cat /proc/meminfo | grep -E "MemAvailable|SwapTotal|SwapFree"
MemAvailable:   11248320 kB
SwapTotal:       2097148 kB
SwapFree:        2097148 kB

Що це означає: Доступна оперативна пам’ять системи здорова; swap не використовується.

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

cr0x@server:~$ sudo cat /sys/kernel/debug/dri/0/amdgpu_vram | head
VRAM total size: 12272 MiB
VRAM usable size: 12272 MiB
VRAM used: 10384 MiB

Що це означає: Використання VRAM високе. Апскейлінг може зменшити розміри рендер-таргетів, але текстури та геометрія все одно домінують.

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

Завдання 10: Помітити компіляцію шейдерів або проблеми з кешем пайплайнів

cr0x@server:~$ journalctl --user -b | grep -iE "shader|pipeline|vulkan" | tail -n 10
Jan 13 09:11:22 desktop steam[4121]: Fossilize INFO: Using read-only directory: /home/cr0x/.steam/steam/steamapps/shadercache
Jan 13 09:11:29 desktop steam[4121]: Fossilize INFO: Processed 128 pipeline cache entries

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

Рішення: Якщо підгальмовування збігається з cache miss, прогрійте кеші у QA-прогонах; не приписуйте підвисання режимам FSR при першому запуску.

Завдання 11: Виміряйте затримку дискового вводу/виводу (вузьке місце стрімінгу ассетів)

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

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.10    2.55    0.00   82.04

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         85.00   9200.00     0.00   0.00    1.20   108.24   42.00   2100.00     5.00  10.64    3.80    50.00    0.30  22.00

Що це означає: r_await/w_await низькі; диск тут не є вузьким місцем.

Рішення: Якщо await підскакує (десятки мс) під час підглючування — вирішуйте IO/стрімінг спочатку. Апскейлінг не виправить повільний диск.

Завдання 12: Перевірте фоні процеси, що крадуть CPU, і шум планування

cr0x@server:~$ top -b -n 1 | head -n 20
top - 09:22:10 up  2:11,  1 user,  load average: 3.02, 2.41, 2.12
Tasks: 356 total,   2 running, 354 sleeping,   0 stopped,   0 zombie
%Cpu(s): 11.3 us,  2.8 sy,  0.0 ni, 84.9 id,  0.8 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem :  32036.7 total,  13420.2 free,  10412.1 used,   8204.4 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.  21624.6 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 4102328 512844 142112 S   3.3   1.6   1:12.44 steam
 2210 cr0x      20   0  834520  94128  62152 S   2.7   0.3   0:33.10 chrome

Що це означає: Загалом CPU переважно простоює; явних хобів немає. Але браузери та оверлеї все одно можуть вносити джиттер.

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

Завдання 13: Перевірте тип композитора/сесію (різниця Wayland/Xorg)

cr0x@server:~$ echo $XDG_SESSION_TYPE
wayland

Що це означає: Сесія Wayland. Деякі інструменти захоплення/оверлеї працюють інакше, ніж на Xorg.

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

Завдання 14: Захопіть простий базовий FPS та метрику часу кадру з логів MangoHud

cr0x@server:~$ mangohud --output_folder /tmp/mhud --log_duration 30 --dlsym vkcube
MangoHud: writing output to /tmp/mhud

Що це означає: Створює короткий лог у /tmp/mhud з статистикою часу кадру.

Рішення: Запустіть одного разу у нативі, одного разу з увімкненим FSR (в грі). Порівняйте p99 часи кадру, щоб вирішити, чи режим дійсно покращує відчуття.

Жарт №2: «У мене на машині працює добре» — це не бенчмарк; це риса особистості.

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

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

Перше: класифікуйте скаргу

• Розмите / розмазані / м’яке → ймовірно занадто низька вхідна роздільність, низька різкість або некоректний масштаб рендеру.
• Привиди / сліди → ймовірно погані вектори руху, відсутня реактивна маска або проблеми з прозорістю.
• Мерехтіння / повзання країв → аліасинг, надмірна різкість або нестабільна історія/джиттер.
• Високий FPS, але відчуття гірше → генерація кадрів без управління затримкою, CPU-завантаження базового кадру, невідповідність VRR/VSync.
• Підгальмовування / заїдання → стрімінг, компіляція шейдерів, тиск VRAM, фонові задачі, політика живлення.

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

Апскейлінг — це головним чином інструмент зменшення GPU-часу. Якщо ви CPU-bound, FSR може мало допомогти або навіть погіршити ситуацію, перемістивши
навантаження в інші проходи. Використовуйте накладки метрик (завантаження GPU, розбиття часу кадру якщо доступно).

• Якщо GPU завантажений і часи кадру падають при зниженні роздільності → GPU-bound. FSR ймовірно допоможе.
• Якщо завантаження GPU низьке і часи кадру не змінюються зі зміною роздільності → CPU/IO-bound. Виправте це спочатку.

Третє: перевірте тимчасові входи (класи FSR 2)

Якщо артефакти тимчасові (привиди, нестабільні деталі), вважайте, що входи неправильні, доки не доведено протилежне.
Перевірте вектори руху в анімованих об’єктах, частинках, прозоростях та при різких змінах камери.

• Чи вектори включають скіновані меші?
• Чи в правильному координатному просторі і в правильному масштабі?
• Чи джиттер застосовано послідовно до кольору, глибини і генерації векторів?
• Чи авторські реактивні маски для проблемних матеріалів?

Четверте: ізолюйте проблеми презентації

Генерація кадрів і VRR можуть створювати «виглядає плавно, але відчувається погано» звіти. Тестуйте з:
фіксованою частотою проти VRR, VSync вкл/викл, обмеження кадрів вкл/викл і порівнюйте послідовні сценарії.

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

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

Три короткі історії з практики

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

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

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

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

Виправлення не було «вимкнути апскейлінг». Це було відновлення векторів руху для проходу частинок і додавання реактивної маски
для конкретних водяних матеріалів. Також змінили розгортання: за замовчуванням ввімкнено лише після телеметричного шлюзу та тижня канарного запуску.

Урок: апскейлер не зламав гру. Він виявив припущення: «частинкам не потрібні вектори».
У тимчасовій області все потребує векторів — або ви повинні сказати апскейлеру не довіряти історії.

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

Корпоративний візуалізаційний додаток (уявіть щось поруч з CAD, багато тонких ліній) інтегрував FSR 1 як швидке вирішення продуктивності
на інтегрованих GPU. Хтось вирішив агресивно підкрутити різкість, щоб дротяні моделі «виглядали чітко».
Демо виглядали різкими на статичних скриншотах.

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

Команда відповіла підвищенням масштабу рендеру, що покращило якість, але відкусило назад продуктивність — знищивши причину, чому FSR 1 взагалі був прийнятий.
Гірше того, новий масштаб спричинив тиск на VRAM на низько-ендових системах через більші рендер-таргети.
Тепер у них було мерехтіння і іноді підгальмовування.

Остаточне виправлення було нудним: знизили різкість, додали тонкий AA-прохід для ліній, адаптований під їхній вміст,
і відкрили для користувача слайдер «стабільність vs чіткість» з розумними дефолтами. Також задокументували, що FSR 1 — не чарівна паличка
для субпіксельного лінійного арту.

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

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

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

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

Через місяці оновлення драйвера спричинило спорадичні скарги на мерехтіння. Команда не дискутувала думками.
Вони запустили repro pack на двох версіях драйвера, знайшли регресію, ізольовану до одного постпроцесу, і випустили невелике пом’якшення,
одночасно подавши чистий баг-репорт постачальнику з захопленнями.

Гравці побачили швидкий патч. Інженери уникли панічного переписування. Менеджмент отримав таймлайн з доказами.
І ніхто не мусив «довіряти відчуттям» одного скриншотного рецензента.

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

Типові помилки (симптоми → корінна причина → виправлення)

1) UI виглядає м’яким або розмитим

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

Корінна причина: UI відображається в 3D-сцені до апскейлу або UI обробляють як контент, що може бути репроєктований історією.

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

2) Привиди за рухомими персонажами

Симптоми: Сліди за гравцями/NPC, особливо на висококонтрастному тлі.

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

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

3) Мерехтіння листви та тонкої геометрії

Симптоми: Листя іскриться; паркани повзають; тонкі дроти аліасяться під рухом камери.

Корінна причина: Вхідна роздільність занадто низька для контенту; надмірна різкість; нестабільна послідовність джиттера TAA; занадто агресивний mip bias.

Виправлення: Використовуйте вищий режим якості FSR; зменшіть різкість; перегляньте mip bias і LOD; забезпечте стабільний джиттер і правильне зважування історії.

4) «FSR підвищив FPS, але гра відчувається гірше»

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

Корінна причина: CPU-завантаження базового фрейму; генерація кадрів без контролю затримки; буферизація черги презентації; невідповідність VRR/VSync.

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

5) Випадкові підгальмовування після увімкнення апскейлу

Симптоми: Мікро-заморозки кожні кілька секунд; гірше при першому запуску або після патчу.

Корінна причина: Компіляція шейдерів/створення пайплайнів; стрімінг IO; перевантаження VRAM; фонові задачі.

Виправлення: Прогрівайте кеші шейдерів у QA; постачайте кеші пайплайнів де можливо; зменште тиск VRAM через текстури; профілюйте IO; вимикайте фонові оверлеї під час тесту.

6) Перезрізана «хрустка» картинка з шумними спекулярами

Симптоми: Металеві поверхні іскряться; відблиски повзають; зображення виглядає зернистим.

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

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

7) Артефакти на частинках, димі, воді та прозоростях

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

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

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

8) Результати бенчмарку не відповідають звітам гравців

Симптоми: Лабораторні показники кажуть про покращення; гравці все одно скаржаться на підгальмовування.

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

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

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

Покроково: вибір правильних дефолтів режиму FSR

1. Встановіть ціль: 60 стабільно, 90 стабільно, 120+ конкурентно. Не прикидайте, що один дефолт підходить усім.
2. Виміряйте базове вузьке місце: GPU-bound чи CPU-bound в нативі і при зниженій роздільності.
3. Виберіть найм’якший режим, що досягає мети: віддавайте перевагу Quality/Balanced перед Performance, коли можливо.
4. Встановіть консервативну різкість: почніть нижче, ніж здається правильним; дайте користувачам можливість підвищити.
5. Перевірте у пастках артефактів: листя, паркани, частинки, швидкі панорами, яскравий HUD на темних сценах.
6. Перевірте поведінку при холодному старті: перша компіляція шейдерів і стрімінг.
7. Перевірте композицію UI: UI має бути у роздільності виводу і стабільним.
8. Задокументуйте відомі обмеження: тонкі лінії, деякі прозорості, екстремально низька вхідна роздільність.

Чекліст інтеграції: тимчасове масштабування класу FSR 2

• Вектори руху включають: скіновані меші, жорсткі тіла, рух камери та анімовані UV/матеріали де потрібно.
• Буфер глибини відповідає очікуваній конвенції (reversed Z, діапазон, лінеаризація як потрібно).
• Джиттер застосовано послідовно до кольору, глибини та генерації векторів руху.
• Експозиція стабільна між кадрами; різкі зміни експозиції скидають історію або зменшують її вагу.
• Реактивні маски для: частинок, води, прозорого скла, емісивних вивісок, анімованої альфа-тестованої листя.
• Різкі зрізи камери і телепорти ініціюють скидання історії (або еквівалентну логіку).
• UI рендериться після апскейлу (переважно) або виключається з повторного використання історії.
• Дефолти різкості консервативні і протестовані у русі, а не лише на статичних кадрах.

Операційний чекліст: випуск без підпалу

• Канарний rollout для змін, що увімкнені за замовчуванням; відстежуйте рівень скарг за моделлю GPU/постачальником і гілкою драйвера.
• Регресійний harness з детермінованими сценами; захоплюйте розподіли часу кадру та скриншоти артефактів.
• Чіткий сценарій для служби підтримки: які налаштування просити (режим, різкість, генерація кадрів, VRR, VSync).
• Матриця драйверів/ОС для QA, що відображає реальність, а не лише ваші дев-риги.
• План відкату: дозволяти відключення/заміни апскейлера без поломки збережень або масштабування UI.

Цікаві факти та історичний контекст

Апскейлінг не з’явився нізвідки. Ось конкретні контекстні пункти, що пояснюють, чому FSR отримав такий резонанс:

1. FSR 1 запущено у 2021 році, позиціювався як швидка просторові альтернатива, яку можна широко прийняти на різних GPU.
2. Крос-вендорний підхід FSR мав значення: він міг працювати на конкуруючому обладнанні, що знизило бар’єри прийняття для студій на ПК.
3. Тимчасове масштабування передувало FSR у багатьох рушіях як реконструкція на основі TAA; FSR 2 формалізував шлях високої якості від вендора.
4. FSR 2 змістив дискурс від «трюків різкості» до «годуйте мене правильними векторами руху», витягнувши на світло питання коректності рушія.
5. Апскейлінг прив’язався до прийняття трасування променів: витрати RT штовхали більше проєктів до реконструкції, щоб зберегти прийнятні FPS.
6. FSR 3 приніс генерацію кадрів в екосистему AMD, розширивши дискусію про апскейлінг до питань затримки і калібрування кадрів, а не лише пропускної здатності.
7. Відкриті шейдерні підходи дозволили розробникам інспектувати і адаптувати інтеграційні деталі легше, ніж закриті рішення.
8. Очікування «консолі→ПК» просунули мислення «режим продуктивності» в меню ПК, нормалізувавши масштабування внутрішньої роздільності.
9. Драйвери і зрілість компіляторів сильно впливають на результат: дві системи з «одним і тим же GPU» можуть давати різні профілі підгальмовувань у різних гілках драйвера.

FAQ

1) Чи FSR — це «справжній 4K»?

Ні. FSR рендерить у нижчій внутрішній роздільності і реконструює до роздільності виводу. Мета — «виглядати достатньо близько при звичній відстані перегляду»,
а не відповідати піксель-в-піксель.

2) Чому FSR іноді виглядає розмитим?

Зазвичай тому, що вхідна роздільність занадто низька для складності сцени, різкість низька, або постпроцесинг гри не дружній до реконструкції (фільмове зерно, агресивна DOF, рухомий розмиття).

3) Чому FSR іноді виглядає занадто різким або шумним?

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

4) У чому практична різниця між FSR 1 і FSR 2?

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

5) Чи допоможе FSR, якщо я CPU-bound?

Не дуже. Зниження внутрішньої роздільності зменшує роботу GPU, але якщо CPU обмежує кадр, виграш може бути невеликим.
Діагностуйте CPU vs GPU перед тим, як чекати чудес.

6) Чому генерація кадрів іноді відчувається затриманою?

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

7) Який найкращий дефолтний режим FSR?

Для більшості проєктів: почніть з Quality (або Balanced на вищих роздільностях) і консервативної різкості. «Performance» — для випадків, коли він справді потрібен,
і ви ретельно протестували тонку геометрію і листя.

8) Чому частинки і прозорі ефекти виглядають гірше з тимчасовим апскейлінгом?

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

9) Чи зменшує увімкнення FSR використання VRAM?

Воно може зменшити розміри деяких рендер-таргетів, але текстури, буфери геометрії та структури трасування часто домінують у VRAM.
Якщо ви близькі до ліміту VRAM, знижуйте налаштування текстур та розміри кешів тіней перед тим, як чекати, що апскейлінг вирішить підгальмовування.

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

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

Якщо ви випускаєте або підтримуєте FSR у реальному світі, зробіть наступне:

1. Припиніть використовувати середній FPS як єдину метрику. Відстежуйте p95/p99 часи кадру та послідовність калібрування.
2. Побудуйте детермінований repro pack зі сценами, що навмисно навантажують тимчасову реконструкцію.
3. Валідуйте вектори руху і маски перед тим, як чіпати дефолти різкості.
4. Розділяйте GPU-bound виграші від проблем CPU/IO. Апскейлінг не вирішить компіляцію шейдерів або повільний стрімінг.
5. Випускайте розумні дефолти й прозорі перемикачі. Дайте користувачам просту опцію відключення, коли їх конфіг незвичний.

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