Рейтрейсинг у 2026: чому це досі складно — і все одно неминуче

Чому це неминуче (навіть якщо боляче)

Неприємна правда: растеризація — це блискуче наближення, але водночас купа виключень. Тіні — окрема система.
Відображення — окрема система. Ambient occlusion — окрема система. Глобальне освітлення — окрема система. Кожна з них має свої хаки,
і кожен хак додає обмеження контенту та крайові випадки. Рейтрейсинг не просто «реалістичніший»; він однорідніший. Єдиний механізм — випустити промені, перетнути геометрію, накопичити світло — замінює музей спеціальних трюків.

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

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

Парафраз ідеї Джона Оллспо (інженерія надійності): «Системи падають у несподіваний спосіб; робота — вчитися на інцидентах, а не звинувачувати людей.»
Робота з рейтрейсингом відчувається так само. Якщо ви звинувачуєте художників, драйверні команди чи «ту одну GPU», ви ще не займаєтеся операціями. Ви все ще в суєтності.

Чому це досі складно у 2026

1) Промені — хижаки пропускної здатності

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

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

2) Шум — це не баг; це рахунок

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

Операційний переклад тут: ви не прибрали хаки; ви пересунули їх. Хаки тепер у денойзері й управлінні історією.
Вони все ще хаки, у них все ще є режими відмови, і вам все ще потрібний моніторинг — але не той, що добре лягає в скріншот з renderdoc.

3) BVH — це живі структури даних, не статичні артефакти

Акселераційні структури (BVH, TLAS/BLAS) — ваш індекс. Якщо він застарів, ваші промені брешуть. Якщо він пересобирається занадто часто, ваш час CPU/GPU зникає.
Якщо він «підгоняється» (refit), коли треба пересобрати, ви отримуєте неефективний треверсал, що виглядає як «випадкове сповільнення GPU».

Також: ваша команда контенту відправить щось, що порушує ваші припущення. Вони завжди так роблять. Їхня робота — доставляти арт, а не поважати вашу просторову структуру даних.

4) Компіляція шейдерів і створення станів пайплайна все ще викликають підлагування

У 2026 шейдерні кеші кращі, пайплайни явніші, і тим не менше: підлагування залишаються.
Рейтрейсинг вводить більше варіантів шейдерів (hit groups, miss shaders, callable shaders, варіації матеріалів) і більше шансів на «компіляцію при першому зверненні».
Якщо ви не ставитесь до компіляції як SRE до cold-start latency, ви випустите гру, яка в бенчмарку гарна, а насправді відчувається жахливо.

5) Гібридний рендеринг — операційно брудний

Багато продакшн-движків досі використовують гібридний рендеринг: растер для первинної видимості + рейтрейсинг для відображень, тіней, AO, можливо GI.
Це прагматично. Але саме тут плодяться баги, бо у вас два світи: два поняття глибини, два набори нормалей (геометричні vs шейдінгові), два представлення прозорості, дві версії «що видиме».

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

6) Регулятор «якість/продуктивність» багатовимірний

Функції растера часто мають досить монотонне криве скейлінгу: менша роздільна тіньова карта, менше каскадів, менше вибірок. У рейтрейсингу повзунки взаємодіють:
промені на піксель, глибина відскоків, макс дистанція, порогова обробка для шорсткості, стратегія importance sampling, налаштування денойзера, обмеження історії, ресемпл резервоару.
Повернути один повзунок може погіршити денойзер, що змусить вас повернути інший, що змінює тимчасову стабільність, що змінює фантоми.

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

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

• Рейттедовський стиль (Whitted-style) (кінець 1970-х/початок 1980-х) популяризував рекурсивні промені відбиття/рефракції, але тоді припускали світ з ідеальними дзеркалами і сферами у порівнянні зі складністю матеріалів сьогодні.
• Path tracing став фізично-орієнтованою «земною правдою» для офлайн рендерингу, прийнявши випадковість і багато вибірок; робота в реальному часі по суті — «path tracing із дуже жорстким бюджетом вибірок».
• Акселераційні структури BVH витіснили kd-дерева в багатьох реальних сценаріях, бо BVH краще піддаються refit для анімацій і динамічних сцен.
• Ранні демо рейтрейсингу в реальному часі часто сперлися на обмежені сцени (мало трикутників, обмежені матеріали). Складність була не в демо — а в доставці непередбачуваного пайплайна контенту.
• DXR і Vulkan ray tracing зробили рейтрейсинг фічею першого класу API; вони також зробили створення пайплайнів і управління шейдерними пермутаціями серйозною проблемою.
• Виділене апаратне забезпечення для треверсалу/перетину перемістило вузьке місце в бік поведінки пам’яті, дивергенції шейдингу й денойзингу, а не лише «чи досить швидко ми можемо робити перетини?»
• Тимчасові денойзери стали стандартом, бо тільки простий просторовий денойз не відновлює деталі при низьких вибірках; саме тому вектори руху та коректність історії важать так само, як попадання променя.
• Гібридний рендеринг лишився, бо «повний path tracing» при стабільних фреймрейтах все ще дорогий, коли додаєш виробничі матеріали, частинки, волосся і прозорості.

