Рейтрейсинг: що він дає крім красивих скриншотів

Що насправді додає рейтрейсинг (крім ефекту «вау»)

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

1) Освітлення, яке поводиться як освітлення

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

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

2) Менше хаки при створенні контенту (і менше зустрічей «чому це металічне неправильно?»)

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

3) Новий тип детермінізму: фізично-обґрунтований, статистично шумний

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

Але ось виграш: помилки статистичні й вимірювані. Ви можете кількісно задати samples-per-pixel, глибину променів і дисперсію, а потім вибрати бюджет.
Растер-хакі часто провалюються катастрофічно — SSR «стрибає», тіні «пливуть», probes «раптом змінюються». Рейтрейсинг зазвичай деградує поступово: більше шуму, більше розмивання, менше стабільності.
Це легше осмислити в продакшні, бо ви можете деградувати плавно.

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

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

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

Факти та контекст, які змінюють підхід

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

1. Рейтрейсинг старший за більшість ігрових рушіїв. Основна ідея походить з кінця 1960-х — початку 1970-х у дослідницьких рендерах.
2. «Whitted-style» рейтрейсинг (1979) не про GI. Він популяризував рекурсивні віддзеркалення/заломлення й жорсткі тіні — досі поширене в режимах «RT увімкнено».
3. Path tracing (середина 1980-х) — робоча конячка GI. Він жертвує швидкістю заради незміщеності; сучасні «path traced» режими часто сильно спрямовані й денойзяться.
4. BVH-акселерація зробила це практичним. Без просторових структур прискорення, рейтрейсинг — це по суті «перебирання кожного трикутника», що виглядає як продуктивність, але не є нею.
5. Спочатку це нормалізували офлайн-регендери для кіно. Фільми могли витрачати хвилини на кадр; ігри мають мілісекунди, тому тут домінують гібридні підходи й денойзери.
6. Справжній реальний рейтрейсинг став можливим із апаратною підтримкою. Фікс-функція traversal/intersection (RT-ядра або подібні блоки) — це не розкіш; це різниця між «демо» і «релізом».
7. Денойзинг неопційний у реальному часі. Більшість релізних проєктів використовують одиничні цифри семплів на піксель для RT-ефектів — денойзер виконує основну роботу.
8. Гібридний рендеринг — норма, а не компроміс. Растеризація лишається основним прохідним видимості; промені використовують для конкретних запитів транспорту світла там, де растер-хакі найгірші.

Практична ментальна модель: промені, бюджети та компроміси

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

Три бюджети, які важливі

• Бюджет променів: промені на піксель для кожного ефекту (віддзеркалення, тіні, GI), плюс глибина променя (відскоки). Це ваша частота запитів.
• Бюджет traversal/intersection: наскільки дорого обходити BVH і тестувати геометрію. Це залежить від якості BVH, складності сцени та когерентності.
• Бюджет шейдингу/денойзингу: що ви робите після попадання променя і як перетворюєте шумні семпли в стабільне зображення.

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

Когерентність: секретний податок

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

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

Жарт №1: Рейтрейсинг — це як найняти приватного детектива для кожного пікселя — точний, дорогий, і вони постійно надсилають вам рахунки підписані «різне».

Шум — це не «погана якість», а математика, що каже правду

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

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

Поза скриншотами: операційна й інженерна цінність

Рейтрейсинг як інструмент коректності

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

Рейтрейсинг як спрощувач (якщо не переборщити)

Найбільший приріст продуктивності — не «красивіше». Це видалення спеціальних випадків.
Ланцюги відкатів SSR, еврика blend’ів probe, і ручні хаки оклюзії накопичуються як дрейф конфігів у парку серверів.
Кожен із них на момент введення виправданий. Разом вони перетворюються на неперевірюване болото.

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

Рейтрейсинг як пастка продуктивності (якщо ігнорувати хвостову латентність)

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

У термінах SRE ви дбаєте про p95/p99 часу кадру, не про середнє. Ставтеся до підлагувань як до інцидентів.
Ви хочете знати: чи сплеснули промені, чи оновлення BVH, чи ми зависли на CPU при надсиланні роботи?

Одна надійна ідея з операцій застосовується і тут: «Сподівання — не стратегія» — вислів, який притаманний інженерам з культури надійності (парафраз).
Замініть сподівання лічильниками і трасуванням.

Де це ламається: передбачувані режими відмов

1) Витрати на побудову/оновлення BVH, які б’ють по часу кадру

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

