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
One observation that doesn't answer your question: this is a weird
data arrangement. Interleaving the data in a VBO can buy you better
cache locality. If you're going to offset the colors behind the
vertices and normals, you might as well use a separate VBO for the
colors. This will make for simpler offset/stride logic.
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 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?
glBSD isn't asynchronous. The only way to do asynchronous updates of
a VBO is to use Apple's flush buffer range extension. This extension
leverages the mapping interface to VBOs.
If anything, map/unmap has the potential to be faster. In practice,
however, I haven't observed map/unmap faster than BSD.
For more context on the surrounding code using the color array, see
(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
_______________________________________________
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
