glBegin(GL_LINE_LOOP) doesn't draw what's expected on Radeon R200 cards on Linux, Mesa version: mesa-libGL-7.0.1-7.fc8. I discovered this bug while using Blender on Linux: the camera object is not properly drawn on my laptop equipped with a Radeon 9000 card. The camera has only 3 sides drawn. Screenshot: http://oxben.free.fr/blender/Screenshot-Blender-broken-GL_LINE_LOOP.jpg The corresponding code in Blender is in: source/blender/src/drawobject.c:drawcamera() ... glBegin(GL_LINE_LOOP); glVertex3fv(vec[1]); glVertex3fv(vec[2]); glVertex3fv(vec[3]); glVertex3fv(vec[4]); glEnd(); ... Blender uses GL_LINE_LOOP is many other places, this produce many visual gltiches on R200. I reproduced the bug easily by making a short program containing only the above opengl code. Only two lines are drawn instead of four.
Using driconf I disabled 3D acceleration and restarted Blender. There is no issue in this case: camera is drawn correctly and all the other glitches I observed with hardware acceleration are not present. That's why I believe the issue comes from R200 drivers, and not from Blender or Mesa software. Thanks for your help.
Yes, this looks like a r200 dri driver bug. Probably related to the tcl code and the render templates this uses (line loops are decomposed into line strips or lines (though the hw apparently could handle line loops just fine - r100 could not)). If that's the case, it might work if you switch off tcl (use driconf or set tcl_mode=0).
You are correct. I set tcl_mode=0 and restarted Blender and all the glitches I saw in the interface are gone. Thanks a lot for the workaround! :) Is this something that can fixed later in R200 code, or will I need to use this trick (tcl_mode=0) forever? Thanks again.
Aha, this explains why the selection boxes in HomeWorldSDL only show the right and bottom edges on R200. Checking the code shows GL_LINE_LOOP is used there. However it used to work correctly. Had been meaning to raise a bug but had problems first bisecting it many moons ago due to the build failing but IIRC it was around about the VBO merge. Looks like an off by one error.
Actually, is this might be a duplicate of bug 12410? Though seem to recall it working correctly with a 855 and R100 though.
(In reply to comment #3) > Is this something that can fixed later in R200 code, or will I need to use > this trick (tcl_mode=0) forever? This certainly can (and should) be fixed. It just requires someone to have time to look at it... (In reply to comment #5) > Actually, is this might be a duplicate of bug 12410? Though seem to recall it > working correctly with a 855 and R100 though. It could be the same bug (or at least be related). i915 doesn't use the same render templates as the r200 tcl code however (as it has no tcl - it should resemble more what the r200 swtcl code (which works) looks like). There are a couple of mesa demos/tests which use line loops (demos/ray, tests/texwrap, tests/antialias,...) and it looks like always 2 segments are missing. The line loop render template code is (unlike other primitives) dependent on flags telling it if start and end of the primitive is included, if those are missing it could cause the first and last segment be dropped.
Created attachment 12949 [details] [review] use _tnl_translate_prim so begin and end flags are included in flags Not sure if that's really correct, but I think the specialized render functions need to do the same as what the t_vb_render code already does, so the flags include the primitive begin and end flags.
That patch fixes it for HomeworldSDL, thanks.
Your patch solves the problem with GL_LINE_LOOP in Blender. Great! It took me some time to test your patch: I had to figure out how to build mesa first . :) (I cloned "git://anongit.freedesktop.org/git/mesa/mesa#mesa_7_0_2", applied the patch, build...) Thanks Roland. I hope your fix will be integrated soon in Mesa.
Fixed in git (master and mesa_7_0_branch). Hopefully for other drivers too...
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.