Якщо ви перебудовуєте занадто багато за кадр, ви побачите періодичні сплески. Якщо ви використовуєте низькоякісні збірки, traversal стає повільнішим, і шум зростає, бо промені промахуються повз тонку геометрію.
В будь-якому разі — ви платите.

2) Дивергенція шейдерів і складність матеріалів

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

Часто можна поліпшити продуктивність RT, спростивши матеріали тільки для попадань променів (LOD матеріалу для рейтрейсингу).
Це менше образливо, ніж звучить. Віддзеркалення вже фільтруються й денойзяться; вам не потрібні всі мікродеталі.

3) Нестабільність денойзера (примари, розмивання, дисоклюжур)

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

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

4) Затримки при відправленні на CPU і синхронізації

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

Ось чому ви маєте профілювати обидві сторони. Фічі GPU можуть спричинити інцидент на CPU. Всесвіт такий грубий.

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

Швидка методика діагностики

У вас немає часу на триденний профайлінг. Вам потрібна 20-хвилинна триажна перевірка, яка скаже, куди копати.
Ось методика, що часто працює дивно добре.

Перший крок: це GPU-bound чи CPU-bound?

• Перевірте завантаження GPU й навантаження по рушіях (graphics vs compute) під час відтворення проблеми.
• Перевірте час кадру на CPU: якщо CPU завантажений, а GPU простоює, рейтрейсинг не є первинним вузьким місцем — навіть якщо «RT увімкнено» корелює з проблемою.

Другий крок: якщо GPU-bound, у яку корзину це потрапляє?

1. Traversal/intersection важкий: вартість BVH, забагато променів, погана когерентність.
2. Шейдинг важкий: дорогі матеріали в точках попадання променя, багато звернень до текстур, дивергенція.
3. Денойзинг/постпроцес важкий: тимчасовий резольв, апскейлінг, буфери історії, тиск на пропускну здатність пам’яті.

Третій крок: знайдіть причину хвостової латентності (підлагування)

• Сплески rebuild BVH (динамічні об’єкти перетинають пороги, підвантаження ассетів).
• Завіси компіляції шейдерів, викликані новими пермутаціями RT.
• Тиск на пам’ять (переповнення VRAM, що викликає пейджинг або агресивний стрімінг).
• Бульбашки синхронізації (CPU чекає GPU-фенсів або навпаки).

Четвертий крок: відокремте симптоми коректності від продуктивності

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

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

Це те, що я очікую від команди: швидкі виконувані перевірки на робочій станції або build-сервері.
Мета не в боготворінні інструментів. Мета — ухвалити рішення на підставі кожного виводу.

Завдання 1: Визначте вашу GPU і драйвер (базова реальність)

cr0x@server:~$ nvidia-smi
Tue Jan 13 12:14:02 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 550.54.14              Driver Version: 550.54.14      CUDA Version: 12.4   |
|-----------------------------------------+------------------------+----------------------|
| GPU  Name                 Persistence-M | Bus-Id          Disp.A | Volatile Uncorr. ECC |
| Fan  Temp   Perf          Pwr:Usage/Cap |           Memory-Usage | GPU-Util  Compute M. |
|                                         |                        |               MIG M. |
|=========================================+========================+======================|
|   0  NVIDIA RTX A5000               Off | 00000000:65:00.0  On   |                  Off |
| 30%   61C    P2              165W / 230W|   14520MiB / 24564MiB  |     94%      Default |
+-----------------------------------------+------------------------+----------------------+

Що означає вивід: У вас GPU класу RTX з високим завантаженням і значним використанням VRAM.

Рішення: Якщо GPU-Util високий, а FPS низький — почніть з профілювання GPU; якщо використання VRAM близьке до ліміту — підозрюйте тиск пам’яті й ризик пейджингу/підлагувань.

Завдання 2: Перевірте тиск VRAM у часі (предиктор підлагувань)

cr0x@server:~$ nvidia-smi --query-gpu=timestamp,memory.used,memory.total,utilization.gpu --format=csv -l 1
timestamp, memory.used [MiB], memory.total [MiB], utilization.gpu [%]
2026/01/13 12:15:01, 14890, 24564, 96
2026/01/13 12:15:02, 21980, 24564, 88
2026/01/13 12:15:03, 24110, 24564, 91
2026/01/13 12:15:04, 24490, 24564, 79

Що означає вивід: VRAM піднімається до стелі; використання падає, коли пам’ять насичується.

