* We used to allow applications to call vkFlushMappedMemoryRanges on coherent
memory to manually annotate regions of memory that are changed in persistent
maps, thus avoiding the overhead of RenderDoc needing to check for changes on
each submit.
* Unfortunately this means that if the application calls flush wrongly then
changes will no longer appear, even though the application was completely
correct, if misleading, since by the spec behaviour vkFlushMappedMemoryRanges
is a no-op on coherent memory so incorrect calls to it make no difference.
* Since applications making use of this are rare or non-existant we just remove
the optimisation.
* 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 typically means that the user hasn't checked correctly for SM6 feature
support before trying to upload DXIL shader, which will then result in
unpredictable behaviour or crashes on replay.
* During capture we detect this and flag it in the overlay text, and prevent
capturing. On capture load we fail to load if we detect such a PSO.
* Fortunately the extension doesn't add any functionality that can't be achieved
through the old bindings, it's just better decoupled.
* What we do is set up our own VAO attrib/binding tracking, and translate all
the functions (old and new style) into the equivalent modifications of that
state, then each time a change happens we flush out the attribs and bindings
using the old attrib functions.
* We also intercept the queries to the new bindings and return the right values,
so even if loading a capture that uses ARB_vertex_attrib_binding would work as
expected (as all the translation to old bindings happens under the emulation
layer).
* For pipelines using tessellation or containing a geometry shader we use
transform feedback to fetch the output of the vertex pipeline after these
stages.
* Screenshots and icons are updated to latest style
* Many out-dated references and mentions of support updated.
* Documentation added for new windows like resource inspector and
performance counter viewer, as well as new features like saving
bookmarks, resource names.
* Added documentation for Android support as well as OpenGL ES support.