Bug 24083 - i965 VBO drawing doesn't flush drawing upon VBO changes
Summary: i965 VBO drawing doesn't flush drawing upon VBO changes
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: All Linux (All)
: medium normal
Assignee: Eric Anholt
QA Contact:
Depends on:
Blocks: 23670
  Show dependency treegraph
Reported: 2009-09-22 08:19 UTC by Brian Paul
Modified: 2009-09-28 11:34 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

test program (2.91 KB, text/x-csrc)
2009-09-22 08:31 UTC, Brian Paul

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Paul 2009-09-22 08:19:38 UTC
In a sequence like this:

create VBO
for (i=0;i<n;i++) {
    load new VBO data
    draw VBO
flush (really draw)

We're not flushing the previous drawing before the VBO contents are changed in the next iteration.  So whatever was last put in the VBO before the flush winds up getting drawn N times.  When we map the VBO to change its contents we need to note that a previous drawing command references the buffer and finish the drawing before allowing the VBO contents to be changed.

The attached program illustrates the problem.
Comment 1 Brian Paul 2009-09-22 08:31:03 UTC
Created attachment 29758 [details]
test program
Comment 2 Eric Anholt 2009-09-28 11:34:43 UTC
commit e8e97c00313b50d50af58c922ba41ecad07e2518
Author: Eric Anholt <eric@anholt.net>
Date:   Thu Sep 24 16:22:30 2009 -0700

    vbo-subdata-sync: New test for bug #23857.

Author: Eric Anholt <eric@anholt.net>
Date:   Thu Sep 24 16:15:52 2009 -0700

    intel: Flush the batch when we're about to subdata into a VBO.
    This fixes the clears in openarena with the new metaops clear code, and
    the new piglit vbo-subdata-sync test.
    Bug #23857.

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.