Рішення: Зменште розміри RT-буферів, знизьте роздільність історії, відрегулюйте стрімінг текстур або зменшіть роздільність RT-ефектів перед тим, як торкатися кількостей променів.

Завдання 3: Швидко підтвердьте вузьке місце на CPU (верхній рівень)

cr0x@server:~$ pidstat -t -p $(pidof game) 1
Linux 6.5.0 (server)  01/13/2026

12:16:10      UID      TGID       TID    %usr %system  %guest   %CPU   CPU  Command
12:16:11     1000     22541         -   165.00   12.00    0.00 177.00    10  game
12:16:11     1000         -     22578    55.00    3.00    0.00  58.00    10  RenderThread
12:16:11     1000         -     22579    46.00    2.00    0.00  48.00    12  RHIThread

Що означає вивід: CPU-потоки сильно завантажені; потоки відправки рендеру зайняті.

Рішення: Якщо одночасно GPU-Util низький — оптимізуйте CPU-частину налаштування RT (оновлення дескрипторів, запис команд) або зменшіть кількість проходів.

Завдання 4: Слідкуйте за сигналами планування кадру GPU/CPU за допомогою MangoHud (Linux)

cr0x@server:~$ mangohud --dlsym ./game -fullscreen
MangoHud v0.7.2
FPS: 72.1 (avg 68.4) | Frametime: 13.9ms (99th: 28.4ms) | GPU: 94% | VRAM: 23.8/24.0GB | CPU: 62%

Що означає вивід: Середнє значення — пристойне, але 99-й процентиль часу кадру поганий (підлагування).

Рішення: Полюйте за сплесками: rebuild BVH, стрімінг, компіляція шейдерів. Не женіться за середнім FPS насамперед.

Завдання 5: Ловіть завіси компіляції шейдерів (поширений «RT увімкнено» підлаг)

cr0x@server:~$ journalctl --user -f | grep -i shader
Jan 13 12:18:07 server game[22541]: ShaderCache: compiling RT_REFLECTIONS_MATERIAL_143 (miss)
Jan 13 12:18:08 server game[22541]: ShaderCache: compiling RT_GI_INTEGRATOR_12 (miss)

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

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

Завдання 6: Перевірте, що апаратний рейтрейсинг дійсно увімкнений

cr0x@server:~$ vulkaninfo --summary | sed -n '1,80p'
Vulkan Instance Version: 1.3.275

Devices:
========
GPU0:
    apiVersion         = 1.3.275
    deviceName         = NVIDIA RTX A5000
    driverVersion      = 550.54.14
    deviceType         = DISCRETE_GPU

Device Extensions:
==================
VK_KHR_acceleration_structure     : extension revision 13
VK_KHR_ray_tracing_pipeline       : extension revision 1
VK_KHR_deferred_host_operations   : extension revision 4

Що означає вивід: GPU і драйвер надають розширення для рейтрейсингу; платформа підтримує його.

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

Завдання 7: Виявлення тротлінгу PCIe або пониження лінку (прихований обрив продуктивності)

cr0x@server:~$ lspci -s 65:00.0 -vv | grep -E "LnkCap|LnkSta"
LnkCap: Port #0, Speed 16GT/s, Width x16
LnkSta: Speed 8GT/s (downgraded), Width x8 (downgraded)

Що означає вивід: GPU працює на зниженому PCIe-лінку.

Рішення: Виправте налаштування BIOS, кабелі/ризери або вибір слоту. Рейтрейсинг вимогливий до пропускної здатності; не дебагуйте шейдери, коли ваш шина кульгає.

Завдання 8: Відмітки про евікцію/пейджинг VRAM (логи ядра + драйвера)

cr0x@server:~$ dmesg --ctime | grep -iE "nvrm|xid|evict|oom" | tail -n 5
[Tue Jan 13 12:20:41 2026] NVRM: Xid (PCI:0000:65:00): 31, pid=22541, name=game, Ch 0000002b, MMU Fault
[Tue Jan 13 12:20:41 2026] NVRM: GPU memory page fault, likely due to invalid address or eviction

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

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

Завдання 9: Перевірте базові частоти ядра й тротлінг (термал/потужність)

cr0x@server:~$ nvidia-smi -q -d CLOCK,POWER,TEMPERATURE | sed -n '1,120p'
Temperature
    GPU Current Temp                  : 83 C
Power Readings
    Power Draw                        : 229.50 W
    Power Limit                       : 230.00 W
