Bug 24083

Summary: i965 VBO drawing doesn't flush drawing upon VBO changes
Product: Mesa Reporter: Brian Paul <brian.e.paul>
Component: Drivers/DRI/i965Assignee: Eric Anholt <eric>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium    
Version: git   
Hardware: All   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Bug Depends on:    
Bug Blocks: 23670    
Attachments: test program

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.