* 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.
* renderdoc/api/replay/ contains all the headers for using the replay and
analysis side of renderdoc (like in a UI or auto-testing tool)
* renderdoc/api/app/ contains the headers if you wanted to write a
renderdoc-aware application.
* 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).
baldurk