Clocks
    Graphics                          : 1290 MHz
    Memory                            : 6001 MHz

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

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

Завдання 10: Перевірте, чи система свапить (підсилювач CPU-лагів)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            64Gi        61Gi       1.2Gi       1.1Gi       1.8Gi       1.6Gi
Swap:           16Gi        7.9Gi       8.1Gi

Що означає вивід: Машина свапить під навантаженням.

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

Завдання 11: Визначте масштабування частоти CPU або тротлінг (реальність для ноутбуків)

cr0x@server:~$ lscpu | grep -E "Model name|CPU\(s\)|MHz"
Model name:                           Intel(R) Core(TM) i9-12900K
CPU(s):                               24
CPU MHz:                              998.762

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

Рішення: Виправте план живлення / охолодження. Затримки відправки на CPU можуть маскуватися під «рейтрейсинг повільний».

Завдання 12: Базовий облік процесів GPU (хто краде GPU?)

cr0x@server:~$ nvidia-smi pmon -c 1
# gpu        pid  type    sm   mem   enc   dec   command
# Idx          #   C/G     %     %     %     %   name
    0      22541     G    92    61     0     0   game
    0      1042      G     8     4     0     0   Xorg

Що означає вивід: Гра — основний споживач GPU; мінімальні перешкоди.

Рішення: Якщо бачите несподівані процеси (рекордери, браузери, ML-завдання) — вбийте їх перед тим, як вірити будь-яким цифрам по продуктивності.

Завдання 13: Ловіть I/O-затримки під час стрімінгу ассетів (корінь підлагувань)

cr0x@server:~$ iostat -xz 1
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          34.21    0.00    6.18   18.77    0.00   40.84

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await  aqu-sz  %util
nvme0n1         812.0  92480.0    12.0   1.46    9.12   113.90   122.0   15488.0    5.44    8.12   92.4

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

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

Завдання 14: Перевірте налаштування hugepages/THP для стабільності CPU (нудно, але реально)

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

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

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

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

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

Студія випустила оновлення, яке за замовчуванням увімкнуло рейтрейсингові віддзеркалення на «висококласних» GPU. Вони визначили «висококласні» за простим списком Device ID.
QA пройшов. Порівняння скриншотів були прекрасні. Ноти патча — впевнені.

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

Реальна причина була простішою й підступнішою: неправильно оцінили запас VRAM. Команда тестувала на машинах з 24GB картами і вважала, що 12GB карти теж витримають,
бо статичне використання VRAM вкладалося. Але в новому оновленні віддзеркалення підвантажували додаткові високороздільні варіанти матеріалів і розширені буфери історії.
Під час руху і різких камерних змін двигун тимчасово перевищував VRAM і почав евіктити ресурси.

Підлагування були «штормами евікції». На одних драйверах це проявлялося як сплески часу кадру; на інших — як періодичні підвіски пристрою з подальшим відновленням.
Їхній список «підтримуваних GPU» не кодував запас пам’яті або поведінку драйвера.

Виправлення було непомпезним: додали VRAM-aware quality scaler, зменшили роздільність історії RT на 12GB картах і обмежили дистанцію віддзеркалення.
Також перестали використовувати «модель GPU» як проксі для «може дозволити цю фічу». Інцидент завершився, коли почали вимірювати те, що справді має значення.

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

Інша команда помітила, що rebuild BVH дорогі для динамічних об’єктів. Хтось запропонував оптимізацію:
«Позначимо більше об’єктів як статичні і оновлюватимемо лише трансформи.» У простому бенчмарку цифри покращилися.
Зміна пройшла код-рев’ю, бо виглядала безпечною.

Потім з’явилися репорти: у віддзеркаленнях персонажів інколи зникали кінцівки. Тіні були неправильні тільки в режимі рейтрейсингу.
Це було переривчасто. У густих сценах стало гірше. Команда тиждень ганялася за налаштуваннями денойзера, бо артефакти виглядали як тимчасова нестабільність.

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

Продуктивність «покращилась», бо двигун перестав виконувати потрібну роботу. Це не оптимізація — це брехня вашому рендереру.
Відкат виправив коректність, а потім вони зробили реальну оптимізацію: per-bone або per-cluster BLAS-оновлення там, де підтримується, плюс агресивний LOD для RT.

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

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

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

Вони також тримали невеликий зоопарк машин: один висококласний десктоп, одну середню GPU з меншим VRAM, один ноутбук з агресивними лімітами енергії,
і одну «брудну» машину з фоновими додатками — бо гравці неохайні.

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

