* Apparently Application.Exit() doesn't close immediately and can throw
an exception, leaving the UI open while the updater tries to run and
nothing works. Environment.Exit(0) should do better hopefully.
* The VS can consume system value semantics at the end of the signature
that weren't present in the IA layout's bytecode. Note that if the
order changes (ie. the system value element is first) then that's not
OK. Only trailing elements are allowed.
* Depth is not cleared, only colour buffers.
* This uses the same definition of pass as the quad overdraw overlay,
which isn't quite the same as the auto-grouping passes (which allow
for varying colour binds being grouped together). It only counts up
to the last draw where the outputs were different.
* E.g. if a huge buffer is displayed as just floats, there could be
100s of millions of rows. Instead, we clip to 200,000 (anecdotally
where things start getting a bit laggy on the control), and allow
advancing through sections of the buffer at a time.
* If no position element is selected at all that's really confusing, so
worst case we just pick the first attribute.
* Making it intuitive/obvious that you can change which attribute is
displayed as mesh - that's a different problem.
* This API is now intended to be forward and backward compatible as much
as possible. Meaning applications should be able to run without
changing on many RenderDoc versions after the one they are built
against without breaking.
* All function pointers are fetched at once in one versioned GetAPI()
function, to save on constant GetProcAddress/dlsym'ing.
* Otherwise, it's largely similar to the previous API.
* Next step is to display VS and other stage inputs on the input panel.
* Also need to tidy up the fetching of highest mip/array slice etc to
use the same codepath.
* This seems way more reliable and smaller than shipping a compiled .dll
* For some reason I didn't find this method before (I only knew that
you could ship the loose files which wasn't a good solution).
baldurk