At this point we don't have Intel GL counters. But the current logic
assumes there is only AMD ones (and that if it's not AMD's, it must be
the generic ones).
* For pipelines using tessellation or containing a geometry shader we use
transform feedback to fetch the output of the vertex pipeline after these
stages.
* This self-insertion has the same kind of problem as overlapping ranges in
memcpy, the act of inserting items can affect the input range by shifting
things around. For inserting a single object we just copy it, for inserting a
range we duplicate the whole array and then do the insert from the old range
(and destruct it).
* Clearly this is not the most efficient implementation, a better solution would
be to append onto the existing array (potentially not even reallocating then)
and doing a rotate/shift in place.
A new button is added to the UI so that we can cycle the currently active window when there are more windows to capture. It's like pressing the F11 button but it works on Android too.
* This means SWIG generates a copy constructor which is very useful for making
duplicate objects in python. Without an explicit 'default copy constructor'
statement, SWIG doesn't generate one.
* Instead of just configuring SPIR-V disassemblers and picking only the first
one when we need to edit SPIR-V, we allow setting up any shader processor that
goes between two shader encodings.
* When editing, the default will still be to use embedded source, and then after
that the first tool that goes from the native shader format to a text format,
but the drop-down allows you to pick any of them.
* Similarly in the shader viewer you can configure the compilation options and
method, to choose the compiler you want to use. Embedded command line
parameters in the shader are automatically appended.
* This means e.g. the D3D11 back-end can accept DXBC directly if the UI can
provide it, or compile from HLSL as before.
* More importantly, the Vulkan back-end can take SPIR-V compiled from any
source, or compile from GLSL as before as a fall-back.
* This will allow the backend to specify both the native format (e.g. SPIR-V,
DXBC) as well as a language it might be able to internally compile (GLSL or
HLSL).
* The caller will then able to decide for itself whether it wants to compile to
native format and pass that down, or pass the language down and let it be
built internally.
* Currently BuildTargetShader still only accepts shader source.
* The new function SetCaptureFileComments allows users to add comments to a
capture after creating it at any time.
* We also use anonymous union to remove the need to duplicate API structs for
backwards compatibility.
* This has some possible problems - e.g. if one copy of qrenderdoc is closed and
kills the server used by another copy. However it seems impossible to reliably
manage adb and we need to ensure we don't leave the process lingering around.
* At the moment 95% of users don't use android, so it's most important that they
have a smooth experience.
* This was the cause of problems around updating versions because adb.exe would
hang around and then be 'in use' and not able to be overwritten.
* Instead of having an N:N mapping of parts of variables to parts of registers,
instead we gather everything together under each variable and it has a list of
registers that comprise it.
* Any gaps are represented as undefined register mappings, for components that
aren't available in any register.
* This measure the number of samples that pass the depth/stencil tests -
In the case of early tests, this means it doesn't account for shader discard before writing.
* This option has always been a mixed bag - when originally written captures
weren't compressed at all so saving the cost of a initial contents on a
gbuffer would have a significant savings.
* Now with compression the savings are lesser, and it's a source of
bugs/confusion for the case where either a bug is caused by leaking data from
the previous frame or worse still the contents are discarded incorrectly.
* D3D11 will now behave as the other APIs will - saving initial contents
whenever needed even if they seem like they might not be used.
* If we make WindowingData an empty struct not an opaque one, it won't leak memory
* Similarly we need typemaps to allow python to pass plain ints and have them cast to pointers
