Device lost error after building a BLAS with more than 852 AABBs

Hi,

After building a single BLAS with 853 AABBs, an unrelated vulkan call fails with ERROR_DEVICE_LOST.
Same BLAS with 852 AABBs work fine.

I am using the vulkan beta driver version 457.96 for Windows.

Is there a known issue concerning a limitation in BLAS concerning the number of AABBs it can contain.

I am using the acceleration structure in a fragment shader to do ray query (see Ray Tracing In Vulkan - The Khronos Group Inc). The main difference between my code and the example in the blog is that I use AABBs for the geometry instead of triangles.

If I comment out the while (rayQueryProceedEXT(rayQuery)) loop in the fragment shader then the Device lost error is not reproducible anymore (but no more RT shadows for me…).

That 852 threshold looks very specific and very small. Could be a problem on my side when building the TLAS and single BLAS but I don’t know where to look.
I double checked the TLAS/BLAS creating and building code. Added some very long sleeps() to rule out synchronization issues (the TLAS/BLAS are constructed once at startup and are not later updated).

I used Nsight graphics to take a closer look at the TLAS/BLAS but did not see anything obvious.
One strange thing: I get the same Device lost error when starting the application via Nsight, but the threshold at which it appears is lower than 852 (I need to find the exact value that will trigger the error).
But with 400 AABBs I am able to start the app under Nsight.

I did see some issues with Nsight itself concerning visualization of acceleration structures but nothing blocking.
See Acceleration Structure viewer ignores AABB buffer offsets.

Problem was on my side.

I was specifying the ALLOW_UPDATE flag when getting the build sizes but not when actually building.
Surprisingly, ALLOW_UPDATE has an influence on the build scratch size and acceleration structure size.

With ALLOW_UPDATE:

  • acceleration structure size: 814 848
  • build scratch size: 1 180 032
  • update scratch size: 524 544

Without ALLOW_UPDATE:

  • acceleration structure size: 623 616
  • build scratch size: 1 248 384
  • update scratch size: 0

I’ll check with the Vulkan SDK developpers if it is possible to detect this situation in the vulkan validation layer.