<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - GL_DEPTH_CLAMP doesn't clamp to the far plane" href="https://bugs.freedesktop.org/show_bug.cgi?id=97231#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - GL_DEPTH_CLAMP doesn't clamp to the far plane" href="https://bugs.freedesktop.org/show_bug.cgi?id=97231">bug 97231</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Jules Blok from <a href="show_bug.cgi?id=97231#c3">comment #3</a>) > Created <a href="attachment.cgi?id=125589" name="attach_125589" title="apitrace file version 2">attachment 125589</a> <a href="attachment.cgi?id=125589&action=edit" title="apitrace file version 2">[details]</a> > apitrace file version 2 > > That's a rounding error, 16777215 / 16777216 is being rounded to 1 in the > apitrace GUI. > > I've attached another apitrace that's more representative of the current PR. > The difference being that we've reversed the depth range to gain more depth > precision. Oh I could see why it might not work with llvmpipe if you do reverse depth range. lp_setup_set_viewports() will set the min/max depth (they actually get "reverse-calculated" from viewport), but it will not take the potential reversing into account, so assuming near <= far. These values are then later used for clamping (in generate_fs_loop). Thus with min = 1.0, max = 0.0 it will first do the min against max (so the value will end up negative or 0.0) and then the max against min from the result (therefore, any value would end up as 1.0). Just a theory though...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>