* We can't assume that premod == postmod in all cases. For colour history on a
colour target it will be, but depth values can change indepednently. Instead
we explicitly fetch pre/post mod before and after each event instead of just
postmod.
* The target image won't always be bound to the (or any) current framebuffer, if
e.g. it's written via image storage. Ensuring we still have a framebuffer to
copy from keeps most code the same.
* We will want to be able to batch these independently and this approach is
easier with fixed slots than having a slot per type in the same framebuffer.
* All tests must be disabled as much as possible, including depth clipping and
depth bounds, as well as binding a fixed shader for potential shader discards.
* The copying of a pixel happens via compute for MSAA targets so the compute
state becomes dirty in CopyPixelForPixelHistory - we rebind all state to
ensure it is properly re-set. This is not needed if non-MSAA.
* When we add a depth attachment we want to ensure this doesn't "activate" a
dormant depth test/bounds state which was inactive before due to the lack of
an attachment, so turn them off explicitly in our replacement pipelines.
Used when debugging a subgroup with workgroup operations get the entire workgroup.
Get the subgroup (and workgroup) layout of threads from the GPU instead of assuming tightly wrapped.
Ensure the lane input data is organised to match the simulation expectations
Enabled by default : config option "D3D12_DXIL_Debug_EnableShaderDebugMT"
By default run jobs in a hot spin loop in a single JobQueue job
Each JobQueue Job runs SimulationJobHelper which is a while loop looking for threads to simulate
Developer option "D3D12_Hack_ShaderDebugUsesJobSystemJobs" to run simulation steps in individual job system jobs.
Make it persistent in the lifetime of the DXIL Debugger session
Add the wrapper to the DXIL Debugger
Make the wrapper replay reset consistent
Store initialisation data in the ApiWrapper
Pull data from ApiWrapper into Debugger during BeginDebug()
Makes DXIL debugger behave more like SPIRV debugger during its initialisation
baldurk