Якщо вам колись доводилося відправляти в продакшн графічну фічу, яка «працює на моїй машині», але має з’явитися на безлічі різних ПК, ви вже знаєте це відчуття:
один апдейт драйвера — і хаос, один амбітний параметр — і кадри по 45 мс, а користувачі, які гарантовано протестують ваш
найгірший сценарій назавжди.
Трасування променів (RT) опинилося саме в такій експлуатаційній реальності. Для AMD «наздоганяння» не було проблемою брендингу; це було рішенням щодо послідовності з управлінням ризиками.
У термінах продакшну: спочатку забезпечити коректність, сумісність і передбачувану продуктивність — потім масштабувати ефекти.
Чому «наздоганяти» було розумно
У техніці «наздоганяти» часто використовують як образу ті, хто ніколи не керував дорожньою картою в умовах обмежень:
енергобюджет, площа кристала, час верифікації, зрілість програмного екосередовища, паритет із консолями і приємна реальність того,
що ігри випускають студії з дедлайнами, а не теоретики з маркерами.
Рішення AMD вийти на апаратне трасування променів пізніше — і більш консервативно — має сенс, якщо розглядати GPU як виробничу систему.
GPU — це не одна фіча. Це стек: ISA, кеші, контролери пам’яті, планування, прошивка, драйвери, компілятори шейдерів,
API ОС, ігрові рушії та контент-пайплайни. RT навантажує майже все одночасно.
«Наддоганяти» означає дозволити іншим прийняти першу хвилю невідомих проблем: ранні краю API, помилки інтеграції рушіїв,
нові помилки авторингу контенту (погані матеріали вибухають у трейсерах), нестабільність драйверів при незвичних шаблонах шейдерів,
і дивні провали в продуктивності, які виникають, коли структури прискорення зустрічаються з реальними сценами.
Розумна стратегія — не «випустити RT першим». Розумна стратегія така:
- Випустіть RT, коли ваш програмний стек зможе це витримати (драйвер, компілятор, інструменти, покриття QA).
- Випустіть RT, коли ринок цього потребує (консолі, рушії, прийняття розробниками).
- Випустіть RT так, щоб не знищити растеризацію (адже більшість пікселів усе ще растеризуються).
- Випустіть RT з історією масштабування зображення (бо брутальна RT — це податок на продуктивність).
З точки зору SRE, AMD оптимізувала надійність і передбачувані результати для великої встановленої бази, а не лише заради верхівкового місця в бенчмарках. Це не боягузтво. Це операційна практика.
Жарт №1: Трасування променів — як обсервабіліті: увімкнувши його, ви одразу дізнаєтеся, скільки речей вам не хотілося б знати.
Факти та історичний контекст, що справді важать
Ось конкретні моменти (не тривіальні), що пояснюють, чому стратегія AMD щодо «наздоганяння» мала рацію:
- RT десятиліттями був «офлайн»: Ґрафічні/візуальні пайплайни у фільмах використовували трасування променів значно раніше за реальний час GPU, бо міняли час на якість.
- DXR формалізував масовий API: DirectX Raytracing зробив «RT як пайплайн» стандартом, а не демонстрацією від вендора.
- BVH — справжній робочий кінь: швидке RT залежить від побудови та обходу BVH; це не лише «додати RT-ядра».
- Ранні реалізації в реальному часі були гібридні: майже всі випущені ігри використовують растеризацію + обмежені RT-ефекти (тіні, віддзеркалення, AO), а не повне трасування шляху.
- Консолі мали значення: консолі на базі AMD принесли апаратне RT на велику фіксовану платформу, змусивши рушії розглядати RT як реальну фічу, а не опцію.
- Масштабування зображення стало частиною угоди RT: технології типу DLSS/FSR перетворили «занадто повільно» на «можливо випустити», жертвуючи роздільністю за допомогою часової реконструкції.
- Зрілість драйверів/компіляторів — конкурентна перевага: навантаження RT по-іншому навантажують компілятори шейдерів і розподіл регістрів, ніж класична растеризація.
- Продуктивність RT часто залежить від пам’яті/латентності: обхід може бути неузгодженим; кеші пропускають; латентність пам’яті стає тихим вбивцею.
- Послідовність часу кадру важливіша за пік FPS: підлагування від компіляції шейдерів або сплесків побудови BVH — те, що відчувають гравці й про що пишуть у підтримку.
Що насправді коштує трасування променів: таксономія вузьких місць
1) Вартість побудови/оновлення структур прискорення (BVH)
RT не починається з променів. Воно починається зі структур даних. BVH (або подібна структура) має бути побудована або оновлена для геометрії.
Динамічні сцени — анімовані персонажі, руйновані об’єкти, рухомі реквізити — додають вартість побудови/оновлення, і ця вартість може змінюватися щокадру.
В операційних термінах: робота BVH — це змінний пакетний таск на вашому критичному шляху. Якщо ви його не обмежите, він у два ночі надішле вам скарги про випадкові підлагування.
2) Розбіжність при обході й затіненні
Растеризація має когерентність: сусідні пікселі часто звертаються до схожих текстур, йдуть подібним шляхом керування, потрапляють у схожу геометрію.
RT може руйнувати цю когерентність: промені відбиваються в несхожі частини сцени. Це означає розбіжність виконання шейдерів і жахливу локальність кеша.
Ось чому «більше обчислень» не лінійно вирішує RT. Іноді ви чекаєте пам’яті. Іноді — кеш-промахів. Іноді — різних гілок виконання, коли половина хвилі пішла по іншому шляху.
3) Денойзинг і тимчасова акумуляція
RT у реальному часі часто використовує мало променів на піксель. Без денойзера виходить іскристий хаос.
Денойзери — це обчислювальні навантаження зі своєю пропускною здатністю й поведінкою кеша. Вони також додають проблеми тимчасової стабільності:
«привидіння», розмивання і особливий біль — «виглядає добре в русі, ламається коли зупиняєшся».
4) Накладні витрати драйвера й компіляція пайплайнів
RT-пайплайни можуть збільшити кількість варіантів шейдерів і складність компіляції. Якщо ви потрапляєте на компіляцію під час виконання — або гірше, відправили реліз без «теплого» кеша шейдерів —
ваша помилка «RT повільний» насправді інцидент «ви скомпілювали шейдер посеред бою».
5) Прихований податок: споживання пам’яті
BVH коштують пам’яті. Додаткові G-буфери коштують пам’яті. Вищу якість RT-ефектів означає більше проміжних буферів.
Коли тиск на VRAM зростає, ви бачите викидання, пейджинг і раптові сплески часу кадру.
Підхід AMD до RT: прагматична інженерія, а не враження
Вхід AMD у RT з RDNA2 виглядав як практичний компроміс: додати апаратну підтримку (Ray Accelerators на CU), одночасно зберігши
широку архітектуру збалансованою для растеру і консолей.
Ось у чому суть: AMD не побудувала GPU «пристрій для RT, який також може растеризувати».
Вони зробили GPU, що фундаментально орієнтований на растеризацію, бо більшість контенту досі таким є.
«Наддоганяння» свідомо обмежене реальністю: витрати, енергоспоживання, вихід придатних кристалів і широка сумісність.
Якщо ви керуєте продакшн-системами, ви впізнаєте цей підхід. Ви не перебудовуєте всю платформу заради однієї нової фічі.
Ви робите фічу працездатною в наявних експлуатаційних рамках. Потім ітеруєте.
У AMD також був інший стратегічний якір: консолі. Коли ваша архітектура працює в консолях, ви оптимізуєте для:
стабільних драйверів, передбачуваної поведінки пам’яті і продуктивності на ват в обмеженому тепловому корпусі.
Це схиляє до консервативних, масштабованих рішень замість «накидаємо транзисторів і молимося».
Ось неприємна правда: раннє впровадження RT частково було проблемою відносин із розробниками. Якщо рушії не пропишуть RT-шляхи масово,
апаратне RT — це блискучий чекбокс. Коли консолі зробили RT більш поширеним, час виходу AMD виглядав менш «пізнім» і більше «синхронізованим».
Спочатку вимірюйте: що збирати до оптимізації
Найшвидший спосіб витратити тижні даремно — сперечатися про продуктивність RT на підставі скріншотів середнього FPS.
Вам потрібні розподіли часу кадру, розподіл навантаження CPU/GPU, запас VRAM і поведінка компіляції шейдерів.
Надійний робочий процес:
- Почніть з відтворюваної сцени: той самий шлях камери, той самий сейвпоінт, той самий час доби/погода, такий самий стан NPC, якщо можливо.
- Фіксуйте часи кадрів, а не лише FPS.
- Виділяйте випадки, обмежені CPU від GPU.
- Тестуйте ефекти RT поодинці (віддзеркалення vs тіні vs глобальне освітлення) і записуйте дельти.
- Відстежуйте тиск на VRAM та системну оперативну пам’ять.
- Перевіряйте поведінку кеша шейдерів після оновлень драйверів.
Цитата (перефразована ідея): Вернер Фогельс популяризував ідею, що системи треба будувати, очікуючи на збої, і проєктувати для стійкості, а не досконалості.
— Вернер Фогельс (перефразована ідея)
Практичні завдання: команди, вивід, значення, рішення
Ці завдання написані так, ніби ви на виклику й потребуєте відповідей, а не вражень. Вони тяжіють до Linux, бо це скриптується й чесно,
але принципи переносяться. Кожне завдання містить: команду, приклад виводу, що це означає і яке рішення прийняти.
Завдання 1: Ідентифікуйте GPU і стек драйверів
cr0x@server:~$ lspci -nn | grep -E "VGA|3D"
0b:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Navi 31 [1002:744c]
Що це означає: Ви підтверджуєте реальний GPU (і PCI ID), а не те, що каже маркетинг.
Рішення: Якщо пристрій не відповідає цілі (RDNA2 vs RDNA3), зупиніться. Ваш «регрес RT» може бути «не та машина».
Завдання 2: Підтвердіть версії драйвера ядра та Mesa/AMDGPU
cr0x@server:~$ uname -r
6.5.0-21-generic
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 7900 XTX (navi31, LLVM 16.0.6, DRM 3.54, 6.5.0-21-generic) (0x744c)
Version: 23.2.1
Що це означає: Продуктивність і стабільність RT дуже чутливі до драйвера/компілятора. Це ідентифікує стек.
Рішення: Якщо у вас стара Mesa/драйвер і ви скаржитеся на RT, можливо, ви бенчмаркаєте археологію.
Завдання 3: Перевірте наявність розширень Vulkan для трасування
cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275
Devices:
========
GPU0:
apiVersion = 1.3.275
deviceName = AMD Radeon RX 7900 XTX
driverVersion = 2.0.279
deviceType = DISCRETE_GPU
Device Extensions: count = 182
VK_KHR_acceleration_structure
VK_KHR_ray_tracing_pipeline
VK_KHR_deferred_host_operations
Що це означає: Шлях Vulkan RT доступний. Якщо ці розширення відсутні, гра/рушій тихо відкотиться на запасний шлях.
Рішення: Відсутні розширення означають, що ви дебагуєте пакування драйвера або середовище, а не «продуктивність RT».
Завдання 4: Перевірте тактові частоти GPU і стан живлення (щоб уловити «заблоковано в низькій потужності»)
cr0x@server:~$ cat /sys/class/drm/card0/device/pp_dpm_sclk
0: 500Mhz
1: 1500Mhz
2: 2400Mhz *
Що це означає: Зірочка показує поточний рівень продуктивності.
Рішення: Якщо ви застрягли на низьких частотах під RT-навантаженням, проблема в управлінні живленням/термали, а не в RT-ядрах.
Завдання 5: Знайдіть сигнали термального тротлінгу
cr0x@server:~$ cat /sys/class/drm/card0/device/hwmon/hwmon*/temp1_input 2>/dev/null | head -n 1
78000
Що це означає: Температура в міліградусах Цельсія (78°C тут). RT-навантаження можуть змінити розподіл енергії й викликати гарячі точки.
Рішення: Якщо температура висока і частоти падають, виправте охолодження або ліміти живлення перед зміною налаштувань.
Завдання 6: Перевірте використання VRAM і тиск на викидання (швидкий сигнал)
cr0x@server:~$ cat /sys/kernel/debug/dri/0/amdgpu_vram
VRAM size: 24576M
VRAM used: 21234M
GTT size: 32768M
GTT used: 6120M
Що це означає: Ви близькі до заповнення VRAM; перетоки в GTT (системна пам’ять) можуть викликати стрибки часу кадру.
Рішення: Зменште роздільність текстур/якість RT або звільніть простір, закривши додатки. Якщо VRAM близький до ліміту, припиніть ганятися за шейдерними правками.
Завдання 7: Виявити вузьке місце CPU vs GPU за допомогою MangoHud
cr0x@server:~$ mangohud --dlsym ./game_binary
... MangoHud: GPU 98% CPU 35% frametime 21.3ms fps 47 ...
Що це означає: GPU насичений. Якби CPU був завантажений, а GPU ні — ви були б обмежені CPU.
Рішення: GPU-завантаження: налаштовуйте RT-параметри, роздільність, денойзер. CPU-завантаження: зменшуйте кількість викликів відрисовки, покращуйте багатопотоковість або знижуйте вартість симуляції.
Завдання 8: Зняти розподіл часу кадру (не середній FPS)
cr0x@server:~$ cat frametimes.csv | awk -F, 'NR>1{sum+=$2; if($2>p99) p99=$2} END{print "max_ms="p99, "avg_ms="sum/(NR-1)}'
max_ms=78.1 avg_ms=19.6
Що це означає: Одиничний сплеск 78 мс видимий користувачеві як підлагування, навіть якщо середнє в порядку.
Рішення: Якщо max/p95/p99 кадрів погані, пріоритезуйте джерела стрибків: компіляція шейдерів, пейджинг, побудова BVH, CPU-сплески.
Завдання 9: Перевірте, що каталоги кеша шейдерів існують і доступні для запису
cr0x@server:~$ ls -ld ~/.cache/mesa_shader_cache
drwx------ 12 cr0x cr0x 4096 Jan 13 09:12 /home/cr0x/.cache/mesa_shader_cache
Що це означає: Якщо кеш шейдерів не може зберігатися, ви будете перевиконувати компіляцію постійно і отримувати «випадкові» підлагування.
Рішення: Якщо дозволи неправильні або кеш на повільному файловому сховищі, виправте це в першу чергу.
Завдання 10: Перевірте логи на сплески компіляції шейдерів у режимі виконання (приклад патерну)
cr0x@server:~$ journalctl --user -n 200 | grep -i -E "shader|pipeline|compile" | tail -n 5
Jan 13 09:22:41 gamehost game_binary[8123]: vkCreateRayTracingPipelinesKHR: compiling pipeline cache miss
Jan 13 09:22:41 gamehost game_binary[8123]: stutter-warning: pipeline compilation took 145ms
Що це означає: Компіляція пайплайна сталася на критичному шляху.
Рішення: Попередньо компілюйте пайплайни, постачайте кеш пайплайнів або реструктуруйте, щоб компіляція відбувалася асинхронно до моменту необхідності сценою.
Завдання 11: Перевірте швидкість лінку PCIe (класична причина «чому стримінг жахливий»)
cr0x@server:~$ sudo lspci -s 0b:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 16GT/s, Width x16
Що це означає: Ви на очікуваній швидкості/ширині PCIe. Якщо вона опускається (x4 або нижче), стримінг і завантаження можуть застрягати.
Рішення: Якщо лінк деградував, перепідключіть GPU, виправте налаштування BIOS або перемістіть у слот перед тим, як звинувачувати RT.
Завдання 12: Виявити тиск пам’яті і свопінг (підсилювач підлагувань)
cr0x@server:~$ free -h
total used free shared buff/cache available
Mem: 32Gi 28Gi 1.2Gi 1.0Gi 2.8Gi 2.1Gi
Swap: 8.0Gi 2.1Gi 5.9Gi
Що це означає: У вас відбувається свопінг. RT + текстури високої роздільності можуть виштовхнути системну пам’ять, особливо з тліючими додатками.
Рішення: Закрийте пам’ятно-важкі процеси, додайте ОЗП, зменште налаштування текстур або виправте витоки. Свопінг робить усе схожим на проблему RT.
Завдання 13: Проінспектуйте затримки I/O для кеша шейдерів і стримінгу ресурсів
cr0x@server:~$ iostat -xz 1 3
avg-cpu: %user %nice %system %iowait %steal %idle
18.21 0.00 4.12 6.70 0.00 70.97
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s w_await wareq-sz aqu-sz %util
nvme0n1 58.0 4120.0 0.0 0.0 1.20 71.0 42.0 2048.0 9.80 48.8 0.55 62.0
Що це означає: write await високий (9.8 ms). Якщо ваш кеш шейдерів лежить на повільному або зайнятому диску, ви будете бачити підлагування.
Рішення: Перенесіть кеш на швидше сховище, зменшіть фонові I/O або налаштуйте параметри файлової системи.
Завдання 14: Підтвердіть поведінку файлової системи для кешу (noatime зменшує непотрібні записи)
cr0x@server:~$ mount | grep " /home "
/dev/nvme0n1p2 on /home type ext4 (rw,noatime,errors=remount-ro)
Що це означає: noatime уникатиме оновлення часу доступу при читанні, зменшуючи метадані-записи.
Рішення: Якщо каталог кешу живе на монтуванні з великим оновленням метаданих, розгляньте тюнінг. Це не гламурно, але вимірювано.
Завдання 15: Перевірте, що перемикачі RT справді змінюють роботу GPU
cr0x@server:~$ grep -E "rt_enabled|rt_reflections|rt_shadows" ~/.config/game/settings.ini
rt_enabled=1
rt_reflections=0
rt_shadows=1
Що це означає: Вас здивує, як часто перемикачі UI не застосовуються без перезапуску або їх переоприділяють пресети.
Рішення: Якщо перемикачі не зберігаються, припиніть A/B тестування, поки не виправите конфігураційний пайплайн.
Завдання 16: Швидка перевірка: базова растеризація проти RT-дельти
cr0x@server:~$ ./bench_scene.sh --preset raster --runs 3
run1 avg_fps=124 p99_ms=11.3
run2 avg_fps=122 p99_ms=11.9
run3 avg_fps=123 p99_ms=11.6
cr0x@server:~$ ./bench_scene.sh --preset rt_medium --runs 3
run1 avg_fps=68 p99_ms=24.8
run2 avg_fps=66 p99_ms=26.1
run3 avg_fps=67 p99_ms=25.4
Що це означає: RT додає як відсіч пропускної здатності (FPS), так і хвостову латентність (p99).
Рішення: Якщо p99 погіршується більше за середнє, сфокусуйтеся на сплесках (побудова BVH, кеш-промахи, компіляція) перед гонитвою за сирою швидкістю.
Жарт №2: Увімкнути ультра RT, щоб «перевірити стабільність», — це як навантажувати базу даних, підпаливши її; технічно інформативно, емоційно дорого.
Швидкий план діагностики
Це робочий процес «у вас 30 хвилин до зустрічі». Порядок складено, щоб ізолювати найбільші категорії спочатку.
Перше: доведіть, що ви знаєте, що запускаєте
- Підтвердіть GPU + стек драйверів (Завдання 1–2). Якщо ви не можете його назвати, ви не зможете виправити.
- Підтвердіть шлях API: присутні DXR/Vulkan RT розширення (Завдання 3). Немає розширень — немає RT-шляху.
- Підтвердіть, що налаштування застосовано (Завдання 15). UI бреше; файли конфігурації рідко роблять.
Друге: класифікуйте вузьке місце (CPU, GPU, пам’ять, I/O)
- CPU vs GPU bound (Завдання 7). Це визначає, чи налаштовувати параметри або потоки.
- Запас VRAM (Завдання 6). Якщо ви близькі до повного, «RT повільний» може означати «повільний пейджинг».
- Системний своп (Завдання 12). Свопінг спотворює хвости часу кадру.
- Затримка диска (Завдання 13). Підлагування шейдерів/ресурсів може бути I/O, а не GPU.
Третє: полюйте за сплесками, а не за середніми
- Розподіл часу кадру (Завдання 8). p95/p99 — це правда.
- Докази компіляції шейдерів/пайплайнів (Завдання 10, Завдання 9). Виправте кешування й стратегію попередньої компіляції.
- Терми/стан енергоспоживання (Завдання 4–5). Якщо частоти падають — ви програєте ще до старту.
Четверте: лише потім налаштовуйте RT
- Вимикайте по одній RT-функції (тіні, віддзеркалення, GI).
- Зменшуйте кількість відскоків і дистанцію променів.
- Віддавайте перевагу стабільним пресетам денойзера над агресивними, що мерехтять.
- Розумно використовуйте масштабування; не ставте нативне 4K RT як етичну перемогу.
Три корпоративні міні-історії (чому їх варто запам’ятати)
Міні-історія 1: Інцидент через хибне припущення
Середня студія випустила патч RT для крос-платформної гри. Вони тестували на кількох топових GPU, побачили добрі середні показники
і оголосили перемогу. Пішли тікети в підтримку як дощу: «RT викликає підлагування щоразу, коли я заходжу в нову зону».
Хибне припущення було просте: вони думали, що «компіляція шейдерів відбувається під час завантаження».
В їх інтеграції рушія варіанти RT-пайплайнів для певних матеріалів запитувалися лише вперше, коли з’являлася конкретна
комбінація світла і поверхонь. Це сталося в середині гри.
На деяких системах каталог кеша шейдерів був на повільному, майже заповненому SATA SSD. На інших — на синхронізованій по мережі домашній папці.
Сама компіляція була дорогою; запис у кеш погіршував ситуацію. Гравці не бачили «повільну гру». Вони бачили непередбачувану.
Виправлення не було магічним налаштуванням RT. Це була дисципліна операцій: постачати «теплий» кеш пайплайнів, компілювати наперед під відомі переходи,
і логувати промахи кеша з достатнім контекстом для відтворення. Вони також додали опцію «прогрів шейдерів» після оновлень драйверів.
Їхній найбільший виграш — культурний: команда перестала використовувати середній FPS як критерій випуску і почала застосовувати пороги p99 часу кадру по сцені.
Скарги на підлагування значно зменшилися, хоча середній FPS майже не змінився.
Міні-історія 2: Оптимізація, що відвернулася проти авторів
Внутрішня графічна команда намагалася «оптимізувати RT-віддзеркалення», збільшивши довжину променя й зменшивши кількість вибірок,
покладаючись на денойзер, щоб заповнити пропуски. На папері: менше променів — швидше кадр.
На практиці довші промені влучали у більше геометрії, викликали більше кроків обходу і давали більш шумні входи для денойзера.
Денойзер тоді потребував більше тимчасової акумуляції, щоб стабілізуватися. Це спричинило привидіння при швидкому русі камери.
Команда відповіла більшим числом проходів денойзера. Використання GPU зросло, а не впало. Гірше: пропускна здатність пам’яті підскочила, бо денойзер
переміщував багато даних через кілька буферів. На деяких AMD-картах навантаження стало більш чутливим до поведінки кеша і демонструвало великі p99-сплески.
Вони відкотили зміни і обрали нудний, але коректний підхід: коротші промені, трохи більше вибірок і пресет денойзера, орієнтований на стабільність.
Продуктивність не «перемогла» в слайді, але гра виглядала краще і дала менше артефактів у крайових випадках.
Урок: «оптимізації» RT, що збільшують варіативність, — це операційний борг. Якщо ви не можете передбачити поведінку, ви не зможете безпечно випустити.
Міні-історія 3: Нудна, але правильна практика, що врятувала реліз
Платформна команда підтримувала лабораторію тестових GPU-машин. Нечуттєво. Переважно кабелі, наліпки й електронна таблиця.
Але вони дотримувалися політики: кожен прогін продуктивності логував версію драйвера, версію ядра, хеш збірки гри, файл налаштувань і фіксований шлях камери.
Під час великого оновлення хтось повідомив: «RT на AMD тепер на 20% повільніший». Інтернет надав би цьому заголовок і біг.
Лабораторія цього не зробила. Вони знову прогнали той самий тест з тим самим шляхом камери, потім порівняли стек драйверів.
Регрес пов’язали з оновленням драйвера, що змінило поведінку компілятора шейдерів. Збірка гри не змінилася.
Команда відтворила проблему на кількох машинах, захопила трасування і передала вендору чіткий репро-пакет.
Тимчасом вони випустили пом’якшення: невелика зміна контенту, що зменшила крайову розбіжність матеріалів у RT-процесі,
плюс налаштування за замовчуванням, що повернуло хвостову латентність часу кадру. Користувачі швидко помітили покращення.
Нудна практика — структурована метадані тестів і відтворюваність — перетворила потенційний шквал звинувачень у вирішуваний інженерний тикет.
Це не потрапило в заголовки. Але врятувало реліз.
Поширені помилки: симптом → корінна причина → виправлення
Цей розділ навмисно конкретний. Це режимні збої, які гублять реальні команди.
1) Симптом: RT «вбиває FPS», але завантаження GPU низьке
Корінна причина: Рамка обмежена CPU, часто через збільшення кількості викликів відрисовки, побудову BVH на CPU або погану багатопотоковість.
Виправлення: Зменшіть роботу на CPU (відсікання, батчинг), перенесіть роботу BVH на GPU де можливо, профілюйте потоки і перевірте, що ви не компілюєте пайплайни в головному потоці.
2) Симптом: Мікропідлагування при вході в нові зони
Корінна причина: Динамічна компіляція пайплайнів/шейдерів і промахи кеша; затримки стримінгу ресурсів.
Виправлення: Попередньо компілюйте пайплайни, прогрівайте кеш шейдерів, переносіть кеш на швидке локальне сховище і стадіюйте ресурси раніше.
3) Симптом: Гладкий середній FPS, потворні p99-сплески
Корінна причина: Викидання VRAM, сплески побудови BVH, фонові I/O або періодичні задачі ОС.
Виправлення: Забезпечте запас VRAM, зменшіть кількість RT-буферів, обмежте вартість оновлення BVH і ізолюйте тестове середовище від фонових навантажень.
4) Симптом: RT-віддзеркалення виглядають «іскристими» або нестабільними
Корінна причина: Надто мало променів на піксель, надто агресивні налаштування денойзера або невідповідні вектори руху.
Виправлення: Трохи підвищте кількість вибірок, підкоригуйте дистанцію променів, перевірте вектори руху і оберіть налаштування денойзера, що віддають перевагу тимчасовій стабільності.
5) Симптом: Після оновлення драйвера продуктивність RT драматично змінилася
Корінна причина: Зміни в компіляторі шейдерів і інвалідовані кеші; інше розподілення регістрів і зайнятість хвиль.
Виправлення: Перебудуйте кеші шейдерів, перезапустіть базові тести і розглядайте драйвери як частину матриці релізів.
6) Симптом: Включення RT спричиняє аварії або втрату пристрою під навантаженням
Корінна причина: Невпорядковане споживання VRAM, занадто великі структури прискорення або баги драйвера/прошивки, викликані рідкісними шейдерами.
Виправлення: Додайте запобіжники: обмежте геометрію в RT-проході, зменшіть роздільність RT, перевірте алокації пам’яті і зберіть мінімальні репро.
7) Симптом: RT здається гіршим на одному вендорі «без причини»
Корінна причина: Вендорно-специфічні шаблони шейдерів, чутливість до розбіжності або покладання на функцію масштабування з іншим поведінкою.
Виправлення: Використовуйте вендонейтральне профілювання, тестуйте з еквівалентними пресетами масштабування і уникайте припущень про те, як здійснюється прискорення обходу.
Контрольні списки / покроковий план
Контрольний список A: Якщо ви купуєте/обираєте апаратне забезпечення для RT-навантажень
- Визначте ціль: 60 fps стабільно, 120 fps конкурентно чи «кіношні 40 fps». Не плутайте ці вимоги.
- Обирайте сцени, які відповідають вашому реальному навантаженню: листя, натовпи, відбивні інтер’єри, нічна неонова сцена — усе по-різному навантажує RT.
- Міряйте часи кадру p95/p99, а не лише середні.
- Бюджетуйте запас VRAM (принаймні кілька ГБ) для RT-буферів і майбутніх патчів.
- Вирішіть політику масштабування зображення наперед (FSR/DLSS/native). RT без масштабування — це розкішний податок.
- Підтвердіть зрілість драйверів для вашої ОС і версії рушія.
Контрольний список B: Якщо ви студія, що випускає RT на AMD (і на всіх інших)
- Побудуйте відтворювану бенчмаркову траєкторію (фіксований шлях камери, фіксований seed, фіксований файл налаштувань).
- Випускайте шлях прогріву шейдерів/пайплайнів і логуйте промахи кеша.
- Експонуйте RT-фічі як незалежні перемикачі (тіні/віддзеркалення/GI) і тримайте пресети розумними.
- Обмежте вартість побудови/оновлення структур прискорення на кадр; відкладайте не критичні оновлення.
- Віддавайте перевагу стабільному денойзеру перед агресивними низьковибірковими хаками, що мерехтять.
- Тестуйте тиск VRAM явно: режим «майже повний» — окремий тест.
- Підтримуйте матрицю драйверів і перезапускайте базові тести після змін драйверів.
- Зробіть «p99 часу кадру» критерієм випуску для RT-пресетів.
Контрольний список C: Якщо ви оператор, що усуває проблему «RT повільний»
- Підтвердіть апаратне забезпечення і стек драйверів (Завдання 1–2).
- Підтвердіть доступність RT API (Завдання 3).
- Класифікуйте вузьке місце (Завдання 7, 6, 12, 13).
- Виміряйте хвости часу кадру (Завдання 8, 16).
- Шукайте компіляцію (Завдання 10) і проблеми з кешем (Завдання 9).
- Перевірте термали і частоти (Завдання 4–5).
- Лише потім налаштовуйте RT; не тюньте навмання.
Питання й відповіді (FAQ)
1) Чи «поганий» AMD у трасуванні променів?
Ні. Продуктивність RT на AMD сильно залежить від гри, інтеграції рушія і налаштувань. Чим більше навантаження обмежене латентністю пам’яті і розбіжністю,
тим помітніші архітектурні відмінності. Розглядайте це як проблему підбору навантаження, а не моралі.
2) Чому RT здається гіршим, ніж растер, навіть якщо FPS виглядає нормальним?
Бо RT часто погіршує хвостову латентність. p99 часи кадру важливіші для відчуття плавності, ніж середній FPS.
Сплески виникають через компіляцію, побудову BVH і тиск пам’яті.
3) Чому віддзеркалення іноді коштують набагато дорожче, ніж тіні?
Віддзеркалення часто потребують довших променів, складнішого шейдингу і більш неузгоджених попадань. Тіні можуть бути дешевшими, якщо вони
обмежені по діапазону і одноразові.
4) Чи завжди варто вмикати масштабування при RT?
У більшості реального часу так. Масштабування — частина бюджету продуктивності RT. Запустіть внутрішню роздільність нижче і витратьте
зекономлений час на RT-ефекти й стабільний денойзер.
5) Який найбільший «підводний камінь» у тестуванні продуктивності RT?
Кеш шейдерів і компіляція пайплайнів. Якщо ваш перший прогін включає компіляцію, а другий ні, ви не тестували RT; ви тестували пайплайн збірки.
6) Чому оновлення драйвера може так сильно змінити продуктивність RT?
RT-пайплайни сильно навантажують компілятори: розподіл регістрів, планування й зайнятість хвиль можуть змінитися.
Також оновлення драйвера можуть інвалідовувати кеші, спричиняючи підлагування першого запуску.
7) Що студіям слід пріоритезувати: пік FPS чи послідовність часу кадру?
Послідовність. Стабільні 60 fps із хорошим p99 відчуваються краще, ніж середні 90 fps з регулярними стрибками по 40 мс.
Стабільність також знижує навантаження на підтримку й негативні відгуки.
8) Чи «більше RT-апаратури» автоматично означає краще RT?
Не автоматично. Обхід і шейдинг можуть бути обмежені латентністю пам’яті, поведінкою кеша, розбіжністю й вартістю денойзера.
Апарат допомагає, але результат вирішують навантаження та програмний стек.
9) Якщо я обмежений GPU з включеним RT, яке налаштування дає найкращий приріст?
Знизьте роздільність RT (часто через режим масштабування), потім зменшіть дистанцію променя і кількість відскоків.
Вимкнення найкоштовнішого RT-ефекту (зазвичай віддзеркалення/GI) може дуже відновити час кадру.
Практичні наступні кроки
Якщо ви візьмете одне з історії AMD про RT — візьміть це: послідовність має значення. Випуск RT пізніше з міцним стеком — не провал;
це дисциплінований компроміс між амбіцією фіч і операційною коректністю.
Зробіть наступне, по порядку:
- Припиніть сперечатися про середній FPS. Збирайте p95/p99 часу кадру і приймайте рішення з урахуванням хвостів.
- Побудуйте відтворювану бенчмаркову траєкторію для RT і логайте весь стек: драйвер, ядро, хеш збірки, налаштування.
- Захистіть запас VRAM. Якщо ви в межах кількох ГБ до ліміту, ваш наступний патч перетвориться на генератор підлагувань.
- Виправте поведінку компіляції шейдерів/пайплайнів. Прогрівайте кеші, попередньо компілюйте і тримайте головний потік чистим.
- Налаштовуйте RT як оператор: ізолюйте одну змінну за раз, вимірюйте дельти і віддавайте перевагу стабільності над крихкими перемогами.
«Наддоганяти» — це те, як ви називаєте, коли лише спостерігаєте за гонкою. Коли ви керуєте системою — це управління ризиками.