Реальний конвеєр: де ховається біль

Первинна видимість: вам досі потрібна стабільна база

Навіть якщо ви робите інтенсивний RT, більшість релізного контенту все ще виграє від стабільного проходу первинної видимості.
Чистий G-buffer з послідовними нормалями, шорсткістю, векторами руху та глибиною — це підкладка, з якої живиться денойзер.
Якщо ваш G-buffer брешить — неправильні вектори руху для скінованих мешів, NaN у нормалях, невідповідний TAA джиттер — ваш рейтрейсинг виглядатиме «шумним» так, що денойзер не зможе допомогти.

Акселераційні структури: збірка, refit і вартість помилок

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

Операційно вам потрібно:

• Чіткі політики, що потрапляє у BLAS як статичне, refit чи виключене.
• Інструментація, що показує час збірки/refit по кадру і використання пам’яті AS.
• Валідація контенту: кількість трикутників, адекватність AABB, трансформи, вироджені випадки.

Треверсал — не єдиний ваш ядро

Рейтрейсинг у реальному часі — ланцюг ядер: збірка/refit, трасування, шейдинг попадань, вибірка текстур, запуск денойзера, композитинг, постпроцес.
Крок «trace» часто не є найбільшою вартістю. Шейдинг — там, де дивергенція вибухає: різні матеріали, різні текстури, різні BRDF-шляхи.

Якщо ви хочете стабільного часу кадру, оптимізуйте для хвоста, а не для середнього. 99-й процентиль — там живуть баги QA і скарги гравців.

Денойзинг — це розподілена система (у мініатюрі)

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

Рейтрейсинг і зберігання: частина, про яку ніхто не хоче говорити

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

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

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

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

Завдання 1: Підтвердити, що GPU і драйвер дійсно використовуються

cr0x@server:~$ nvidia-smi
Tue Jan 21 10:14:08 2026
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 560.18                 Driver Version: 560.18         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 4080                Off | 00000000:01:00.0  On |                  N/A |
| 35%   56C    P2             180W / 320W |   9120MiB / 16376MiB |     92%      Default |
+-----------------------------------------+----------------------+----------------------+

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

Рішення: Якщо VRAM > 90% у сценах з RT — пріоритезуйте зниження пам’яті (компактація AS, нижча резидентність текстур, менше RT-таргетів) перед мікрооптимізаціями шейдерів.

Завдання 2: Перевірити, чи немає throttling через живлення/температуру

cr0x@server:~$ nvidia-smi -q -d POWER,CLOCK,TEMPERATURE | sed -n '1,120p'
==============NVSMI LOG==============

Temperature
    GPU Current Temp            : 83 C
    GPU Shutdown Temp           : 95 C
    GPU Slowdown Temp           : 87 C

Clocks
    Graphics                    : 2235 MHz
    SM                          : 2235 MHz
    Memory                      : 10501 MHz

Power Readings
    Power Draw                  : 318.44 W
    Power Limit                 : 320.00 W

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

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

Завдання 3: Виявити проблеми PCIe, що маскуються під «RT повільний»

cr0x@server:~$ lspci -vv -s 01:00.0 | sed -n '1,80p'
01:00.0 VGA compatible controller: NVIDIA Corporation Device 2704 (rev a1)
        LnkCap: Port #0, Speed 16GT/s, Width x16
        LnkSta: Speed 8GT/s (downgraded), Width x16 (ok)
        Kernel driver in use: nvidia

Що це означає: Лінк працює на 8GT/s замість 16GT/s. Це може вдарити по стрімінгу і оновленнях AS.

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

Завдання 4: Вловити CPU-бокси (збірки BVH, сабміт, стрімінг)

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

