Scalarize light loop
- Dominant language
- Rust
- Stars
- 48.2k
- Forks
- 4.8k
- Avg merge
- 3d 16h
- Merged PRs (30d)
- 171
Description
## What problem does this solve or what need does it fill?
Less register pressure in our PBR shader = higher occupancy = higher performance.
Applies to direct lights, light probes, future decal support, etc.
## What solution would you like?
Implement strategies from https://flashypixels.wordpress.com/2018/11/10/intro-to-gpu-scalarization-part-2-scalarize-all-the-lights and https://themaister.net/blog/2020/01/10/clustered-shading-evolution-in-granite, https://advances.realtimerendering.com/s2020/RenderingDoomEternal.pdf, etc.
## Additional context
I tried this in https://github.com/bevyengine/bevy/pull/15183, but it seemed to either do nothing, or make things a bit worse.
My theory is that register pressure is already so high in our PBR shader, scalarizing the loops didn't actually help.
Might have been better with deferred, don't think I tested it. Or better in scenes with much larger amounts of lights. Or on AMD (I tested only on NVIDIA).
Contributor guide
Research direction
Begin with prior PR #15183 and the linked scalarization articles and presentations; compare their assumptions with the current PBR light-loop behavior. Benchmark direct-light and light-probe scenes across the mentioned NVIDIA and AMD cases and varying light counts. Consider the work complete only when a reproducible occupancy or performance improvement is demonstrated without regressions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- computer-graphics, game-dev, performance
- Issue type
- Refactor
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100