* 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.
* The main addition here apart from some extra stubs is a new rdc type
for date time objects.
* Although the module doesn't do anything and is only used for docs
reflection it is desirable to not have to link against Qt as this
can cause problems when linking the module without unresolved symbols.
Images[i].res.namespace was left set to eResUnknown, causing the image
not to be found in GLResourceManager::GetID when populating the
renderstate view. This would result in images being incorrectly shown as
unbound.
The offset argument to FlushMapped[Named]BufferRange was being treated
as relative to the start of the buffer, rather than
relative to the mapped range.
During a capture, if a buffer was mapped for write with a non-zero
offset using Map[Named]BufferRange, the offset wouldn't be taken into
account when using the shadow buffer.
* These .py wrappers are relevant for the non-builtin path, but since we
use -builtin they serve no purpose except to make things more complex.
* So instead we make the module directly exported as 'module' instead of
'_module'.
* On windows there's no conflict because we have renderdoc.dll vs
renderdoc.pyd. On linux it's librenderdoc.so vs renderdoc.so.
* To prevent supporting files like .lib / .pdb from conflicting on
windows we build the python modules into a subdirectory. They're not
ever used by the UI (it links in the bindings directly).
* This prevents issues where perhaps some file that is compiled in
references a symbol in another file which is not compiled or isn't
enabled, leaving an undefined symbol in librenderdoc.so. This can
lead to some seriously hard to track bugs.
* This way it's uniformly supported, so e.g. we can still get it when
the replay itself is running on android.
* To do this we just pass the 'raw' bytes, which contains the whole blob
needed for disassembly. This means a little extra work to disassemble
D3D blobs by doing a tiny parse of the DXBC.
baldurk