[Epic] Shared ray-traced visibility pass (ray queue) for shadows, GI, reflections and lit shaders #1039

Open
opened 2026-10-25 03:19:37 +00:00 by sky_line · 0 comments
Owner

Epic. Replace the ray-traced visibility walks that are inlined into many kernels with one shared visibility pass driven by a ray queue.

Why

The same walk (the candidate alpha test, transmission / foliage / blend-layer accumulation, the fixture rule) is inlined into the RT shadow visibility kernels, GI hit lighting (sun ray), RT reflection lighting (sun ray + blend layers), probe RT, and the forward lit shader's ray-query variants. The 2026-10-24 profiling (#1031 / #1036) showed:

  • every one of these sits at 168-255 registers, because the walk runs with the consumer's state live around it;
  • every walk optimisation has to be redone per consumer;
  • the walk is a large part of why the RT pipelines are huge to compile (#849, #890).

Shape

  1. Consumers write compact visibility requests (origin, direction, tmax, kind, mask, flags, result slot) into a shared queue, together with their unshadowed terms.
  2. One lean walk pass (one kernel per walk kind: opaque / grey / RGB / foliage / accumulating blend layers) traces every request and writes its result. No consumer state is live.
  3. Consumers resolve their terms with the stored visibility.

Per-kind policies replace per-consumer special cases. For example, a GI-hit sun request can be opaque-only (#981), and weak point lights can skip their rays (#983).

Phases

  1. Shadow visibility (builds on the #1031 per-sample job list), the GI hit sun ray, the reflection sun ray.
  2. The reflection blend-layer walk as an accumulating kind.
  3. The forward / alpha lit shaders through a compute visibility pre-pass, removing the lit ray-query variants (#849).

#849 (phase 3), #981, #983, #890, #1031, #1036. #256 (raster visibility buffer) is separate.

A design document comes first (agent design pass): request and result formats, kinds, consumer splits, memory budget, async scheduling, the expected pipeline count / compile-size reduction, plus a survey of other duplicated code and features in the pipeline that could be split out the same way.

**Epic.** Replace the ray-traced visibility walks that are inlined into many kernels with one shared visibility pass driven by a ray queue. ## Why The same walk (the candidate alpha test, transmission / foliage / blend-layer accumulation, the fixture rule) is inlined into the RT shadow visibility kernels, GI hit lighting (sun ray), RT reflection lighting (sun ray + blend layers), probe RT, and the forward lit shader's ray-query variants. The 2026-10-24 profiling (#1031 / #1036) showed: - every one of these sits at 168-255 registers, because the walk runs with the consumer's state live around it; - every walk optimisation has to be redone per consumer; - the walk is a large part of why the RT pipelines are huge to compile (#849, #890). ## Shape 1. Consumers write compact visibility requests (origin, direction, tmax, kind, mask, flags, result slot) into a shared queue, together with their unshadowed terms. 2. One lean walk pass (one kernel per walk kind: opaque / grey / RGB / foliage / accumulating blend layers) traces every request and writes its result. No consumer state is live. 3. Consumers resolve their terms with the stored visibility. Per-kind policies replace per-consumer special cases. For example, a GI-hit sun request can be opaque-only (#981), and weak point lights can skip their rays (#983). ## Phases 1. Shadow visibility (builds on the #1031 per-sample job list), the GI hit sun ray, the reflection sun ray. 2. The reflection blend-layer walk as an accumulating kind. 3. The forward / alpha lit shaders through a compute visibility pre-pass, removing the lit ray-query variants (#849). ## Related #849 (phase 3), #981, #983, #890, #1031, #1036. #256 (raster visibility buffer) is separate. A design document comes first (agent design pass): request and result formats, kinds, consumer splits, memory budget, async scheduling, the expected pipeline count / compile-size reduction, plus a survey of other duplicated code and features in the pipeline that could be split out the same way.
sky_line added this to the Slipstream project 2026-10-25 03:19:37 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Reference
sky_line/Slipstream#1039
No description provided.