From: <bug...@pd...> - 2004-06-19 00:24:07
|
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: dri...@li... ReportedBy: id...@us... 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. |
From: <bug...@pd...> - 2004-06-21 16:54:38
|
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 ------- Additional Comments From id...@us... 2004-06-21 09:54 ------- Created an attachment (id=401) --> (http://freedesktop.org/bugzilla/attachment.cgi?id=401&action=view) Log depth values when occlusion testing is active This is the patch I used to log the depth values when occlusion testing is active. This causes quite a lot of data to be sent to the log, so be careful using it. :) You'll also need to enable GL_HP_occlusion_test on both client-side and server-side. That's as easy has changing a '#if 0' in xc/xc/lib/GL/glx/glxextensions.c and one in xc/xc/programs/Xserver/GL/glx/glxscreens.c. -- 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. |
From: <bug...@fr...> - 2005-06-09 21:49:40
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=762 id...@us... changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From id...@us... 2005-06-09 14:49 ------- The actual bug in Mesa was fixed by Brian Paul in Mesa 6.1. The current Mesa version in the X.org tree is 6.2.1. I just committed code to re-enable GL_HP_occlusion_test. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: <bug...@fr...> - 2005-10-19 22:18:21
|
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=762 aj...@nw... changed: What |Removed |Added ---------------------------------------------------------------------------- Component|libGLcore |General -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. |
From: Brian P. <bri...@tu...> - 2004-06-23 21:09:47
|
bug...@pd... wrote: > 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: dri...@li... > ReportedBy: id...@us... > > > 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 |
From: Ian R. <id...@us...> - 2004-06-23 22:32:58
|
Brian Paul wrote: > 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. Great! What's the magic? > 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!). Agreed. That extension is a bit of a hack. > I don't know if anyone might be relying on this extension though. Does > anyone care if I remove it? My only reservation about doing that is that there is no indirect protocol (yet!) for either ARB_occlusion_query or NV_occlusion_query. My vote would be to leave it in until then and rutlessly rip it out after. |
From: Brian P. <bri...@tu...> - 2004-06-23 22:51:41
|
Ian Romanick wrote: > Brian Paul wrote: > >> 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. > > > Great! What's the magic? Basically, make occlusion_zless_triangle() work whether we have a 16 or 32-bit Z buffer. >> 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!). > > > Agreed. That extension is a bit of a hack. > >> I don't know if anyone might be relying on this extension though. Does >> anyone care if I remove it? > > > My only reservation about doing that is that there is no indirect > protocol (yet!) for either ARB_occlusion_query or NV_occlusion_query. My > vote would be to leave it in until then and rutlessly rip it out after. Well, I've found another case in which GL_HP_occlusion_test isn't working correctly. I'm not too inclined to fix it if I'll be ripping it all out. If nobody says they need the extension, I'm tempted to remove it sooner rather than later. -Brian |
From: Ian R. <id...@us...> - 2004-06-23 23:54:51
|
Brian Paul wrote: > Ian Romanick wrote: >> Brian Paul wrote: >> >>> 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. >> >> Great! What's the magic? > > Basically, make occlusion_zless_triangle() work whether we have a 16 or > 32-bit Z buffer. I saw the commit message right after I posted my reply. :) >>> I don't know if anyone might be relying on this extension though. >>> Does anyone care if I remove it? >> >> My only reservation about doing that is that there is no indirect >> protocol (yet!) for either ARB_occlusion_query or NV_occlusion_query. >> My vote would be to leave it in until then and rutlessly rip it out >> after. > > Well, I've found another case in which GL_HP_occlusion_test isn't > working correctly. I'm not too inclined to fix it if I'll be ripping it > all out. > > If nobody says they need the extension, I'm tempted to remove it sooner > rather than later. That's fair. Given that it has been disabled in DRI CVS for so long, I doubt that anyone is going to miss it. I noticed that the DRI tdfx driver advertises GL_HP_occlusion_test but not the ARB or NV extension, while the glide driver doesn't advertise any of them. Obviously, the HP extension would have to be removed from the tdfx driver, but is there any chance of getting the ARB (and NV) extensions in the glide driver? |
From: Brian P. <bri...@tu...> - 2004-06-24 16:37:34
|
Ian Romanick wrote: > Brian Paul wrote: > >> Ian Romanick wrote: >> >>> Brian Paul wrote: >>> >>>> 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. >>> >>> >>> Great! What's the magic? >> >> >> Basically, make occlusion_zless_triangle() work whether we have a 16 >> or 32-bit Z buffer. > > > I saw the commit message right after I posted my reply. :) > >>>> I don't know if anyone might be relying on this extension though. >>>> Does anyone care if I remove it? >>> >>> >>> My only reservation about doing that is that there is no indirect >>> protocol (yet!) for either ARB_occlusion_query or NV_occlusion_query. >>> My vote would be to leave it in until then and rutlessly rip it out >>> after. >> >> >> Well, I've found another case in which GL_HP_occlusion_test isn't >> working correctly. I'm not too inclined to fix it if I'll be ripping >> it all out. >> >> If nobody says they need the extension, I'm tempted to remove it >> sooner rather than later. > > > That's fair. Given that it has been disabled in DRI CVS for so long, I > doubt that anyone is going to miss it. > > I noticed that the DRI tdfx driver advertises GL_HP_occlusion_test but > not the ARB or NV extension, while the glide driver doesn't advertise > any of them. Obviously, the HP extension would have to be removed from > the tdfx driver, but is there any chance of getting the ARB (and NV) > extensions in the glide driver? I don't have time to start into the tdfx driver, so I've fixed up the problem I found with GL_HP_occlusion_test (it didn't work when using generic span paths). -Brian |