Bug 28130 - vbo: premature flushing breaks GL_LINE_LOOP
Summary: vbo: premature flushing breaks GL_LINE_LOOP
Status: RESOLVED DUPLICATE of bug 81174
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: marius predut
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-16 07:06 UTC by Campbell Barton
Modified: 2015-10-17 16:13 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
python opengl test python/opengl/pygame (536.93 KB, application/python)
2010-05-16 07:06 UTC, Campbell Barton
Details
Image displaying the bug. (43.63 KB, image/png)
2010-05-16 07:07 UTC, Campbell Barton
Details
C program which demonstrates bug (36.56 KB, application/zip)
2010-05-16 08:10 UTC, Sergey I. Sharybin
Details
python opengl test python/opengl/pygame (Switching states) (281.41 KB, application/python)
2010-05-16 09:16 UTC, Campbell Barton
Details
Fixed version of C program (36.56 KB, application/zip)
2010-05-16 11:01 UTC, Sergey I. Sharybin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Campbell Barton 2010-05-16 07:06:45 UTC
Created attachment 35687 [details]
python opengl test python/opengl/pygame

Hi, We have a bug report in blender3d on linux which reports a drawing problem with both Intel and ATI graphics cards (32 and 64bit x86 - linux).

I didn't get the problem with me nvidia driver so I compiled the latest mesa (7.8.1) and ran blender with Mesa's software libGL.so LD_PRELOAD'd to redo the bug.

I made a simple example of this bug in python (depends on pygame and pyopengl)
to show how this bug happens in an isolated testcase.

See attached, will attach an image of the bug next.
Comment 1 Campbell Barton 2010-05-16 07:07:38 UTC
Created attachment 35688 [details]
Image displaying the bug.
Comment 2 Campbell Barton 2010-05-16 07:08:43 UTC
Note that this bug happens in Blender3d and in a very simple testcase so its (C and Python application), so its very unlikely the bug is in either PyOpenGL or Blender.
Comment 3 Campbell Barton 2010-05-16 07:12:10 UTC
Here is the report in blenders bug tracker:
http://projects.blender.org/tracker/index.php?func=detail&aid=22346
Comment 4 Sergey I. Sharybin 2010-05-16 08:10:51 UTC
Created attachment 35692 [details]
C program which demonstrates bug

Maybe C program would be useful for debugging.
Comment 5 Pierre Willenbrock 2010-05-16 08:53:44 UTC
The GL_LINE_LOOPs around the 5461st and 10921st vertex are closed prematurely after the aforementioned vertices. You can change all other GL_LINE_LOOPS to GL_LINE_STRIPS without changing the extra lines(Obviously, you will be missing some closing lines). Moving the 5461st and 10921st vertex and the first ones of the given LOOP around confirms that the extra lines is between these vertices. 

Looks like the vertices are collected before drawing and then the primitives are incorrectly split leaving at least one GL_LINE_LOOP where there should be two GL_LINE_STRIPS. I could not find the code responsible for this.
Comment 6 Campbell Barton 2010-05-16 09:16:31 UTC
Created attachment 35695 [details]
python opengl test python/opengl/pygame (Switching states)

Hi, I added a modified version of the python test case.
It switches between 3 states.

0: draw the first part of the shape
1: draw the second part of the shape
2: draw both parts.

You can see that only when both parts are drawn the bug is visible.
therefor I think the bug is not in the use of glBegin(GL_LINE_LOOP);
Comment 7 Sergey I. Sharybin 2010-05-16 11:01:34 UTC
Created attachment 35697 [details]
Fixed version of C program

Pardon, previous archive was incorrect (i've used GL_LINE_STRIP instead of GL_LINE_LOOP for investigation and there was no atrifacts, but there should be GL_LINE_LOOP).
Comment 8 marius predut 2015-06-11 17:13:37 UTC
My investigation till now :
Because the test code call twice the 
glBegin(GL_LINE_LOOP);glVertex3fv(); glEnd()  and then glFlush()
if we add an intermediary glFlush() between those sequential call then the bug 
is fixed.
Seems a trouble with last status of glBegin(GL_LINE_LOOP) after the same call, in case not flushing was done.
Comment 9 Roland Scheidegger 2015-06-11 17:24:25 UTC
(In reply to marius predut from comment #8)
> My investigation till now :
> Because the test code call twice the 
> glBegin(GL_LINE_LOOP);glVertex3fv(); glEnd()  and then glFlush()
> if we add an intermediary glFlush() between those sequential call then the
> bug 
> is fixed.
> Seems a trouble with last status of glBegin(GL_LINE_LOOP) after the same
> call, in case not flushing was done.

Pretty sure this is more or less coincidence, since in this example a single loop fits into the max size of some buffer before it will be flushed internally. Make it bigger and it will still fail.
(Also see https://bugs.freedesktop.org/show_bug.cgi?id=81174 for a related bug and some mroe explanation).
Comment 10 Marek Olšák 2015-08-07 11:07:49 UTC
Please keep the QA contact as mesa-dev, so that we can receive all messages.
Comment 11 Brian Paul 2015-10-17 16:13:43 UTC
This is the same as bug 81174.  I've documented the root issue and fix there.

*** This bug has been marked as a duplicate of bug 81174 ***


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.