* The exact contents depend on the API - on D3D11 this is the bytecode
blob, on Vulkan it's the SPIR-V. On OpenGL it is just a concatenation
of all the source files passed in sequence.
* If there's no replay context we can still use the live connection to
copy and delete captures remotely. Try to use that whenever possible
and warn the user when it's not possible (i.e if the program has been
closed and there's no replay context, we have no way to access the
files anymore).
* If the user tries to open a remote log without a replay context,
prompt them either to swithc to a replay context on that host or to
save the log locally.
* In GL although the ARB_dsa extension allows binding of cubemap faces
as if they were a 2D array (you know, the sane way), it doesn't let
the queries return the cubemap face to the LAYER query. Instead it
needs a separate query of CUBE_MAP_FACE.
* This is similar to the button on the capture dialog of the windows UI,
except on linux the situation is a bit more complex as layers can be
registered in two different system locations (one for distro packages
and one for non-distro stuff), as well as in $HOME.
* On linux we make sure the json always contains an absolute path so we
can tell from any given build whether or not a json is our own or not.
* By default we now install the json to /etc since /usr is reserved for
proper distro packages, and shouldn't be written to by 'make install'.
There's a CMake variable for overriding this for anyone who wants to
make install into a custom folder (maybe for packaging).
* It seems like actually ppSOTargets can only be NULL if NumBuffers is
0, but the D3D runtime will happily accept a null pOffsets and just
act as if it's full of -1 (which means append)
* This suppresses lines like "RenderDoc v0.31 x64 (...) loaded in replay
application" which are only useful for the logfile and not for actual
user output.
* When transferring over the network, we keep texture data consistently
in GL origin-bottom-left order. This means we can just flip images on
display and otherwise have things consistently behaving, while still
preserving the behaviour of flipping on saving to disk to try and
mostly 'do the right thing' when saving an image.
* The behaviour should be the same as before except for remote proxying
which is fixed. The behaviour for GL is still that compressed images
saved as compressed will appear to flip vertically from what is
natively displayed in the UI, but I think this is the only sensible
way to behave (and anyway, flipping compressed images is far too
involved to be worthwhile).
* This was copy-pasted from windows where unfortunately the nfds
argument is ignored and we could get away with just passing 0 (which
I suspect is where the broken code came from originally - a windows
example code that passed 0)
Fixes glXCreateWindow returning "BadMatch (invalid parameter attributes)".
Also delete the GLX_ALPHA_SIZE=8 criteria, else there might not be any
matching config.
* If the AMD extensions are active and captured, the driver will crash
on replay in a hard to diagnose way (unless you know what's really
wrong!)
* With this change, the target application should see the extensions
failing to create and gracefully fallback to not using them.
* Also allow disabling GL a little better by removing the dependency in
renderdoccmd.
* Disabling them now completely removes all xcb and xlib build
dependencies. The resulting library/executable is only useful in
limited situations - e.g. replaying vulkan remotely which doesn't need
any window system interaction. Or capturing vulkan as well with the
KHR_display WSI extension which doesn't need any built-time includes
or libs.
* This lets us detect when a remote server has been disconnected and
needs to be restarted, as well as alerting the user if this happens in
the middle of a replay session.
* Pinging other hosts means the context switcher is reasonably up to
date if one of them comes up.
* The compression bound was just a hacked 'uncompressed size + 512'
which might not be enough for true worst case.
* Worse, the serialisation was transferring size_ts so it would break if
proxying between 32-bit and 64-bit executables.
* If the machine idents differ in significant ways that we'd consider
it to be a different platform (currently just OS), and if so mark it
as supported but suggested to be replayed remotely.
* This can be used to determine what kind of machine a capture came from
and potentially decide to alert the user and suggest replaying on that
kind of machine if it's very different.
baldurk