10:14:20 AM  CPU   %usr %nice %sys %iowait %irq %soft %steal %idle
10:14:21 AM  all   62.10 0.00  9.44   0.35 0.00  0.88   0.00 27.23
10:14:21 AM    7   98.00 0.00  1.00   0.00 0.00  0.00   0.00  1.00
10:14:21 AM   13   97.00 0.00  2.00   0.00 0.00  0.00   0.00  1.00

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

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

Завдання 5: Подивитися, чи ви IO-обмежені через шейдерний кеш або стрімінг активів

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.0 (buildbox)  01/21/2026  _x86_64_  (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          55.10    0.00    8.23    6.42    0.00   30.25

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s w_await aqu-sz  %util
nvme0n1        182.0  52240.0     0.0   0.00    8.40   287.0    96.0  18012.0   14.20   2.92   89.3

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

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

Завдання 6: Перевірити тиск пам’яті, що спричиняє спорадичні паузи

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           128Gi        96Gi        4.2Gi       1.6Gi        28Gi        24Gi
Swap:           16Gi        5.8Gi        10Gi

Що це означає: Swap активний. Це червоний прапорець для редакторських збірок і шейдерної компіляції.

Рішення: Якщо swap ненульовий під час перф-зйомок, ви бенчмаркуєте інцидент керування пам’яттю. Виправте RAM-проблеми перш ніж продовжувати.

Завдання 7: Виявити NUMA-помилки при CPU-важких збірках/refit

cr0x@server:~$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0-15
node 0 size: 64088 MB
node 0 free: 11204 MB
node 1 cpus: 16-31
node 1 size: 64110 MB
node 1 free: 4102 MB

Що це означає: Нода 1 тісно по вільній пам’яті. Якщо ваш рендер-тред працює на ноді 1, а алокації падають на ноду 0 — латентність зростає.

Рішення: Прив’язуйте критичні потоки й виділяйте пам’ять локально по вузлу. NUMA-проблеми відчуваються як «випадкові спайки», поки ви не подивитесь уважно.

Завдання 8: Підтвердити поведінку hugepages / THP (може впливати на CPU-збірки)

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

Що це означає: THP встановлено в madvise (загалом розумно). «always» може викликати латентні спайки для деяких робочих навантажень.

Рішення: Якщо ви бачите періодичні затримки й THP «always» — протестуйте з «madvise» на збіркових машинах. Не копіюйте без вимірів; міряйте.

Завдання 9: Знайти скидання шейдерного кеша, дивлячись за файловою активністю

cr0x@server:~$ sudo inotifywait -m -e create,modify,delete /var/cache/shadercache
Setting up watches.
Watches established.
/var/cache/shadercache/ CREATE psos.bin.tmp
/var/cache/shadercache/ MODIFY psos.bin.tmp
/var/cache/shadercache/ DELETE psos.bin.tmp

Що це означає: Кеш перезаписується постійно. Часто це розбіжність ключів версії або надто широка інвалідизація.

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

Завдання 10: Вловити джиттер планування CPU під навантаженням

cr0x@server:~$ pidstat -t -p $(pgrep -n game-client) 1 3
Linux 6.8.0 (buildbox)  01/21/2026  _x86_64_  (32 CPU)

10:14:42 AM   UID      TGID       TID    %usr %system  %guest   %CPU   CPU  Command
10:14:43 AM  1000     22184     22184   35.00    6.00    0.00  41.00     7  game-client
10:14:43 AM  1000     22184     22201   72.00    2.00    0.00  74.00    13  RenderThread
10:14:43 AM  1000     22184     22218   41.00    1.00    0.00  42.00     2  RTASBuilder

Що це означає: Ви бачите, які потоки спалюють CPU. Якщо RenderThread завантажений — у вас CPU-обмеження, а не обмеження RT-ядрами.

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

Завдання 11: Відстежити апаратні помилки GPU на рівні ядра, які списують на «RT баги»

cr0x@server:~$ dmesg -T | tail -n 20
[Tue Jan 21 10:13:58 2026] nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
[Tue Jan 21 10:13:59 2026] NVRM: Xid (PCI:0000:01:00): 31, pid=22184, name=game-client, Ch 0000002b, intr 10000000

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

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

Завдання 12: Переконатися, що ваш контейнер/CI ранери бачать GPU коректно

cr0x@server:~$ nvidia-container-cli info | sed -n '1,80p'
NVRM version:   560.18
CUDA version:   12.4

Device Index:   0
Device Minor:   0
Model:          NVIDIA RTX 4080
IRQ:            132
GPU UUID:       GPU-3d2a0e2f-7aa3-4a19-9d16-1d2fbbd2a0a1
Bus Location:   00000000:01:00.0

Що це означає: Підтверджує, що runtime контейнера бачить GPU. CI perf-тести без правильного доступу до GPU дають нісенітницю.

Рішення: Якщо GPU не видно — зупиніться. Виправте ранери. Не погоджуйтеся на «падіння до софтверного fallback» для RT-бенчів.

Завдання 13: Перевірити можливості Vulkan-пристрою (саніті-чек у CI)

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

Devices:
========
GPU0:
        apiVersion         = 1.3.280
        deviceName         = NVIDIA RTX 4080
        driverVersion      = 560.18.0
        deviceType         = DISCRETE_GPU

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

Рішення: Якщо Vulkan loader або драйвер відрізняються від вашого перф-бейзлайну — трактуйте регреси як дрейф середовища, поки не доведете інше.

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

cr0x@server:~$ sudo perf stat -a -- sleep 5
 Performance counter stats for 'system wide':

        24520.33 msec task-clock                #    4.904 CPUs utilized
           182,441      context-switches          #    7.442 K/sec
            11,204      cpu-migrations            #  456.922 /sec
             5,220      page-faults               #    0.213 K/sec

       5.001215625 seconds time elapsed

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

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

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

План швидкої діагностики

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

Перший крок: класифікуйте режим відмови за 10 хвилин

• Стабільно, але занадто повільно: час кадру послідовно високий. Думайте про пропускну здатність, занадто багато променів, дорогий шейдинг або вартість збірки AS.
• Швидко в середньому, але зі спайками: стутер. Думайте про компіляцію, стрімінг IO, сплески пересборки AS, осциляцію живлення/температури або конкуренцію CPU.
• Виглядає неправильно: фантоми, розмазування, блискітки. Думайте про вектори руху, інвалідизацію історії, невідповідність нормалей/глибини або застарілий TLAS.
• Падіння/зависання: думайте про драйвер-таймаути, неправильні дескриптори, NaN, вихід за межі буферів або маргінальну апаратну стабільність.

Другий крок: ізолюйте CPU vs GPU vs IO

1. Перевірка GPU-bound: якщо завантаження GPU високе, а CPU-потоки не забиті, швидше за все ви GPU-обмежені (але все одно може бути обмеження пам’яті на GPU).
2. Перевірка CPU-bound: якщо одне чи два CPU-потоки завантажені й завантаження GPU падає — ви обмежені сабмітом/збіркою.
3. Перевірка IO-bound: якщо стутер збігається з високим дисковим навантаженням і перезаписом кешу — виправляйте стрімінг/компіляційний пайплайн.

Третій крок: визначте домінуючу RT-статтю витрат

• Переважає збірка/refit AS: занадто багато динамічних мешів, політика rebuild занадто агресивна, немає інстансу, або погане повторне використання BLAS.
• Переважає трасування: занадто багато променів, занадто велика макс дистанція, надмірні any-hit (alpha test) операції.
• Переважає шейдинг: дивергентні матеріали, дорогі текстури, забагато hit shaders або занадто багато рекурсії/відскоків.
• Переважає денойзинг: занадто багато RT-таргетів у повному розширенні, дорога тимчасова логіка або слабка історія, що вимагає сильнішого фільтрування.

Четвертий крок: затвердіть «відомо-правильну сцену» як базу

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

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

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

Студія випустила рейтрейсовані відображення в оновленні живої гри. Фіча була заґейтована перемикачем налаштувань, і внутрішнє припущення було простим:
«Якщо RT вимкнено, ми за RT не платимо.» У них був охайний діаграм, що це показує. Діаграми заспокоюють.

Патч вийшов. За день почали надходити звіти гравців: періодичні підвисання кожні кілька секунд на mid-tier GPU, навіть коли RT вимкнено.
QA не могло відтворити це стабільно. Перф-зйомки виглядали нормально при вимірюваннях на довгих інтервалах. Тикети служби підтримки були хаотичні: різні драйвери, різні збірки ОС, різні оверлеї.

Корінь був буденний і трохи соромний: двигун завжди будував TLAS кожні N кадрів, бо система відображень повторно використовувала ту ж сценну репрезентацію, що й система probe-оклюзії.
Тумблер вимикав фінальний проход відображень, а не підготовку сцени вгору по ланцюжку. На машинах з RT-вимкнено вони платили податок BVH і не отримували візуалу.

Виправлення не було героїчним. Вони перемістили підготовку BVH за гейт можливостей і налаштувань, додали лічильники «час збірки AS навіть коли RT вимкнено» і написали тест, що асертує, що лічильник близький до нуля у режимі RT-off.
Продуктивність відразу покращилась. Організаційний виграш був більший: команда перестала довіряти «вимкнено = вимкнено», якщо профайлери не підтверджують.

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

Інша команда намагалася відкусити мілісекунди, агресивно роблячи refit BVH замість повного пересбору. На папері refit дешевший:
оновити межі, зберегти топологію, рухатися далі. Їхня початкова бенчмарк-сцена — переважно жорсткі меші з помірним рухом — виглядала добре.

Потім з’явився контент. Анімації стали екстремальнішими, скіновані меші стали звичними в рефлективних кадрах, художники почали використовувати морф-таргети для близьких планів обличчя.
Вартість треверсалу повзла вгору. Не трішки. Достатньо, щоб денойзеру довелось працювати більше, отже більше тимчасової залежності, отже більше скарг на фантоми.
Оптимізація не тільки вдарила по продуктивності; вона опосередковано погіршила якість.

Постмортем був повчальний: refit давав «вільні» BVH. Промені повинні були проходити більше вузлів, влучати в більшу кількість кандидативних трикутників, і GPU витрачав час на доведення негативів.
Команда оптимізувала стадію побудови, тихо роздуваючи стадію запитів — класичне переміщення витрат.

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

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

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

Одного тижня оновлення драйвера закочувалося на підмножину внутрішніх машин і внесло спорадичний стутер у шлях рейтрейсованих тіней.
Середній FPS виглядав нормально. 99-й процентиль часу кадру — вже ні. Гравці назвали б це «лагом». Команда — «неможливо відтворити».

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

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

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

1) «Відображення іскряться і повзуть»

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

