<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#c16">Comment # 16</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:hverbeet@gmail.com" title="Henri Verbeet <hverbeet@gmail.com>"> Henri Verbeet</a> <pre>(In reply to <a href="show_bug.cgi?id=57875#c15">comment #15</a>) > I've written an extension proposal for a new mesa extension that exposes the > CLIP_DISABLE bit. The proposal is attached, please review and comment. There > are some TODOs I'm not quite sure how to deal with, see the list in "Status". > - It probably makes sense to mention "depth" in the extension name somewhere, we really only care about the near and far clipping planes. E.g. MESA_depth_clip. - Perhaps it makes more sense to write the extension in terms of ARB_depth_clamp. I.e., provide a subset of ARB_depth_clamp, that only disables depth clipping, and generates undefined results in the depth test, except for perhaps GL_ALWAYS / GL_NEVER. (Also, note that you can't really make fragment depth values undefined before / in the fragment shader, because you have interactions with e.g. texture filtering as well.) It would avoid the perhaps somewhat questionable "ARB_depth_clamp must not be supported", and you can just defer to ARB_depth_clamp for most of the issues etc. The interaction between the two extensions just becomes that if ARB_depth_clamp is also supported you get defined depth test results.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>