* 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.
* We don't consider anything else, this includes permissions or the
library being present. Since we no longer expect to patch in the
library we also don't check its version (however we leave the tag in
case it is useful in the future).
* If the user has root access we will never warn, assuming the injection
will work fine even without the debuggable flag.
* Initially add support for spirv-cross and spirv-dis.
* When possible we'll auto-detect the tools in path or in the build's
plugins folder. Otherwise the user can add it and add their
executable path.
* We still use the first disassembler for editing - in future it would
be good to allow selecting the disassembler at edit time (as well
as allowing multiple compilers).
* We search first in specified folders by the user (they can browse to
the android SDK and java JDK).
* If the tools we want aren't found there, we look relative to the UI
as we now distribute the required tools with windows builds.
* If we still don't find them, we prefer to look in PATH since the user
has 'opted in' to any tools found in there. If the tool isn't in PATH
either then we look relative to known environment variables.
* This is to support python bindings - the pyside implementation of
QVector, QString, etc is not available to SWIG, so SWIG treates these
all as opaque types.
* Rather than trying to set up bindings that work for rdcarray and
QList/QVector, or implementing separate bindings, we instead just say
that the public interface must use the rdc types. In most cases they
seamlessly convert to/from Qt types anyway.
* In a couple of places we use an array of pairs instead of a map. In
future we probably want an rdcdict or rdcmap with proper dict bindings
in python.
* This is a leftover from before the interface was hoisted out, and most
windows were still calling directly to CaptureContext instead of via
the public ICaptureContext interface
* In future one of the notes items would be for gathered hardware info.
Not automatically, but with one button press the full configuration
can be embedded.
During initial scan of application, detect if root access is available
and track it. If user later selects "Click here for ways to fix this".
display a new dialogue that offers to push the layer directly.
If pushing fails, fall back to production dialogue.
Also add a new persistent setting to enable automatic layer pushing.
* Added a couple of utility macros to help with the conversion. lit() is
paired with tr() for untranslated text.
* QFormatStr is more explicitly for non-textual formatting strings.
* Both are just #define'd to QStringLiteral()
* Note, this API is still in-flux and beta, so there may still be some
more changes before it's 'stable', and even then it will still be
subject to some amount of change.
* This API is then exposed to python via SWIG bindings and hides
internals that don't need to be visible, and means the actual API is
easier to work with.
* We also use this API to reduce inter-dependencies between different
windows that need to interact with each other at a high level.
* The naming is python/standard RenderDoc TitleCase method names, not
Qt style camelCase methods.
# Conflicts:
# qrenderdoc/Windows/PipelineState/D3D11PipelineStateViewer.cpp
# qrenderdoc/Windows/TextureViewer.cpp
baldurk