Catcrafts/Crafter.Graphics
Watch
2
0
Fork
You've already forked Crafter.Graphics
 0
Code Issues 8 Pull requests Projects Releases Packages Wiki Activity Actions

docs: where the NVIDIA descriptor-heap faults stand on 615.78.08

Browse source 
The heap acceleration-structure read still needs the rewrite on
615.78.08; the READMEs say so and point at HeapASRead --no-workaround
for checking a newer driver. Dynamic descriptor indexing in hit shaders
is fixed there, which the README and the Sponza and SponzaBench notes
now say, and the VulkanTriangle investigation no longer contradicts
itself about llvmpipe, which advertises VK_EXT_descriptor_heap now.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
Jorijn van der Graaf 2026-10-19 03:03:17 +02:00
commit 449d5da553
Signed by: jorijnvdgraaf
GPG key ID: 2937E59CDCC1BCFB
4 changed files with 36 additions and 13 deletions
Download patch file Download diff file Expand all files Collapse all files

18
examples/VulkanTriangle/README.md
View file

@ -58,6 +58,17 @@ every other driver the workaround is inert. It's gated on
`interfaces/Crafter.Graphics-ShaderVulkan.cppm` so it can be deleted wholesale
once a fixed NVIDIA driver ships.
### Status on later drivers
On `615.78.08` the fault is still there. With the rewrite off
(`CRAFTER_GRAPHICS_NO_AS_WORKAROUND` set), `traceRayEXT` still loses the device,
and an inline ray query that reads the TLAS from the heap no longer faults but
renders nothing. Mesa's llvmpipe now advertises `VK_EXT_descriptor_heap` too
and renders the plain heap read correctly, which is a second implementation
backing the conclusion below. `tests/HeapASRead` renders this triangle through
both paths and checks the pixels; `HeapASRead --no-workaround` is the quick
check for a new driver, reporting each path on its own.
### The underlying fault (#7)
The fault was traced to the **acceleration-structure read through
@ -83,9 +94,10 @@ The fault was traced to the **acceleration-structure read through
- The fault reproduces even with the AS descriptor written at heap byte 0
and read at shader index 0 (no descriptor offset/stride ambiguity), and
is unaffected by the `pAddressRange` size.
- `VK_EXT_descriptor_heap` is brand new; on this machine NVIDIA is the only
implementation that advertises it (llvmpipe does not), so there is no
second conformant implementation to cross-check against.
- `VK_EXT_descriptor_heap` is brand new; at the time NVIDIA was the only
implementation on this machine that advertised it (llvmpipe did not), so
there was no second conformant implementation to cross-check against.
Mesa's llvmpipe has it now; see "Status on later drivers" above.
**Conclusion:** this is a driver-side fault in NVIDIA's
`VK_EXT_descriptor_heap` acceleration-structure path, not an engine bug, and