* This is possible on D3D11 but only with certain cap bits, it's simpler to test
on D3D12 and the DXBC debugger will go through the same path for both.
* In heavy D3D11 workloads the refcounting overhead especially during fast
binding changes was significant. Refactoring the refcounting to work on a
different model and deferring destruction of objects removes most of the
overhead.
* This helps catches cases where a discarded image is accidentally used and in
many cases may still have valid data. Particularly on Vulkan this is relevant
for DONT_CARE renderpass load and store ops.
When getting read only resources from the pipe state, stitch back up
according to the bindpoint mappings. When displaying resources in UI,
don't traverse unbounded arrays. Fix resource swizzle on load/sample/
gather instructions, which happens on fetch result, not on the source
operand. Added more tests for unbounded arrays and different ways to
index into arrays.
* It's not particularly scalable and can be brittle to driver changes, and we
can use targeted specific pixel tests to check what we really want - to see if
the output has rendered correctly.
* Overlay tests still check files directly - this is a future refactor to
remove.
D3D11 may default to a different adapter than D3D12. For the sharing
test, both adapters must be D3D12 compatible. Tell D3D11 to use the
adapter that D3D12 is using to ensure compatibility.
Also fixed a memory leak in the test.
On laptops with integrated+discrete adapters, adapter 0 may not
support D3D12, so a default create device call will fail. Adapters
other than the 0th one need to be specified explicitly.
* Instead of only doing a very lightweight check to see if the API is available
up-front, we now share the API initialisation among all API tests far enough
to determine availability of extensions, features, etc. Then we can precisely
determine which tests are available and which aren't before running.
* If we create in a bare pointer then just cast to a smart pointer, it adds a
ref instead of stealing it. Just only allow creating smart pointers in the
first place.
* Built entirely independently of the main renderdoc build (for now).
* Contains python scripts & framework for running tests on a renderdoc build,
which will be run nightly.
baldurk