Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

glBufferSubData vs. glMapBuffer



Hello,

I see peculiar behavior on Intel builds when using glBufferSubData to update just the color data in a VBO. (This is on a Mac Pro with a GeForce 7300 GT. Disabling VBOs eliminates the artifacts, running the PowerPC build under Rosetta on the same machine or on a native PPC Macintosh eliminates the artifacts, as well.)

The model looks fine, so the vertex and normal data do not appear to be affected. When initially filling the VBO with the vertex, normal, and color data, everything appears fine. (The vertex and normals are interleaved, followed by the colors, which are 3 GL_FLOATs.) However, when changing the color with glBufferSubData, a section of the color at the end of the color data is not updated, and left whatever color was filled in the initial construction, and a section of the color at the beginning is shifted with (r,g,b) showing as (g,b,r). I double-checked the offset, size, and data being passed to glBufferSubData.

Anyone else see anything like this?

If I replace the glBufferSubData call and use glMapBuffer instead to update the color data, the problem disappears.

#if 0
 glBufferSubDataARB(GL_ARRAY_BUFFER_ARB, colorOffset, colorSize, colorArray);
#else
 GLubyte* dest = glMapBufferARB(GL_ARRAY_BUFFER_ARB, GL_WRITE_ONLY_ARB);
 dest += colorOffset;

 for (int i = 0; i < fNumVertices; i++) {
   *(ColorArrayElement*)dest = colorArray[i];
   dest += sizeof(ColorArrayElement);
   }
		
 GLboolean success = glUnmapBufferARB(GL_ARRAY_BUFFER_ARB);
 assert(success);
#endif

What should that tell me? I would have expected those calls to be equivalent, so I must be misunderstanding something.  Does the glBufferSubDataARB require some additional synchronization? (Wrapping glBufferSubDataARB with glFlush or glFinish as a test did not eliminate the artifacts.)

The artifact is shown at

 http://www.PacificT.com/glBufferSubDataArtifact/

The sphere was initially all red, correctly, then  glBufferSubData was called to update the colors to all green. The top portion at the end of the buffer was not touched. The middle portion was updated correctly. The initial portion of the buffer was touched, but appears to be shifted.

Since using glMapBufferARB appears to work fine, is there any advantage to diagnosing and fixing the problem with glBufferSubDataARB? Would one expect glBufferSubDataARB to be faster? Asynchronous?

For more context on the surrounding code using the color array, see

<http://lists.apple.com/archives/mac-opengl/2004/Sep/msg00124.html>

(This new problem does not appear to be related to that one, which was resolved at the time, though it is in the same code.)

- Ron
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Mac-opengl mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/mac-opengl/email@hidden

This email sent to email@hidden

References: 
 >Re: Interesting catch-up behaviour with GL multi-threading (From: Christopher Hunt <email@hidden>)
 >Re: Interesting catch-up behaviour with GL multi-threading (From: John Rosasco <email@hidden>)
 >Re: Interesting catch-up behaviour with GL multi-threading (From: Christopher Hunt <email@hidden>)
 >Re: Interesting catch-up behaviour with GL multi-threading (From: Jean-Francois Roy <email@hidden>)
 >Re: Interesting catch-up behaviour with GL multi-threading (From: John Rosasco <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.