Slim G-buffer VS: find the real register peak #821

New issue

Open

opened 2026-10-17 18:10:02 +00:00 by sky_line · 0 comments

sky_line commented

2026-10-17 18:10:02 +00:00

Owner

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.

The slim G-buffer VS (no previous-frame pose, no pick outputs) saves ~0.3 ms but still measures 94-95 registers (depth-only VS: 54). Find what holds the registers (instance row fetch with two mat4s, texture-animation UV, tangent / matMapUVMatrix, spin, encloses-camera test, joint table) with register probes like RenderVKGbufRegProbe, and specialise or move the cost. 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.

sky_line added the

labels

2026-10-17 18:10:02 +00:00

sky_line added this to the Slipstream project

2026-10-17 18:10:02 +00:00

sky_line referenced this issue from a commit

2026-10-22 19:32:55 +00:00

#821: slim G-buffer VS register probes (find what holds its ~95 registers)