2
\$\begingroup\$

How is it possible that a fragment is generated, passes the depth test but isn't written to the current render target?

This is the pixel history I see if I capture a frame in RenderDoc:

enter image description here

The fragment should pass the depth test (same depth of the corresponding pixel in the depthbuffer and depthfunc = Less equal), blending is not enabled, stencil test is not enabled, but the new color is not written.

What am I missing? Is there some other state I'm not taking into account?

\$\endgroup\$
4
  • \$\begingroup\$ Is it possible the depth values have been rounded for display, and they actually differ in the 4th or 5th decimal place? \$\endgroup\$
    – DMGregory ♦
    Commented Apr 1, 2022 at 10:56
  • \$\begingroup\$ @DMGregory maybe, however RenderDoc highlights depht test failure in the pixel history tab (on the right in the picture) with a red (not green) tint for the corresponding entry and labels it with "Depth test failed".... \$\endgroup\$
    – leone ruggiero
    Commented Apr 1, 2022 at 12:14
  • \$\begingroup\$ Right, which is what we would expect if the depth value of the new fragment is strictly greater than the stored depth value, even if they round to the same 3-decimal representation for display. \$\endgroup\$
    – DMGregory ♦
    Commented Apr 1, 2022 at 12:17
  • \$\begingroup\$ You can try adjusting the number of digits used for displaying floats in the settings: renderdoc.org/docs/window/settings_window.html \$\endgroup\$
    – Adam
    Commented Apr 10 at 0:01

1 Answer 1

Reset to default
0
\$\begingroup\$

Renderdoc run most hlsl code on cpu instead of gpu, so it just simulate how gpu runs. There maybe some float precesion problem, so you can't see it in renderdoc.

\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .