* 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.
* For the most part we implement this as a thin pass-through layer. Where we
care about things (image barriers for layout transitions and queue
submissions) we do two different things:
- For image barriers, we "downcast" to plain VkImageMemoryBarrier. Currently
the only thing that's unique to VkImageMemoryBarrier2KHR is extra access
flags and pipeline stages, which we don't care about. This keeps a lot of
code from having to either handle two paths or handle the new path and then
do lots of conversions back to VkImageMemoryBarrier when running on older
drivers.
- For queue submissions we do the opposite. We promote old VkSubmitInfo to
VkSubmitInfo2KHR and process that in a common function, then if necessary
we decay back to VkSubmitInfo before sending to the driver.
baldurk