There’s (of course) a lot of ways to do this, it can involve a bit of plugin programming too, but not necessarily.
In your case volatile output is perfectly normal (and valid) : several pixels can have the same depth. So you can return a different pixel at times.
So I would separate your technique into 2 stages:
Find the min depth (without pixel location)
Extract pixel(s) where pixel depth=min depth.
To find the minimum depth, there’s a lot of ways, easiest one will likely be:
render to a 1x1 texture (R32_Float) in vertex shader set all your pixels to write to 0,0,0,1 coordinate and pass depth value as texture coordinate. write this depth value as final color.
Set blend state to minimum.
In a second pass create a buffer of stride 12 (float3 for position/depth), which should be appendable, reset counter every frame in renderer.
In compute shader process every pixel and append when depth <= min depth.
in the sample patch i posted above there is exactly one min-depth point, but the computeshader cannot find it very reliable.
i also tried your proposed 2-stage technique (calculate min-depth / find pixel with min-depth). but the min-depth computeshader doesn’t work very well because the calculated min-depth is volatile too…
see here: https://dl.dropboxusercontent.com/u/51232449/minDepth.zip
the interlockedMin function seems not to work for me :/ i dont know why.
but your idea of a 1x1 texture seems to be very clever. i will try that!
why has the second pass have to be appendable and why do i have to reset the counter every frame?
this is a new version. there is only one problem left:
the minDepthTexture shader does not work properly. like vux said we need the “darkest” color of the original texture, so i set the position in the vertex shader to 0,0,0,1 and added a blend renderstate with blend-operation “minimum” to it. so i expect to get a 1x1 texture with the darkest color (= nearest point from depth texture)… unfortunately it doesn’t work.