* This may break on drivers old enough to not recognise the first non-legacy
ASIC, but that is much rarer than new drivers that have dropped support for
the old ones.
* 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.
* 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.
* We already link to the chunk index and the chunk metadata contains the
callstack, there's no need for a duplicate copy when there may be many
APIEvents in a capture
* The block index may change between capture and replay, so serialising the
index alone is unstable similar to locations. Program initial states already
serialise by name, but if a capture contains a block binding change mid-frame
this could serialise wrongly.
* This helps catches cases where a discarded image is accidentally used and in
many cases may still have valid data. Particularly on Vulkan this is relevant
for DONT_CARE renderpass load and store ops.
* This is a very big blunt hammer for fixing the problem of multithreaded
submission from GL. Every GL call checks to see if the context changed (which
would only happen from a thread switch to a different context) and if detected
it inserts a manual MakeCurrent call equivalent.
* It's slow to capture (when this happens - checking is not particularly slow)
and slow to replay, but it's functional which is an improvement.
* It's not particularly scalable and can be brittle to driver changes, and we
can use targeted specific pixel tests to check what we really want - to see if
the output has rendered correctly.
* Overlay tests still check files directly - this is a future refactor to
remove.