* This allows you to hook into processes that are difficult to launch
directly with the existing functionality in RenderDoc.
* This is rather risky, as it modifies the AppInit_DLLs registry key to
inject a small shim dll that checks for the desired process and injects
the full renderdoc.dll. If that registry key got left, or if there was
some incompatibility with the shim dll, you could have problems. It
should only ever be used as a last resort if there's no other way to
capture.
* Whenever a child process is hooked, that's passed back up to the UI and
a list is shown with all the child processes of the one you are connected
to in the dialog.
* At any point you can double click to create a new dialog latched to that
process.
* If the process you're attached to closes and has one child, similar to if
you only have one capture made the dialog will close itself and open a
new connection to the child process. This is the case for e.g launcher ->
editor
* This behaviour is overridden if you made a capture, as it assumes you
then don't care about the child processes and instead want to open the
capture. You can always do file -> attach later.
* If it has multiple children when the process closes, the dialog stays
open to allow you to peruse the list and maybe open up a connection to
one of the children.
* For vertex shader output only, we do the streamout as a point list and
render each vertex once then we can reuse the same(ish) index buffer and
topology as the original draw.
* For GS/DS out there will likely be some expansion of verts so we do the
same as we used to.
* This means when multiple fragments are writing to a pixel you can choose
precisely the one you want to debug, rather than the debugging always
running the approximately last fragment to pass
* Expand the abilities of the GetTextureData in replay drivers
to be able to resolve samples and render down to RGBA8 unorm
for file export to other programs.
* Greatly improve the ability to save textures - in theory any
texture format/type/dimension/etc should now be mappable in
sensible & useful ways to output formats.
* This is useful in e.g. a renderdoc-aware application that has voluntarily
injected renderdoc, and then wants to boot the UI to automatically open
up the management connection
* Also for float/unorm texture add an additional "resolved" option that
just does an unweighted average of all samples, which is the behaviour
from before (assuming that's what ResolveSubresource does).
* Beta builds will be between nightlies and official releases in terms of
stability. Tested at least to make sure there are no obvious bugs, but
haven't been through 1-2 weeks stabilising period.
* Beta builds will upload crash reports, so I can get early warning of any
bugs that are creeping in on master.
* http://blog.selfshadow.com/2012/11/12/counting-quads/
* Quad Overdraw based on ScenePS4 from the revised implementation. The
colours are new, up to 20 levels. Picking pixels shows the overdraw level
* Available per-pass and per-drawcall, a pass defined the same way as in
the mesh view, drawcalls since last clear or RT change.
* List of events now passed through to RenderOverlay the same as RenderMesh
* For APIs where the shader namespace/bindpoint (which may be arbitrary
like 'the Nth texture resource' can be mapped, at each event, to the
actual API bind point where the object is.
* On D3D11 this is pass-through, on GL this returns the value of each
uniform.
* This also means GL shader reflection structures are properly immutable
and the variance in the uniform values is handled elsewhere.
* In future this might need to be expanded to support more complex binding
methods, where the mapping returns the resource rather than just mapping
to an integer bind ponit.
baldurk