Причина: недовибірка + нестабільний blue noise + невідповідність між normal map і геометричними нормалями, що спричиняє непослідовний шейдинг попадань кадр-до-кадру.

Виправлення: стабілізувати послідовності вибірок, обмежити історію для блиску й гарантовано узгодити декодування normal map між растерним і RT-hit шейдерами. Розгляньте бюджет променів залежно від шорсткості.

2) «За об’єктом тягнеться фантомний шлейф»

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

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

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

3) «Увімкнений RT спричиняє випадкові спайки часу кадру»

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

Причина: компіляція шейдерів, створення станів пайплайна або інвалідизація шейдерного кеша. Іноді також сплески пересборки AS при підвантаженні нової геометрії.

Виправлення: попередньо компілюйте PSO/hit groups, зберігайте кеші між запусками і прогрівайте сцени контрольованими шляхами камери. Розбивайте збірки AS і уникайте одночасного пересобрання всього.

4) «Продуктивність тане в сценах з густою рослинністю»

Симптом: RT-тіні/відблиски стають непридатними у рослинності.

Причина: any-hit шейдери для alpha testing дорогі; треверсал стає розгалуженим; багато дрібних трикутників руйнують якість BVH.

Виправлення: зменшити участь alpha-tested матеріалів (fallback на shadow maps), використовувати opacity micromaps при наявності підтримки, спростити геометрію листя для RT і віддавати перевагу маскованим матеріалам, які можна апроксимувати.

