* This avoids the problem where an application exits so fast on shutdown that we
don't have time to execute any cleanup functions to delete cached ASs.
* To avoid opening a huge number of file handles we also collate cached ASs into
batched files
* Although we intercept size queries to return the current size instead of
compacted size, this size can still leak out if a compacted AS is used as the
source of a subsequent update-build. Also in theory an application could just
compact then query the current size (possibly for defrag? though you'd expect
that size to be cached on the CPU from the original compact).
* We're probably crashing if this mode is enabled - try to avoid the crash.
Don't build or copy ASs, and don't dispatch rays. Still do all the patching
prep though.
* To remove ray query work, force-write all AS descriptors as NULL both with
dynamic writes and initial contents.
* Preallocate IDs for builds and pass via a new serialise sideband key-value
storage. It's ugly and warty but less ugly than trying to pack the data in
directly.
* Descriptor references to ASs may not be right as a descriptor could be written
before a build is even known about, or at least before it has fully resolved
on the CPU timeline.
* If the same AS is re-used for a new BLAS, consider the TLAS invalid/stale and
0 out its address. Similarly if a TLAS somehow ends up there (though it should
always fail the age check first)
* For ease of tracking this is simpler as there is currently no situation where
we need to know the providence of an AS and what ID it was before if it's
rebuilt in place with the same size (e.g. an in-place update). On the other
hand it is useful to know when an AS is a new build for potential TLAS
invalidation or lifetime checking.
* If BDA capture/replay is not supported we patched the feature query for the
vulkan 1.2 struct, but if an application used the promoted KHR extension
struct we weren't patching that because it was previously invalid to query on
the extension itself.
Jake Turner