* This was variably sized so in practice we didn't use it, but the spec still
requires us to respect the max sizes that could be used for the upper bound
and this lead to the wrong texture being sampled on NV.
* MS has deleted vbscript because breaking things is fun, so we use jscript
instead to do the weird replace of '#' so that numbers read from the registry
can be compared to numbers
* On a new enough dxc we can pass a flag to tell it to ignore dxil.dll
* This allows the tests to run on the test machine with an old windows SDK
(where the demos project copies the dxcompiler.dll + dxil.dll from) but still
pull in a new dxcompiler.dll without having it break on an old dxil.dll
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
* This requires setting vmaBDA to true, which is opt-in as it applies
universally to all memory allocations in the test. We don't know if there are
driver impacts from enabling BDA and it may also mess with our tests.
* Apparently the spec allows drivers to do extremely stupid things with
swapchain images and return them even when it's not valid for you to use them
yet because last frame's work to the image is still ongoing, which leads to a
validation warning about using a semaphore when it might technically still be
in flight.
* To get around this because AcquireNextImage doesn't actually block until an
image is ready inspite of having a timeout and being expected to return a
usable image it doesn't, we use a manual fence to do what AcquireNextImage
should be doing.
Do not pixel debug on an unknown primitive ID (-1)
Allow pixel debug and vertex debug on non-drawcall actions which have non-zero drawIndex i.e. Indirect draws