* This is a deliberate break of compatibility since the field is now often
empty, for non-markers. This means code will get a more explicit error when
the name is being referenced, so it can be updated to fetch the name it needs
as needed.
* 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.
* Most remote replay links are slow enough that the lag introduced by
synchronously fetching and displaying these thumbnails would be annoying for
simple mouse-over scenarios.
* This is a bit coarse, as e.g. if you have one window that is unsupported on an
API and another that is this will treat both as supported even if the active
window doesn't support capturing. This is an unlikely case and needs a new UI
to properly represent that.
* Wrapped ranges in D3D are allowed to overflow from an image subresource into
the miptail and set some/all of it :(.
* Also implement copy operations for D3D.
* In principle descriptors should be updated less often than they are
referenced, so we used to cache tracking of them at update time to improve the
speed that references can be processed at submit time during capture.
* Some applications though update a *lot* of descriptors *very* often,
effectively writing all their descriptors for a frame every frame. That means
that this background tracking is wasteful and has a big performance impact, so
instead it's a better balance to do more work at submit time during capture.
* 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.
* Users should stringify the actual value themselves if so desired. This reduces
the number of string allocations in the structured data since ResourceIds are
common.
* 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.
* For certain very large arrays it can be nice to defer generation of structured
data until it's needed, since often maybe only a handful of elements may be
needed (or commonly none at all).
* If chunks come from an allocator they can't be safely deleted because the
allocator may have been reset and recorded over where these chunks were with
other data. Fortunately we don't need to do anything to delete them, so
storing the allocator status up front is sufficient.
Jake Turner