* This means if there's no intervening list() it still works, e.g. passing an
rdcarray property to a function paramater that expects an rdcarray in python.
* These map more naturally to python tuples and are easier to wrap in and out.
* We also tidy up the FloatVecVal etc and standardise the members of
ShaderValue.
* Ideally we'd document every member unconditionally for best autocompletion,
but that's a lot of modification so for now we stick to just making sure that
any members that are struct types (or lists/tuples) have the :type:
declaration so that we can autocomplete inside them.
* Also added a script that can run as part of CI to verify that the docstring
matches, by generating a regex from the docstring documented parameter types
and return type and making sure we find a match within the C headers. This
ensures all parameters are documented with the right types, no extra
parameters are documented, and the return type is correct.
* The script also checks proper scoping so that if qrenderdoc docstrings
mention a renderdoc type, they need to scope it properly.
* This prevents unnecessary conversions back and forth between rdcstr and const
char * when going through interfaces. In the OS specific layer this is rarely
an issue because most of the implementations don't convert to rdcstr, but it
is convenient to be able to pass in an rdcstr directly. The few cases where
there's an unecessary construction of an rdcstr is acceptable.
* A couple of places in the public API need to return a string from a global
function, so can't return an rdcstr due to C ABI, so they still return a const
char *.
* Similarly const char * is kept for logging, to avoid a dependency on rdcstr
and because that's one place where unnecessary conversions/constructions may
be impactful.
* One automodule in a file for our modules is way too much, so we split it into
files. Unfortunately this means that only one file can have those classes and
functions be linkable from elsewhere.
* Instead we bite the bullet and manually curate the items into pages, and at
the same time subdivide the 'enums and data' page more which is a general
readability and usability win as well.
* We also add some previously not-included functions, and add a doc-build time
check to ensure that functions and classes aren't omitted from the
documentation in future
* If the last refcount on a python lambda/temp function is released when a
wrapping std::function is destroyed in a C++ invoke, we can't destroy it
safely. Instead we queue up that decref and process it the next chance we're
able (which is either when the current execution finishes for a python shell
execution, or on the next function call which handles extensions).
* This by no means replaces PySide2, but it allows python extensions to write
simple UIs without needing to rely on PySide2, which might not be available
(generally all windows builds have it as well as recent binary linux builds,
but local windows builds may not and most linux builds probably won't).
* This is a string type which heavily optimises for immutability and minimal
storage. It only contains one pointer to the string data and always
reallocates on modify. For compile-time literals it doesn't modify or
allocate.
* On x64 we use the top bit in a tagged pointer to store a flag of whether it's
heap or literal, on other platforms it uses a separate field (meaning another
pointer sized value effectively, including padding).
* This is best for structured data which tends to use a lot of immutable strings
for type/name information, and only a few for actual string data (which are
only allocated once and aren't modified after that). Similarly we rarely want
to know only the size of any of these strings, we want the whole string so not
explicitly storing the size is not a big deal.
* Overall this reduces SDObject from 128 bytes to 80 bytes.
* When the pyside2 we ship was built it accidentally included a small dependency
on Qt5Qml, which we don't distribute so the pyside2 libraries wouldn't load.
* We can generate a tiny stub with the right exports and load it manually from
the PySide2 folder on 32-bit qrenderdoc builds to allow pyside2 to load
subsequently. The stub source is tiny, and added alongside.
* Putting it in the PySide2 folder means that even if someone puts RenderDoc's
build folder in their PATH, our stub Qt5Qml won't break anything because it
won't be loaded. If they put PySide2 in the PATH it might, but then it's their
fault!
D3D12Pipe now stores an array of root elements, each one corresponding
to a root element or range in the root signature. Migrated usage in the
D3D12 pipeline state viewer and PipeState retrieval of resources.
Restricted number of resource array textures displayed in the texture
viewer to prevent app hangs.
* This allows persistent config storage and registering tweak variables that
works independent of the UI's configuration.
* Config vars can be debug only, which means they will be compiled out in stable
version releases. This allows for debug-logging tweaks that are available in
all builds (including nightly builds) for diagnostic purposes, but have zero
overhead in stable releases.
* Variables have a loose hierarchy defined with _ or . to separate nodes.
* The ShaderDebugTrace now only sets up the initial state of an opaque
ShaderDebugger handle.
* This handle can then be passed to a new function - ContinueDebug - to
iteratively return N more states. The number of states is implementation
defined and may be a fixed number or it may run for a fixed time.
* The states themselves no longer contain a complete snapshot of all variables,
but instead only the changed variables for that iteration. The changes are
stored as before and after value to make it easier to step forwards and
backwards (only the ShaderDebugState is needed to move forward or backwards,
you don't have to search back for the last set value of a variable to 'undo' a
change).
* Moving away from 'registers' explicitly being stored, we now have a single
variable array where the shader representation is responsible for allocating
it.
* In DXBC we calculate the number of each type of mutable variable (temps,
indexable temps, and outputs) and assign slots linearly.
* We also update some naming - high-level variables aren't "locals" since they
could be globals too, and debugging variables aren't "registers" but simply
the variables we use for debugging which may be more complex than float4 for
other APIs.
* The local variable matching by string name is unnecessary for this change
but will be more useful in future after further refactors where there isn't
a single list of variables to index into at the upper level.
baldurk