Захоплення показало періодичні сплески rebuild BVH узгоджені зі стрімінгом ассетів. На ноутбуку SSD був повільніший, і CPU знижував частоти під впливом тепла,
що подовжувало вікно стрімінгу. Це подовжувало період, у який RT-пайплайн мусив перебудовувати/оновлювати структури прискорення для щойно завантажених мешів.

Виправлення було нудне й ефективне: вони розподілили побудову BVH на кілька кадрів, запрефетчили підмножину мешів перед камерними склейками,
і додали «не компілювати шейдери в середині кадру» для RT-пермутацій. Фіча вийшла стабільною.
Ніхто не написав про це гучного допису. Користувачі просто не стукали. Ось мрія.

Поширені помилки (симптом → причина → фікс)

1) Симптом: віддзеркалення «вискакують» або зникають на краях екрану

Причина: Ви все ще бачите поведінку SSR або гібридний фолбек, що переключається різко.

Фікс: Зливайте SSR у RT-віддзеркалення через стабільну евристику (roughness, ray confidence) і уникайте жорстких переключень. Забезпечте, щоб RT max distance покривав очікувані випадки.

2) Симптом: сліди-примари у віддзеркаленнях під час руху камери

Причина: Вектори руху для відображених об’єктів неправильні або відсутні; денойзер переиспользує некоректну історію.

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

3) Симптом: випадкові «іскри» на глянцевих поверхнях

Причина: Надто мало семплів плюс погане семплювання (fireflies), часто від яскравих емісивів або HDR-середовища.

Фікс: Клаптуйте радіанс для входу денойзера, покращіть семплювання (MIS, importance sampling) і обережно обробляйте емісиви в RT-шляхах.

4) Симптом: масивні підлагування при вході в нову зону

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

Фікс: Предкомпілюйте RT-шейдери; передбудуйте BLAS/TLAS де можливо; рознесіть побудови по кадрах; прогрівайте кеші під час екранів завантаження.

5) Симптом: режим RT працює нормально 10 хвилин, а потім деградує

Причина: Фрагментація/переповнення VRAM, коли накопичуються додаткові матеріали й буфери історії.

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

6) Симптом: RT-тіні виглядають «занадто різкими» або «неправильна м’якість»

Причина: Ви фактично робите жорсткі тіні (один семпл) без семплювання площинних джерел світла.

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

7) Симптом: продуктивність падає в сценах з великою кількістю скла/листя

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

Фікс: Використайте спрощену «RT-proxy» геометрію, обмежте глибину променя для заломлення і додайте LOD матеріалу для попадань променів (дешевші шейдери/текстури).

8) Симптом: стрибки часу кадру на CPU при увімкненому RT

Причина: Забагато проходів/дескрипторів, per-frame AS-оновлення, погане батчування, накладні витрати синхронізації.

Фікс: Зменшіть пер-кадр churn стану, батчуйте оновлення, заздалегідь виділіть дескриптори і профілюйте потоки відправки — не лише GPU-ядра.

9) Симптом: RT працює на одному вендорі, але ламається на іншому

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

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

10) Симптом: «RT увімкнено» робить зображення більш розмитим навіть при тій же роздільності

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

Фікс: Підвищте якість там, де важливо (семпли в ключових ефектах), виправте узгодженість G-буферів, налаштуйте пороги денойзера і додавайте підгострення після денойзу обережно.

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

Чекліст A: Вирішення, чи вартий рейтрейсинг вашого проєкту

1. Обирайте болючу точку, а не модне слово. Що гірше за все: віддзеркалення (провали SSR), тіні (аліасинг) чи GI (плоске освітлення)? Виберіть одне.
2. Визначте бюджет у мс. «Ми можемо витратити 2.5ms на віддзеркалення при 1440p з апскейлом» — це план. «Ми хочемо RT» — ні.
3. Визначте режим відмов. Під навантаженням ви віддаєте перевагу шуму, розмиттю чи зменшеному діапазону? Вирішіть і реалізуйте граціозне погіршення.
4. Зобов’яжіться до спостережуваності. Додайте лічильники для кількостей променів, часу побудови AS, часу проходу денойзера, відсотку відкинутої історії і запасу VRAM.
5. Плануйте пермутації. Якщо кожний матеріал дублюється у «RT-варіант», вам потрібен контроль або ви натворите компіляційних завіс.

