LOD GPU roadmap Phase 3: GPU culling and indirect command generation

[MichaelFisher1997]

Goal

Move high-cardinality visibility and draw-command compaction to GPU compute after CPU visibility and MDI are efficient and measurable.

Depends on

Phases 0-2: metrics, stable pooled/indirect rendering, and safe asynchronous resource lifetime.

Parallel workstreams

Data contract and fallback

• Define compact per-region bounds, LOD hierarchy/fade state, draw ranges, water ranges, and coverage flags.
• Extend RHI contracts for compute-to-indirect barriers and count/indirect drawing as needed.
• Retain CPU culling below a measured candidate threshold and on unsupported devices.

Compute visibility

• Implement distance and frustum culling into compact visible-instance and indirect-command buffers.
• Preserve parent fallback until required children are renderable.
• Generate separate terrain and water command streams without duplicating visibility work.
• Add overflow bounds, counters, validation mode, and CPU/GPU result comparison.

Optional occlusion

• Integrate the existing depth pyramid only after frustum/indirect culling is stable.
• Use temporal hysteresis/conservative bounds to avoid popping.
• Benchmark whether occlusion pays for itself in open terrain; disable it when candidate count or expected occlusion is low.

Relevant code

• modules/world-lod/src/lod_renderer.zig
• modules/engine-rhi/
• modules/engine-graphics/src/vulkan/
• assets/shaders/vulkan/culling.comp
• assets/shaders/vulkan/depth_pyramid.comp

Acceptance criteria

• The environment/config GPU-culling option performs real GPU culling rather than warning and falling back.
• GPU output matches CPU reference visibility in validation mode.
• Terrain and water are rendered from compact indirect command streams.
• Compute/barrier cost is reported separately and improves CPU frame time at large horizons.
• Small workloads automatically retain the cheaper CPU path.
• No hierarchy holes, transition popping, indirect-buffer overflows, or one-frame stale draws.

Risks

Synchronization/barrier errors, indirect-count feature portability, delayed occlusion visibility, and atomic compaction contention. Mesh shaders are explicitly out of scope until conventional compute + MDI is proven insufficient.

[github-actions]

Thanks for the structured roadmap, Michael. A quick triage pass with the current code in hand:

Classification: Feature Request (Phase 3 of the LOD GPU roadmap; depends on the open tracker issues #921 Phase 0, #920 Phase 1, and #919 Phase 2, which gate the work above).

Current state worth noting (entry points already exist)

• modules/world-lod/src/lod_renderer.zig:144 already wires ZIGCRAFT_LOD_GPU_CULLING, and modules/world-lod/src/lod_renderer.zig:197-200 emits the "fallback until RHI exposes indirect-command compaction" warning - that warning is exactly what the first acceptance criterion is asking us to retire.
• assets/shaders/vulkan/culling.comp (frustum + occlusion-test compute; reads ChunkAABBs and writes visible_buffer.indices via an atomic counter) and assets/shaders/vulkan/depth_pyramid.comp (mip-chain max() reductions) already exist.
• DrawIndirectCommand and RHI.RenderContext.drawIndirect are wired end-to-end (modules/engine-rhi/src/rhi.zig:432, modules/engine-graphics/src/rhi_vulkan.zig:682, modules/engine-graphics/src/vulkan/rhi_draw_submission.zig:170), and the LOD renderer already emits per-LOD indirect command streams (modules/world-lod/src/lod_renderer.zig:284-310), so this phase is genuinely about moving the visibility + count compaction onto the GPU rather than introducing new draw plumbing.

Scope recommendation: split into 3 tracked sub-issues. The body already enumerates three independent workstreams; each is large enough for its own PR + review + measurement cycle and they touch disjoint code paths:

1. Data contract + RHI barriers / count-drawing - extend engine-rhi with compute-to-indirect barriers and a drawIndirectCount (or equivalent) entry, define the CompactRegion (bounds + LOD hierarchy + fade + coverage) and dual command-stream layouts (terrain vs water), and keep the CPU path selectable from a measured candidate threshold and supportsIndirectFirstInstance/feature checks. Land this without touching the culling shader; only the contract exists.
2. Compute visibility - run culling.comp against the per-frame CompactRegion buffer, write a visible-instance buffer and a compact indirect-command buffer, hook the new drawIndirect path in lod_renderer.zig (replacing modules/world-lod/src/lod_renderer.zig:279-310 CPU staging), preserve the "render parent until required children are ready" rule on the GPU side, add overflow bounds + validation mode that compares GPU visible count vs CPU reference, and gate the new path behind the measured candidate threshold from (1).
3. Optional occlusion - wire depth_pyramid.comp into the post-g-buffer pass and feed it into culling.comp (sampler2D depth_pyramid binding already declared) only after (1) + (2) are green and benchmarked, with temporal hysteresis plus a "disable when open terrain / low candidate count" runtime gate.

The "validation mode that compares GPU vs CPU reference" piece in (2) is the natural single-acceptance gate that lets us prove correctness without eyeballing terrain, and it dovetails with Phase 0 baselines from #921.

Sync / lifetime risks mentioned in the issue are real: a follow-up needs to make sure the new command/instance buffers participate in the same per-frame ring (the existing [rhi_types.MAX_FRAMES_IN_FLIGHT]BufferHandle slots in modules/world-lod/src/lod_renderer.zig:97-98) and that the depth pyramid read in culling.comp has the right compute-to-fragment + compute-to-compute barrier before sampling, otherwise we will regress #917/#922. Worth pulling that into a fourth sub-task once (1) lands.

Happy to open (1) as the first tracked sub-issue referencing #918 and #919 once Phase 2 (#919) is green, with (2) and (3) blocked on it.

[github-actions]

Comment posted: #918 (comment)

Summary: classified as Phase 3 Feature Request, noted the existing ZIGCRAFT_LOD_GPU_CULLING fallback warning in lod_renderer.zig:197-200 as the entry point to retire, pointed out that culling.comp / depth_pyramid.comp and RHI.RenderContext.drawIndirect are already in place, and recommended splitting into 3 tracked sub-issues (data contract/RHA barriers, compute visibility, optional occlusion) plus a follow-up sync/lifetime task blocked on Phase 2 #919.

opencode session  |  github run