Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://freedesktop.org/bugzilla/show_bug.cgi?id=762 Summary: GL_HP_occlusion_test broken due to mismatch in depth
bits
Product: DRI
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: libGLcore
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
A long time ago I disabled GL_HP_occlusion_test on both the client-side and the server-side because the Mesa occlusion demo always got a value of 0 from the glGetBooleanv(GL_OCCLUSION_TEST_RESULT_HP, v) queries. I finally got around to investigating the problem, and the bug is 100% on the server-side.
I added code to src/mesa/swrast/s_triangle.c to print the values of span.z, z,
i, and zRow[i] in the RENDER_SPAN macro for occlusion_zless_triangle. The
values for span.z and z (and i, of course) look perfectly reasonable, but rowZ
was always 0x00ff for odd values of i and always 0xffff for even values of i. 'LIBGL_ALWAYS_INDIRECT=y glxinfo' shows that only 24-bit depth-buffers are
available, but I'm guessing that DEFAULT_SOFTWARE_DEPTH_TYPE is GLshort and
DEFAULT_SOFTWARE_DEPTH_BITS is 16.
It is easy enough to change the value of DEFAULT_SOFTWARE_DEPTH_BITS to 24, but I don't think that really fixes the problem. That seems like more of a bandage that just covers are much larger problem. Or does it? If DEFAULT_SOFTWARE_DEPTH_BITS is 24 will 16-bit depth-buffers still "work" correctly?
Since this problem is on the server-side only, the next time I commit a change
to glxextensions.c (client-side), I will re-enable GL_HP_occlusion_test.
Ian, I've found the cause of this bug and have a fix. However, I'm really tempted to rip out the GL_HP_occlusion_test extension altogether.
It's obsolete in favor of GL_ARB_occlusion_query and the implementation of GL_HP_occlustion_test is a bit ugly. For example, it relies on a glGetIntegerv() to clear the occlusion query flag (glGet functions shouldn't _set_ state!).
I don't know if anyone might be relying on this extension though. Does anyone care if I remove it?
-Brian
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