Чекліст B: Випустити RT-фічу без сорому

1. Зафіксуйте стандартну бенчмаркову траєкторію. Та сама камера, та сама сцена, ті самі прапори збірки. Зберігайте захоплення.
2. Тестуйте середній VRAM-кейс. Якщо ви тестуєте лише на флагмані — ви робите демо, а не продукт.
3. Предкомпілюйте або кешуйте шейдери. Переконайтесь, що під час гри не відбувається компіляції шейдерів (логування).
4. Розподіляйте побудову AS. Не перебудовуйте все в одному кадрі під час стрімінгу; амортизуйте.
5. LOD матеріалу для попадань променів. Виріжте дорогі гілки для RT-шейдингу там, де це непомітно.
6. Перевірте вектори руху. Особливо для скинованих мешів, частинок і анімованих UV — денойзери жорстко карають за помилки.
7. Слідкуйте за p99 часом кадру. Якщо p99 поганий — користувачі скажуть «підлагування», навіть якщо середній FPS в нормі.

Чекліст C: Коли продуктивність погіршилась після «дрібних» змін

1. Підтвердіть середовище (драйвер, ліміти живлення, термали, PCIe лінк). Не відловлюйте привидів.
2. Порівняйте GPU-кадри між доброю і поганою збіркою в тому ж сценарії.
3. Перевірте дельти VRAM (нові буфери, вища роздільність історії, більші BLAS/TLAS).
4. Перевірте дельти кількості променів (випадкове подвоєння через налаштування якості або взаємодію масштабу роздільності).
5. Перевірте обсяг оновлень BVH (чи стало більше об’єктів «динамічними»?)
6. Перевірте входи денойзера (нормалі, глибина, вектори руху). Артефакти можуть призвести до «фіксів», що підвищують вартість.

Питання й відповіді

1) Чи рейтрейсинг — це лише віддзеркалення і тіні?

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

2) Чому рейтрейсинг виглядає шумним?

Бо ви семплюєте складний інтеграл занадто малою кількістю семплів на піксель. Шум — це дисперсія.
Реальний час RT зазвичай використовує дуже низькі значення семплів і покладається на денойзинг + тимчасове накопичення для стабільного вигляду.

3) Чому увімкнення RT іноді знижує завантаження GPU?

Це може ввести точки синхронізації, підвищити витрати на відправку з CPU або спричинити тиск пам’яті, що зупиняє GPU.
Високе завантаження не гарантовано, якщо конвеєр набивається бульбашками.

4) У чому різниця між рейтрейсингом і path tracing у іграх?

«Рейтрейсинг» в іграх зазвичай означає конкретні ефекти (віддзеркалення/тіні/GI) з обмеженими променями і сильним денойзингом.
«Path tracing» прагне симулювати повне глобальне освітлення з багатьма відскоками, але в реальному часі він все ще агресивно оптимізований і денойзиться.

5) Чи роблять виділені RT-ядра рейтрейсинг «безкоштовним»?

Ні. Вони прискорюють traversal/intersection, що важливо, але ви все одно платите за генерацію променів, шейдинг, пропускну здатність пам’яті і денойзинг.
Можна бути шейдинг-заблокованим або bandwidth-заблокованим навіть з RT-апаратною підтримкою.

6) Чому дзеркала іноді досі виглядають неправильно з RT?

Бо багато реалізацій обмежують дистанцію променя, глибину променя або складність матеріалу; і денойзери можуть розмити деталі.
Також деякі пайплайни використовують гібридні фолбеки, які можуть не збігатись у крайових випадках між SSR/probes/RT.

7) Яка найпоширеніша причина підлагувань RT?

Рuntime-компіляція шейдерів і стрімінг ассетів, що збігаються з побудовами/оновленнями BVH.
Середній час кадру може виглядати прийнятним, а ось p99 — жахливий. Виправляйте зависання першими.

8) Чи варто крутити samples-per-pixel, щоб виправити артефакти?

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

9) Чи «гібридний рендеринг» менш точний, ніж повний рейтрейсинг?

Він менш однорідний, але часто більш придатний до релізу. Растеризація дуже ефективна для первинної видимості.
Використовуйте промені там, де растер-хакі системно підводять: позаекранні віддзеркалення, м’які тіні, певні випадки GI.

10) Що вимірювати спочатку: промені, BVH чи денойзер?

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

Наступні кроки, які не марнуватимуть ваш час

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

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

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