* The enums are given after compute, to preserve indices for the normal vertex
pipeline.
* Mesh dispatches are considered a new action type, rather than being bundled
into the `Drawcall` type. This will allow them to be distinguished by API
backends as needed. The UI treats them as drawcalls
* We apply this universally even though it's not relevant to D3D11/GL. It means
a couple of empty array entries but it should not cause any significant
issues.
* Shader messages will be identified by group and thread as with compute
shaders. For mesh shaders there is an additional subdivision to identify them
by task group, since each task group can submit a grid of mesh groups.
* When used in richcompare this would throw an exception and return
Py_NotImplemented causing a failure. Instead we should just return NULL, which
is fine and will be considered as a not-equal comparison for
equality/inequality and throw the kind of exception we want for less than or
greater than.
* We store the compiler used (when known) in shader debug info and use that to
select the compiler for editing as even higher priority than the default for a
given language/encoding combination.
* We also ensure that for known tools we add the input and output parameters
last, after any custom parameters, so that they are always present regardless
of what the user puts in.
* Since the source vars data doesn't change for a given instruction, we can pre-
calculate it and save time on re-calculating per-state.
* Note callstack *can* change per-state on SPIR-V where the same instruction can
be reached by different flow paths, so the callstack remains part of the per-
state data.
3rdParty source files and some renderdoc files which include 3rdparty header files
Disable "-Wshorten-64-to-32" for the whole of qrenderdoc render_python.cxx triggers the warning
3rdParty source files and some renderdoc files which include 3rdparty header files
Disable "-Wshadow" for the whole of qrenderdoc render_python.cxx triggers the warning
* Most of the main entry points that can fail with relevant reasons now has a
way of specifying a message to return with it. This message can be displayed
to the user to give more information or context about an error.
* Newly written shaders and any updated shaders can now use pre-defined macros
to abstract away binding differences between APIs, so custom shaders will be
more portable in particular shaders written in HLSL for D3D or GLSL on OpenGL
won't break on vulkan because they refer to incorrect binds.
* There's not a good accepted terminology for this kind of event, and for
historical reasons 'drawcall' has been the accepted term, even though
that can be quite confusing when a dispatch or a copy is a 'drawcall'.
* This is particularly highlighted by the event browser filters where
$draw() includes draws and dispatches, but $dispatch() only includes
dispatches, it's hard to intuitively understand why $draw() matches all
of these calls.
* As a result we've defined the term 'action' to cover these types of
events in the same way that we defined 'event' in the first place to
mean a single atomic API call.
* This in particular means push constants and specialization constants on vulkan
but also applies to root-value cbuffers on D3D12.
* GL bare uniforms are not feasible to expose in this way.
It was previously marked as disabled for Apple
Required to build the python modules which are used by the testing framework
Python imports .so libraries by default, change the shared library extension to .so for python modules on Apple
* 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).
baldurk