popen's access mode was accidentally changed from string to enum used in
FileIO::open() wrappers. This is a posix function and should keep using
the string.
* The framebuffer is allowed to be a smaller size, the renderarea is what we
need to check to ensure we don't render outside the image with some stale
state.
* 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
* Debugging shaders with UAV access could(likely will) have side-effects on
those UAV contents, so when ContinueDebug needs to fetch UAV contents we
should replay back to before the draw to fetch them.
* This replay only happens once per ContinueDebug, and UAV contents are cached
globally so we only do it once per UAV that's accessed, so the impact is low.
* Previously we hinted loading both the old LunarG metalayer and the new
combined Khronos layer. Since only one was a 'real' layer this was safe and
would allow us to enable validation anywhere without needing to enumerate
available layers.
* Unfortunately a new loader version makes it an error to specify the
VK_LAYER_LUNARG_standard_validation for loading! So it is completely
impossible to be fully compatible. We have no choice then but to follow the
loader/SDK's path and have a hard backwards compatibility break.
* This means the validation won't be enabled anymore for anyone on SDK from
early 2019 and before.
* Normally SetEventID is synchronous and blocking, and will stall the UI while
it is processing. However we can at least pop up a progress dialog and allow
the UI to function (if not be interactive due to the blocking progress dialog)
when some other long-running task is delaying the processing on the replay
thread.
* 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).
* When we use the wholeMemBuf from a dedicated allocation it may actually be
smaller than the whole allocation, and we need to be careful not to overuse
it. Keep a separate size for wholeMemBuf which can shrink if the buffer is
smaller.
baldurk