* We keep parent references when returning child objects via reference/python
object wrappers rather than copying. But when iterating a linked list like the
actions this can produce an incredibly long parent chain and then on
destruction we can stack overflow if the chain is long enough.
* These are temporarily given separate names, to allow them to exist in parallel
with the existing helpers, but in future these will be renamed when the older
helpers are removed.
* This is a consideration for any cases where binding numbers are relevant -
primarily D3D11 and GL - where the offset into an arbitrary (and possibly
fake) descriptor storage is not helpful but knowing the register binding
definitely is.
* If someone wants to look at the raw descriptor contents without respect to a
particular shader access they can use this query to determine a more useful
'name' for any given descriptor. On D3D11 and GL this gives the register
number, on Vulkan it gives the binding number (and array element). On D3D12 it
just repeats the offset effectively.
* Baking these into descriptors when we get arbitrary 'GetDescriptor' queries
independent of the bound descriptor sets is not possible - a descriptor set
could be in theory bound twice to two places with different dynamic offsets.
* Instead we report these as part of the pipeline states and the abstraction &
replay API consumer will need to manually apply them to get the true buffer
offset.
* The offsets are indexed by descriptor storage byte offset for easier
processing (the dynamic offset struct can be turned into a pair and used to
initialise a dict)
* 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.
* 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.
* 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.
* 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.
* 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
* 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.
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.
* 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.
* This is only lightly tested and may break heavily. It is disabled by default
and must be explicitly enabled.
* In particular this is only known to work for Wayland use at capture time.
Wayland on replay is still unsupported. Known issues include: EGL pbuffer
surfaces are not implemented on Wayland, Wayland cannot get window dimensions,
and there are hangs/failures with GL and vulkan presentation with Wayland.
baldurk