5) «Виглядає гарно на скріншотах, жахливо в русі»

Симптом: скріншоти гарні; геймплей розмитий.

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

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

6) «Падає лише на одному вендорі»

Симптом: зависання/таймаути GPU, device lost, лише на певних гілках драйверів.

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

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

7) «RT вимкнено — але все одно коштує продуктивності»

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

Причина: upstream робота (підготовка AS, класифікація матеріалів, оновлення кешів) все ще виконується; тумблер підключений надто пізно в пайплайні.

Виправлення: перемістіть гейтування раніше; додайте лічильники «робота виконана при вимкненому фічі» і проваліть CI, якщо вони перевищують поріг у режимі RT-off.

8) «Якість сильно відрізняється на різних GPU»

Симптом: денойзер поводиться по-різному або баланс перф/якості несподівано змінюється між архітектурами.

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

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

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

Крок 1: Визначте ціль продукту для рейтрейсингу (перестаньте бути розмитими)

• Виберіть ключові фічі: відображення? тіні? GI? Одну-дві, не п’ять.
• Встановіть бюджети часу кадру: наприклад «RT-фічі отримують 4 ms при цілі 60 fps» (налаштуйте під платформу).
• Визначте мінімальну прийнятну стабільність: цілі по процентилям часу кадру, а не лише середні.

