* 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.
This test renders a small triangle that casts a shadow from a point light, onto a larger triangle. The test runner then checks that various pixels in the final output are the correct colour.
There is also an arbitrary AS copy in the render loop just to hit more API coverage when manually capturing, but the test runner doesn't check its output.
Core test work originally done by martyn.jacques@arm.com
* As the aftermath headers can't be distributed currently this requires putting
those headers in the right place. Then the resulting build can load the
aftermath dll if it exists in the plugins folder.
baldurk