<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Second Life viewer bad rendering with git-ec83535" href="https://bugs.freedesktop.org/show_bug.cgi?id=57875#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Second Life viewer bad rendering with git-ec83535" href="https://bugs.freedesktop.org/show_bug.cgi?id=57875">bug 57875</a> from <a class="email" href="mailto:maraeo@gmail.com" title="Marek Olšák <maraeo@gmail.com>"> Marek Olšák</a> <pre>(In reply to <a href="show_bug.cgi?id=57875#c10">comment #10</a>) > > That bit only exists on r5xx asics. R3xx and r4xx don't have that bit. > I'd say it's related to floating point depth buffer support. I don't know > about the capabilities of the GPUs though and have to read up the > interactions between depth_clamp and depth_buffer_float again, but I'd > expect the limited depth buffer range to clamp the values. There's no floating-point depth buffer support in r500. > > I don't remember having anything useful besides some quick hacks and I don't > > have them anymore. > I've written a kernel hack, now the broken geometry is mostly behind the > correct parts. I guess this is where you stopped last time. > > Before I give up on this I'd like to investigate some more things, > particularly the interaction with glDepthRange(something similar to > 92e7c6a2581b5f612a84587500399bb00318c6f0) and the interactions with and the 92e7c6a258 fixes a piglit test which passes with r300g, so it's most probably unrelated. glDepthRange is packed in the Z component of the vectors in pipe_viewport_state, which is applied after clipping and converts coordinates from the clip space to the window space.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>