MeshDecompressStagingRelease test fails on master: deletionQueue.size() != 1 after compressed Build #110

New issue

Closed

opened 2026-06-17 19:50:31 +02:00 by catbot · 0 comments

catbot commented

2026-06-17 19:50:31 +02:00

Member

crafter-build test MeshDecompressStagingRelease fails deterministically on current master (HEAD 2c8a293, the #67/#106 merge), independent of any feature branch — reproduced after git stash on a clean tree.

Two checks fail, both rooted in the same symptom:

FAIL  exactly one allocation (the staging) handed to the deletion queue
FAIL  staging is NOT freed before framesInFlight frames have elapsed

The test (tests/MeshDecompressStagingRelease/main.cpp:154) asserts Device::deletionQueue.size() == 1 immediately after mesh.Build(asset, cmd) on the GPU decompress path — i.e. exactly the compressed staging buffer should have been handed to the fence-keyed deletion queue. On this RTX 4090 + validation-layer run the queue does not hold exactly one entry, so the later "not freed before framesInFlight" check (which re-asserts size == 1 after a frame-0 ReclaimDeletions()) also fails.

This is GPU-path only (the codec is present here), so it likely wasn't caught on a CPU-decode-fallback CI. Either the #67 staging-release path enqueues a different number of deferred deletions than the test expects, or the BLAS build on this path enqueues an extra deferred allocation the test doesn't account for.

Surfaced while working on #75 (TLAS metadata buffer BAR upgrade); that change is unrelated (touches only RenderingElement3D) and its own tests pass. Filing so the master regression is tracked rather than silently rolled into an unrelated PR.

`crafter-build test MeshDecompressStagingRelease` fails deterministically on current `master` (HEAD `2c8a293`, the #67/#106 merge), independent of any feature branch — reproduced after `git stash` on a clean tree. Two checks fail, both rooted in the same symptom: ``` FAIL exactly one allocation (the staging) handed to the deletion queue FAIL staging is NOT freed before framesInFlight frames have elapsed ``` The test (`tests/MeshDecompressStagingRelease/main.cpp:154`) asserts `Device::deletionQueue.size() == 1` immediately after `mesh.Build(asset, cmd)` on the GPU decompress path — i.e. exactly the compressed staging buffer should have been handed to the fence-keyed deletion queue. On this RTX 4090 + validation-layer run the queue does not hold exactly one entry, so the later "not freed before framesInFlight" check (which re-asserts size == 1 after a frame-0 `ReclaimDeletions()`) also fails. This is GPU-path only (the codec is present here), so it likely wasn't caught on a CPU-decode-fallback CI. Either the #67 staging-release path enqueues a different number of deferred deletions than the test expects, or the BLAS build on this path enqueues an extra deferred allocation the test doesn't account for. Surfaced while working on #75 (TLAS metadata buffer BAR upgrade); that change is unrelated (touches only `RenderingElement3D`) and its own tests pass. Filing so the master regression is tracked rather than silently rolled into an unrelated PR.

catbot referenced this issue

2026-06-17 19:50:50 +02:00

perf(rt): allocate TLAS metadata buffer in BAR/VRAM, not system RAM (#75) #111