* This will solve the common case encountered when physical devices
vary between capture and replay, where two devices swap over.
E.g. [0]=AMD [1]=NV to [0]=NV [1]=AMD
* This can also happen with discrete and embedded GPUs that swap order.
* It will also provide a limited amount of portability by selecting a
closer matching physical device if more than one is available.
* This is a possible fix for a case where render work triggered by mouse
movements (such as pixel and vertex picking) can happen faster than it
executes, leading to a backlog of render commands and a noticeable lag
which only gets worse the more you move the mouse until everything
seems to be unresponsive or laggy (especially if you then trigger a
blocking command like event change, which will block the whole UI
until the queued picks happen).
* Since a new pick coming in will override and make redundant the
previous pick, we allow the render commands to do just that. If a new
command comes in, we remove any previous commands with the same tag
and put the command in the first match (this prevents a tagged invoke
always being pushed to the back of the queue).
* When creating replay-only images via vkCreateImage we don't need to
add any extra properties. Only during capture we need to add replay-
needed properties, so that the same call will be used as during replay
and so the same set of memory requirements.
- Fix sorting to respect visual ordering by ID, including parent.
- Provide Ctrl-A to 'Select All'. Note that there is an extant
bug with the redraw where renderdocui will not repaint when
it gets focus back.
GLES allows drawing from client memory instead of VBOs. We keep a set of
buffers, one for each potential attribute, to bind the vertex attribute to
instead of the client array pointer. These buffers are then filled before
the draw call.
* For VS we can assume that instances all output the same amount of data
so each instance outputs totalVerts / numInstances verts. However that
assumption doesn't hold true for geometry/tessellation stage where
each instance can expand independently.
* Unfortunately the only way to get per-instance sizes is to do an
O(N^2) loop of draws up to the real number of instances, checking the
total output each time, and find out the per-instance size from there.
* Once vulkan has an implementation for GS/Tess out, it will be simpler
as we can just patch the shader to write to an atomic counter with the
primitive/vertex output count in each instance.
* Not used yet, as I need to figure out how to apply list markers when
we record multiple individual lists. Doing open/close of a list just
for the marker seems wasteful. It could be fired directly at the queue
* Previously this fix was needed for shader debugging since we did a
replay up to before the draw, before debugging. However we don't do
that anymore and in general the event ID we last replayed will be
accurate.
* The majority of GL calls that create objects are pretty failure proof
since they don't really do anything apart from create/allocate. In the
case of glCreateShaderProgramv though it requires the call to be valid
e.g. the type enum to be correct, so it can actually return 0 if that
happens.
* If we don't check for this then we end up creating an ID and program
for name 0 which causes all sorts of problems.
* Thanks to build-master general @aras_p for the tip:
https://twitter.com/aras_p/status/841287101907910656
* The projects are still defined with the usual platforms Win32 and x64,
this only affects the naming in the solution configurations.
* Previously on VS2010, the DIA2 library wasn't properly supported on
64-bit, so it needed a separate program that always ran 32-bit and
proxied operations over a named pipe.
* Now DIA2 will load correctly in 32-bit and 64-bit, so we can do the
work in-process without needing the separate exe.
* We still need to distribute dbghelp.dll and symsrv.dll, so these now
live alongside renderdoc.dll in the build/install folder with matching
bitness.
* At the same time fixed a bug I noticed where the 0-based module index
would return 0 for the first valid module and be treated as invalid.
* Truly, this is a sad day. But unfortunately many dependencies are just
not supported and it's increasingly difficult to stay on VS2010.
* In an ideal world, the IDE and compiler would be decoupled, but that's
not the case.
baldurk