* 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.
* If we hit a fatal error during initialisation, the structured file pointer
still points at the temporary serialiser's structured file. It's not until we
finish loading that we swap it into the driver-stored file that we can safely
return and detach ownership of.
* The UI will become non-functional and the backend will be replaced with a do-
nothing one that keeps things alive without needing error bulletproofing
everywhere in the real backend.
* These are the only handles returned up by reference from the replay driver,
dynamically allocating them means that we can steal/move the ownership of
these and keep them valid even after the replay driver is destroyed.
* Note - ShaderDebugTrace is also returned by reference but it is already
dynamically allocated like this.
* Instead of storing the API pipeline states in the replay driver and returning
pointers, we store them in the replay controller and write into it from the
replay driver.
* This will allow us to remove the replay driver and still keep any previously
obtained references/pointers to the pipeline state valid.
* 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 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.
* We preserve each API's interpretation of bit order for packed formats like
RGBA4 or R5G6B5 when displaying the raw data in the UI, but when we need to
proxy it or save to disk, we always transform to D3D's order as standard.
* This allows us to proxy them reliably because we always have a standard bit
order and APIs that need a different order transform when fetching data to the
standard format, or setting proxy data from the standard format.
* Since we restrict output formats on remap to basic float/uint/sint, for 1-byte
formats this ends up mapping to UNORM. Instead promote straight to RGBA16F to
ensure we have the precision
* We instead always have 3rdparty/ in the relevant include search paths and rely
on that. Each library still has its own unique base dir within 3rdparty to
clarify where the include is coming from.
* 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).
* Subresource handling is more consistent - we pass around a struct now that
contains the array slice, mip level, and sample. We remove the concept of
'MSAA textures count samples as extra slices within the real slices' and
internalise that completely. This also means we have a consistent set
everywhere that we need to refer to a subresource.
* Functions that used to be in the ReplayOutput and use a couple of implicit
parameters from the texture viewer configuration are now in the
ReplayController and take them explicitly. This includes GetMinMax,
GetHistogram, and PickPixel.
* Since these functions aren't ReplayOutput relative, if you want to decode the
custom shader texture or the overlay texture you need to pass that ID
directly.
baldurk