ShaderDirectAccess is used to reference resources which are accessed directly from the Shader (not via a direct binding). Shader resource references using direct binding are stored in ShaderBindIndex.
* We keep parent references when returning child objects via reference/python
object wrappers rather than copying. But when iterating a linked list like the
actions this can produce an incredibly long parent chain and then on
destruction we can stack overflow if the chain is long enough.
For the future display any unknown global shader flags as hex value
Make sure the DXIL debugger line numbers match the disassembly output if there are unknown global shader flags
* 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.
Jake Turner