* On x64 windows IsWow64 returns true for 32bit programs, but on x86
windows there is no such thing as Wow64 so it returns false. Detect this
by checking our own processes Wow64 nature (which should always return
true if Wow64 is a thing).
* This means that e.g. decimal separator will always be . and similar
effects, which avoids the need to have culture specific formatting or
special-case handling around CSV export etc.
* Occlusion queries seem to be unhappy with a depth-stencil state that
performs no tests and sometimes can produce incorrect results. This
appears to make the queries more reliable and fixed cases where depth
clip was showing as discarding pixels incorrectly.
* There's still something weird going on here, I'm not super happy with it.
* Also do a full replay after the shader discard test as there seems to be
some kind of D3D/driver bug that can cause false positives on test
failures.
* In the case where blending is disabled this gives us the passing shader
output value (when blending is enabled we need to get the in between
fragments, if any.
* Uses occlusion queries to determine which events touch a given pixel
(by replaying with all tests disabled except scissor, and scissoring to
the pixel).
* Caused the render state tracking to get confused (as UAVStartSlot is
used to determine the number of RTVs) and led to weird inconsistent
states being restored. Most obviously led to RTs not being set when
they should have been on replaying and drawcalls going missing.
* NULL specifies that a gap should be made/skipped in the output data.
* This would crash before but now serialises NULL as "" since that's an
invalid SemanticName (must be NULL or name a semantic). This will still
read old logs fine but old programs will not do the right thing on new
logs.
* These often come up when you have an inline array that are dynamically
indexed into (e.g. an array of offsets in a poisson disk used in a loop
that isn't unrolled).
* The explanation is in the FAQ but the short explanation is that most
data e.g. normal maps are conventionally displayed as if they contained
SRGB data, so RenderDoc does the same so things look as expected.
* Print out the type via guid - if we can track which resources are
creating duplicates we can pass the error further back to the Create*
function so we can dump descriptor etc.
* This lets us distinguish framebuffer object 1 on context A from
FBO 1 on context B.
* At the moment we assume that all shareable objects are shared between
all contexts. I think this is sensible and fairly common, but it will
break if some contexts don't share as the objects will alias.
Baldur Karlsson