The usage of the function 'glClipPlane()' inside an OpenGL program is supposed to clip an object at the defined clip plane which does not happen. I'm using a radeon9700 card. DRI is enabled. Screenshot of how it is supposed to work (winXp + mingw + no_mesa): http://ingo.wollsau.de/clippingTest/sphereClipped.png Screenshot of how it actually works on my system: http://ingo.wollsau.de/clippingTest/sphereNotClipped.png The used test-program code (redbook example): http://ingo.wollsau.de/clippingTest/clippingTest.c Info that OpenGL told me (see code): Maximum count of additional clip-planes: 6 Depth bits: 24 glxinfo: http://ingo.wollsau.de/clippingTest/glxinfo xorg.log: http://ingo.wollsau.de/clippingTest/xorg.log May be related to: http://bugs.freedesktop.org/show_bug.cgi?id=6512 and http://webcvs.freedesktop.org/mesa/Mesa/src/mesa/tnl/t_vb_cliptmp.h?view=log Previously posted here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=408679
Bug confirmed Experienced on [Radeon X800PRO (PCIE)], Renderer : Mesa DRI R300 20060815 x86/MMX/SSE2 TCL Version : 1.3 Mesa 6.5.2 Sphere of the above testcase isn't clipped.
I can confirm with mesa 7.0: OpenGL renderer string: Mesa DRI R300 20060815 x86/MMX/SSE2 TCL OpenGL version string: 1.3 Mesa 7.0 ATI Mobility Radeon X700 (M26) (PCIE)
I've figured out how to upload the clipping planes. I'll attach some information so that Bugzilla doesn't reformat it. I can modify the driver later to support clipping planes but I need to check the other planes, too.
Created attachment 10672 [details] Clip Plane
I just checked the clip plane numbering... GL_CLIP_PLANE0 = 0x400 GL_CLIP_PLANE1 = 0x401 So I guess it's just incremented for each clip plane. I'm not sure how many R300 supports.
Based on the location of R300_PVS_UPLOAD_POINTSIZE, it supports 6 clipping planes.
You will probably find that writing to those registers have no effect at all. Presumably you have to do some initialization first...
I looked at the dumps some more, and I think that 0x221c (previously an unknown register) is the clip control register. The first 6 bits seem to be the enable bit for each clip plane. Previously we thought this register had to be 0x0 for normal rendering and 0x0001C000 for buffer clears; so maybe there is some weirdness with this clip register and buffer clears... but it's main purpose seems to be clip control not some kind of rendering mode control.
Created attachment 12340 [details] [review] first attempt at r300 clip plane support Can someone test this code, I've only used it with the clip redbook demo and it seems to work, but I've no idea what things it might break..
(In reply to comment #9) > Created an attachment (id=12340) [details] > first attempt at r300 clip plane support > > Can someone test this code, I've only used it with the clip redbook demo and it > seems to work, but I've no idea what things it might break.. I think it might break vertex programs if the app has user clip planes enabled. This is not supported and as far as I understand the user clip enable should just be ignored in this case (though I doubt it's a problem in practice). Unless you have a position invariant program, in which case user clip planes work exactly the same as with the fixed function pipeline.
I checked with Dave and pushed his patch to Git, along with a register renaming patch. Marking bug as fixed.
Mass version move, cvs -> git
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.