* 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.
* The last fix to this file wasn't complete - both width and height must
be greater than 0 for the area to be valid to fill.
* Fixes an uploaded crash report.
Disable warnings in qt (warn_off) then remove -w from qt compiler flags
to re-enable previous renderdoc warnings
Use qt standard way to enable c++11 eg CONFIG += c++11
* Since we don't clear out stale descriptors that reference deleted
objects, we have to make sure that ids and records for deleted objects
are always valid (until they're allocated and filled with something
sensible).
* On AMD calling glVertexArrayElementBuffer doesn't update the global
query for GL_ELEMENT_ARRAY_BUFFER_BINDING until the VAO is unbound and
bound again. To avoid that we just always emulate this function.
* Even if the map isn't persistent, we need to redirect it into our
shadow buffer when the user maps it. Note that on unmap we already
have code to unconditionally check for changes and copy.
* In GL various really really stupid options for changing shaders and
recompiling and relinking is possible.
* We don't support the whole giant trash fire, but we can at least
handle re-compiling a shader within the same program (so the original
source isn't used anywhere and can be safely rewritten).
baldurk