Lighting: flatten the light-loop load chain #815
Labels
No labels
amd
avatars
bug
builder
cannot-reproduce
crash
epic
feature
from-viewer
gl-removal
known-limitation
monitoring
parity
perf
platform
priority
critical
priority
high
priority
low
priority
medium
provenance
rendering
rt
status
in-progress
status
testing
status
up-next
triage
ui
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sky_line/Slipstream#815
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Each candidate light costs two serial memory round trips (pos_radius, then the full 160 B record; projectors add proj_mat, gobo, atlas). The loop's early exits stop the compiler hoisting the next light's load. Options: stage the tile's (or froxel cell's) surviving lights into shared memory once as compact point / projector records, or a dense 32 B pos/colour array with the next light preloaded. Lossless. Local lights are ~22% of lighting cycles on a ~370-light scene.
Measure: shader-clock LOCAL stage and lighting time.
Context: measured on a GTX 1080 (Pascal) at 4K with the test-control channel and the shader clock (RenderVKShaderClockLighting) / pipeline stats (RenderVKPipelineStats). The frame is GPU-bound but not bandwidth-bound (memory controller ~36% busy on the 1080, ~14% on a 5090): it is latency / occupancy bound, so trading a little memory traffic for fewer registers and fewer dependent loads should help every GPU generation.
Fixed in Slipstream 1.3.0 (stable): https://git.slipstreamviewer.org/sky_line/Slipstream/releases/tag/v1.3.0
If you still see this on 1.3.0, reply here and we'll reopen it.