* We still use derivatives to fetch the input values for the quad when
debugging, but we do it on the shader side and read back the raw inputs rather
than input+derivatives
* These are the API-side helpers. One makes it easy to declare and add a
new buffer for output, handling BDA (KHR and EXT) and plain bindings
if needed.
* Another is a helper for "grab current state, substitute in a
shader's SPIR-V, ready to do a single draw/dispatch"
* This is a temporary duplication of PatchReservedDescriptors to make a
refactoring easier with smaller commits, and is mostly identical but returns
its data in a struct instead of as loose outputs.
* These both automate some common (and verbose) tasks and also add extra helpers
for declaring a new output buffer that might come via BDA or via a binding.
Setting QT_QPA_PLATFORM with putenv from a local variable
causes the environment to later still refer to it when it's out of scope.
Use setenv instead, as it copies the values provided.
When mutable descriptor sets are used, Fossizlie needs the
VkMutableDescriptorSetCreateInfoEXT. However, instead of taking it raw
like some other inputs, it uses a simplified version that is just a list
of lists. If we give it full structs, Fossilize will crash. In order to
do this, we need a couple special cases.
* Set sType for query-return structures.
* Ignore pass boundaries to not mix queries inside and outside of renderpass
boundaries.
* Wait for idle before fetching KHR results (don't think it should be necessary
with VK_QUERY_RESULT_WAIT_BIT but validation expects it).
* 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.
* Previously when replaying we'd always use our d3dcompiler_47.dll that we ship,
but during capture we would always prioritise re-using an existing d3dcompiler
that the process already had.
* Since it should be safe to have multiple (differently named) d3dcompiler's in
the same process and we want to avoid using an old out of date d3dcompiler if
possible, we prioritise loading a new d3dcompiler_47.dll over re-using an
existing in-process d3dcompiler_43.dll
baldurk