* EXT_direct_state_access emulated by pushing/popping current bind
* ARB_copy_image emulated with framebuffer blits
* ARB_clear_buffer_object emulated with Map + memset/memcpy
* ARB_internalformat_query2 emulated with a limited hardcoded database
* This is a bit of a hack. Mesa seems to return a function pointer for
functions it recognises but doesn't support. So e.g. if you query for
glBindFramebuffer you'll get the implementation, if you query for
glBindFramebufferEXT then you get a stub that errors out.
* So in this case we ensure that any EXT/ARB aliases only set their
function pointer if we don't have the core function already. This will
fix some cases but obviously doesn't help if the core function is the
error-stub and the extension is supported...
Currently, selecting an event with children (e.g. vkCmdExecuteCommands)
in the event browser will cause the API inspector window to show the
final child event, rather than the event itself. This behaviour makes
sense everywhere else: selecting an event with children shows the state
after all children have completed.
However, for the API inspector, we want to be able see API calls for
the parent event when it is selected rather than those of its last
child, particularly in the case of vkCmdExecuteCommands which may have
other API calls leading up to it.
To allow this, distinguish between the "current event" and "selected
event". For an event with children, the former refers to the last
child, while the latter refers to the event itself. ILogViewerForm now
has two separate event callbacks for when either one changes.
The API inspector now makes use of the selected event, while everything
else continues to use the current event.
Before editing a pipeline, we need to recreate its creation info struct.
Compute pipelines have their own VkComputePipelineCreateInfo instead of
VkGraphicsPipelineCreateInfo, and we now make that distinction.
* This means that any 'degenerate' cases of only one event or so on will
still have enough slots to be able to handle reasonable amount of
overdraw. The only case that will fail is if every event has loads of
hits, but on average there should be enough slots allocated.
* This requires that every operation on output windows leaves the state
untouched, so make a few changes to arrange that.
* By doing this it means any unstable/non-deterministic results are
consistent between the current capture inspection and the shader
debug results.
* Without this, the RADV open source driver also gets checked, and its
version is 0.0.1 so it gets marked as buggy.
* Unfortunately there's not a great way to identify different drivers
for the same piece of hardware (ie. PCI IDs are the same).
* We have to use the original allocators when re-recording because the
capture may record multiple command buffers at the same time,
requiring multiple allocators.
* This doesn't actually fix any problems, but a couple of crash reports
exposed the fact that we try to use the result of CreateDescriptorHeap
before checking for errors - this leads to a crash and hides the real
problem.
* Located via a crash report - if there are no initial states in a
capture at all, then initStateCurList will still be NULL after trying
to apply them.
* Should fix a reported crash - it looks like an invalid buffer ID was
passed, and there's no protection for this.
* As with other invalid API use, RenderDoc isn't intended to be totally
safe against bad API use. This check is easy to add though and should
catch some simple cases.
* I received a few crash reports with a disposed buffer viewer still
doing work. My theory is that some operation took long enough that the
user was able to close the viewer (perhaps *because* it was taking a
long time) and subsequent work then didn't handle the window having
been closed.
baldurk