* This causes a full rebuild in VS because the command line has changed
every time you commit or checkout in git (because the git commit
/D parameter has changed).
* Since we only need it in UI-facing projects we remove it from
every project except qrenderdoc, core renderdoc, and renderdoccmd.
They will still rebuild when the commit changes but technically VS is
right to do so.
* There's weird behaviour seen where after binding a descriptor set with
an offset, subsequent work in other command buffers doesn't behave
correctly. Re-binding the descriptor set with a 0 offset seems to fix
it, so I assume the offset is leaking and applying to subsequent
binds that don't have any dynamic offsets.
* Instead we write transparent black when out of bounds. This only works
when we're blending, but the cases that we don't blend are when we do
a blit to a precisely sized output target with no offset, so it
shouldn't cause a problem.
* Mostly used for passing a progress float back during a long blocking
call like opening a capture or doing a copy.
* This is much more feasible for python to bind to.
* In several cases we just use a tiny lambda that updates a float anyway
since we can't push the progress directly into a progress dialog, but
need to let it query from a temporary in-between float.
* We track the progress through making a capture as well as the progress
we already tracked loading a capture.
* Also incidentally fix a copy-paste bug that was calculating the wrong
progress for loading captures by applying FileInitialRead instead of
FrameEventsRead for the frame replay.
* We also let an API be active without presenting, and then note when it
starts presenting. This lets us detect the case where an API has been
started up and used, but isn't presenting so we're not able to capture
it. Less confusing than telling the user no API is detected, and lets
us direct them to the relevant documentation.
* There's also a flag indicating if the API can be captured even if it
does present.
* Currently we only have structured data for the CPU-side calls, but we
want to display the information for the individual selectable GPU-side
commands.
* So we add a new fake virtual chunk and insert it with data pulled from
the GPU information, and any meta-data like the offset of that
command.
* This means the command buffer begin/end won't just be a fake chunk
with the queue submission API details, it will point to the actual
begin or end chunk.
baldurk