Крок 2: Побудуйте вимірювальний хранос

• Один детерміністичний шлях камери («відомо-правильна сцена»).
• Одна стресс-сцена з найгіршим контентом (рослинність, скінінг, частинки, дзеркала).
• Зняття метрик: середній час кадру, 95/99 перцентилі, VRAM, час збірки AS, шейдерні пропуски кеша, IO використання.

Крок 3: Визначте політику AS як інженер, а не поет

• Які активи BLAS статичні, а які динамічні?
• Пороги refit vs rebuild (за класами мешів).
• Правила інстансингу і ліміти.
• Правила виключення: частинки, дрібна геометрія, декалі, певні типи прозоростей.

Крок 4: Зробіть денойзинг підсистемою першого класу

• Валідуйте вектори руху й вирівнювання джиттера як gating-тест.
• Реалізуйте надійну детекцію дисоклюженції й реактивне маскування.
• Відкрийте debug-перегляди (вага історії, довіра, оцінка дисперсії).
• Бюджетуйте вартість денойзера явно; не дозволяйте їй «просто рости».

Крок 5: Ставтеся до компіляції шейдерів як до продакшн-латентності

• Постійні кеші з коректними ключами версій.
• Пре-компіляція критичних пайплайнів/hit groups для поширених матеріалів.
• Фонові компіляції з лімітом швидкості.
• CI-чеки, що ловлять шторми інвалідизації кеша.

Крок 6: Випускайте з запобіжними заходами

• Динамічна масштабованість: зменшуйте промені/вибірки, скорочуйте макс дистанції, обмежуйте відскоки під навантаженням.
• Безпечні fallback-и по фічі (SSR fallback для відображень, shadow maps для рослинності тощо).
• Телеметрія: процентилі часу кадру, використання RT-тумблерів, GPU-креші (агреговано й безпечно для приватності).

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

1) Чи практичний повний реальний час path tracing у 2026?

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

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

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

3) Яка найбільша прихована вартість: треверсал, шейдинг чи денойзинг?

Залежить від контенту, але шейдинг і денойзинг часто стають «сюрпризами». Апаратний треверсал покращився; поведінка пам’яті та дивергенція все ще кусає.
Денойзинг може стати податком, який ви платите кілька разів (відображення + тіні + GI), особливо при високій роздільності.

4) Чому рослинність і alpha-tested матеріали так сильно шкодять?

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

5) Як зменшити стутер від компіляції шейдерів?

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

6) Чи слід пересобирати BVH кожен кадр, щоб уникнути проблем з якістю?

Ні. Пересборка всього — груба сила, що спалює бюджет. Краще мати виміряну політику: статичні BLAS повторно використовуються, динамічний refit у межах порогів деформації,
rebuild лише коли refit slack росте. Інструментуйте компроміс; не вгадуйте.

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

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

8) Що тестувати в CI, щоб тримати рейтрейсинг стабільним?

Тести регресії процентилів часу кадру, перевірки перезапису шейдерного кеша, бюджети часу збірки AS, VRAM-чекери та асерти «RT-off не робить RT-роботу».
Додайте детекцію дрейфу драйверів/тулчейнів, щоб не плутати зміни середовища з змінами движка.

9) Чи «більше променів на піксель» завжди краще за «кращий денойзер»?

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

Практичні наступні кроки

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

1. Виберіть дві ключові RT-фічі і дайте їм явні бюджети (час, VRAM і процентилі).
2. Інструментуйте збірку/refit AS, вартість денойзера і перезапис кеша, щоб ви могли відповісти «куди пішов час кадру?» без здогадок.
3. Встановіть базову сцену і ставтеся до неї як до канарки для регресій двигуна.
4. Зробіть RT-off дійсно вимкненим, загейтуючи upstream роботу, потім тестуйте це автоматично.
5. Стабілізуйте входи до денойзера (вектори руху, нормалі, глибина) перед тим, як налаштовувати параметри денойзера.
6. Керуйте драйверами й тулчейнами як залежностями з контрольованими оновленнями, а не випадковим дрейфом.

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