[Intel Arc B580] No LOD rendering: reverse-Z depthBoundingBuffer remains all zero

Summary

On an Intel Arc B580, Voxy generates and persists LOD data and produces non-zero MDIC draw commands, but no LOD terrain is visible. GPU readback shows that Voxy's reverse-Z depthBoundingBuffer can remain entirely 0.0; the fragment shader then discards effectively every LOD fragment.

Reported by @FFDVDGD.

This is a complete non-rendering issue, not the Arc performance problem tracked in #333. It is closer in symptom to #301, but this report includes a reproducible framebuffer/depth-buffer diagnosis on current 26.2 versions.

Environment

• OS: Windows 11, build 10.0.26200
• GPU: Intel Arc B580
• Driver: Intel 32.0.101.8974 (2026-08-11 WHQL)
• Minecraft: 26.2
• Fabric Loader: 0.19.3
• Voxy: 0.2.18-beta
• Sodium: 0.9.1
• LSS: 0.12.0
• Iris: not installed
• Vanilla render distance: 2 chunks (Voxy logs the known warning about possible rare edge culling; the observed failure is total LOD non-rendering)
• Pipeline reported by Voxy: NormalRenderPipeline / MDICSectionRenderer

RTSS was stopped and the client restarted for an A/B test; the failure was unchanged.

Observed behavior

• No terrain is rendered beyond vanilla render distance.
• LSS source data is present around the player and Voxy's database grows while ingesting.
• Voxy debug statistics and indirect draw commands are non-zero.
• Disconnecting/rejoining, which rebuilds VoxyRenderSystem, reproduces the failure.
• A one-time GL/FBO state reset can make rendering recover briefly, but later frames or renderer recreation fail again.

GPU readback from a failing frame

Render properties:

RenderProperties[isZero2One=true, isReverseZ=true, useBlockAtlasUVs=false]

At 1920x991 (1,902,720 pixels):

colourTex:          nonBlack=0, nonZeroAlpha=0
colourSSAOTex:      nonBlack=0, nonZeroAlpha=0
depthTex:           zero=1902720, one=0, middle=0
depthBoundingTex:   zero=1902720, one=0, middle=0
opaqueDrawCount:    41439
translucentCount:   5830

The first sampled indirect commands were valid and non-zero, for example:

count=198 instances=1 baseVertex=75710464 baseInstance=97
count=270 instances=1 baseVertex=75711612 baseInstance=97
count=246 instances=1 baseVertex=86887316 baseInstance=102

All relevant FBO objects still existed, had the expected texture attachments, and reported GL_FRAMEBUFFER_COMPLETE (36053):

bounds:   exists=true status=36053 attachmentName=712 error=0
pipeline: exists=true status=36053 attachmentName=740 error=0
ssao:     exists=true status=36053 attachmentName=742 error=0

Calling Voxy's DepthFramebuffer.clear(1.0f) on the render thread returned no GL error, but immediate texture readback still contained 1,902,720 zeroes and no ones.

For comparison, during a transient working period the same probe reported:

depthBoundingTex: zero=0, one=621894, middle=1280826
colourTex: nonBlack=1321700

Why this rejects every LOD fragment

With reverse-Z, Voxy defines:

#define DEPTH_SCALAR_COMPARE(a,b) ((a)>(b))

quads.frag contains:

if (DEPTH_SCALAR_COMPARE(gl_FragCoord.z,
        texelFetch(depthTex, ivec2(gl_FragCoord.xy), 0).r)) {
    discard;
    return;
}

When the complete bounding texture is 0.0, practically every visible fragment has gl_FragCoord.z > 0.0 and is discarded before writing color.

Workaround confirming the failing condition

Changing only the condition in assets/voxy/shaders/lod/gl46/quads.frag restores visible distant terrain:

-if (DEPTH_SCALAR_COMPARE(gl_FragCoord.z, texelFetch(depthTex, ivec2(gl_FragCoord.xy), 0).r)) {
+if (false && DEPTH_SCALAR_COMPARE(gl_FragCoord.z, texelFetch(depthTex, ivec2(gl_FragCoord.xy), 0).r)) {

After restarting with that workaround, distant mountains, forests, coastline, and water rendered beyond the 2-chunk vanilla distance. No obvious near-terrain overlap or corruption was visible during the test.

Expected behavior

depthBoundingBuffer should be cleared/populated with the correct reverse-Z values. If the bounding pass cannot produce a valid texture, the terrain shader should fail open rather than treating an all-zero texture as a mask that rejects every LOD fragment.

Notes

No driver change was made during testing. The evidence establishes the immediate failure mechanism, but does not establish whether the underlying state fault belongs to the Intel OpenGL driver, Voxy, or its interaction with Sodium 0.9.1.

Start by reproducing the failing framebuffer readback on the Intel Arc B580, then inspect assets/voxy/shaders/lod/gl46/quads.frag and the code around DepthFramebuffer.clear(1.0f). Trace the NormalRenderPipeline and MDICSectionRenderer bounding-pass state to determine why depthBoundingTex remains zero. Done means LOD terrain renders without the workaround and the reverse-Z depth bounding texture is correctly populated.