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.   
   
--    
Configure bugmail: http://freedesktop.org/bugzilla/userprefs.cgi?tab=email   
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.


-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
--
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to