-
Notifications
You must be signed in to change notification settings - Fork 0
Pixel History
-
Retrieving the shader output colour and depth. If blending and a draw overdraws the pixel more than once (likely) then we want to get each individual fragment that's output. We could do this with UAV writes but we want to maintain the existing pixel shader. In theory you could translate the bytecode back to HLSL and append the appropriate instructions to write to a UAV but that's very complex.
We can get the final result by just rendering to a new render target but this doesn't account for overdraw or blending. One potential solution to this would be to use stencil testing to count the number of layers we go through and set the stencil value to the 'layer' we want to retrieve (similar to stencil shadowing techniques). This does mean N iterations for the drawcall though so might be slow. It should work though as the order of fragments written to the screen should be contractually guaranteed.
-
Going the whole distance with the above you also want to get test-results on a per-fragment basis, but I'm not sure if this is possible in all cases (e.g. how do you know if the nth fragment failed the stencil test if you're using the stencil to select the nth fragment).
-
Handling MSAA - haven't really thought about this yet.
-
It would also be awesome to get the primitive number out for each fragment, we can then work backwards to get the vertices that made up the triangle that was rasterized. If no geometry shader or tessellation is bound then the pixel shader can just bind a semantic to obtain the primitive ID,
but in other cases this isn't possibleand it seems that if geometry and/or tessellation is active, binding the primitive ID semantic in the pixel shader gives us the original primitive, which is very nice!The way I've thought to do this would be to fetch the post-shader mesh for this drawcall and upload the positions to a custom vertex shader that just does a pass-through and appends the primitive ID with this.
However that only gives you the primitive output from the final stage - that doesn't translate through to a primitive (or control point set) from the initial data read to the vertex shader. Perhaps that's not important as it's so user-defined?Binding regular SV_PrimitiveID gives us the original primitive, so we should be able to get all but intermediate stages.
Performance is still a concern and in cases of large numbers of draws this can still be a bit laggy. It's OK at the moment but this is probably an important area for optimisation (and general log-replaying optimisations will help here).