G-buffer: terrain-free static shader + terrain pipeline; slim G-buffer VS #813
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#813
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?
Merged (
be625ce523,2c14225fd0). The G-buffer fragment shader used 112 registers because PBR terrain (mostly hex tiling) was compiled into every draw; non-terrain draws now use a 48-register shader and terrain its own (72, 112 with hex as a specialisation constant). G-buffer static pass 2.79-2.95 -> 1.92-2.18 ms (Firestorm-equivalent settings) and 4.48 -> 3.14 ms (high settings) on the GTX 1080 at 4K. Settings RenderVKGbufTerrainSplit / RenderVKGbufSlimVS (both default on).Still to check before closing: image A/B (terrain with and without hex, coplanar terrain/prim seams), occlusion paths on, ship.
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.