* 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.
* IF we are ref'ing all resources, we want to serialise GPU dirty resources
regardless if they're in m_FrameReferencedResources. If we are NOT
then we can skip out.
* 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.
* We expand the depth-pixel-copy CS to copy colour pixels too, and be able
to read from MSAA textures where appropriate.
* This introduces a small unnecessary overhead for non-MSAA colour textures
but it's not really an issue.
* I've also changed it to use the existing textures rather than creating
copies when the existing texture has BIND_SRV already.
* 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
* PSInput must be the first thing in the function signature to match the
output of previous stage, but we snip out the above SV semantics and
fetch them separately to get the right values and not hit any weird
compiler errors.
* This might be the wrong thing to do, I've changed my mind on this a dozen
times. I think most people will want these, and I don't think it's a bad
thing to include it as the default setting - people can still go to
customise and unselect it. I thought most people would do custom and then
opt-in since most will want it, but I suspect (from watching people run
the installer) that most people hit typical, and so don't get these.
baldurk