Mapping a VBO more than once per frame

[markfcsl]

In my VBO code, I generate 4 ARRAY_BUFFER VBOs of 256Kb each, which I use to stream dynamic vertex data into. I set these up with GL_STREAM_DRAW_ARB usage.

I don't know what the new vertex data is in advance, so I can't use BufferSubData, but instead use MapBuffer.

Each VBO has a wrapper over it indicating how much of it has been written to, so when MapBuffer is called, I offset the returned pointer to where I am allowed to write, and update that offset when UnmapBuffer is called. This MapBuffer/UnmapBuffer pairing, with writes, could happen multiple times in a frame, on the same VBO.

However, I've noticed that using this approach causes a varying amount of corruption in the rendered geometry.

Under the VBO specs, it mentions that a PRESERVE/DISCARD option isn't really necessary.

So I'm wondering whether whenever you call MapBuffer, is any of the data already in the buffer preserved? or discarded?

I'm leaning towards thinking it's the latter (for speed), which would explain the corruption I'm seeing.

Has anyone else looked at anything like this? Or is it assumed that you'd only map any VBO at most once in any frame?


Cheers,


Mark

[Tom Nuydens]

Are you checking the return of glUnmapBufferARB()? It returns false if the data is lost, in which case you are required to respecify it.

-- Tom

[markfcsl]

Yes. It never returns GL_FALSE. If it does, I send out a debug message and then respecify the VBO with a NULL pointer data to glBufferDataARB, but I've never seen that happen.

I should say that I'm seeing the same thing on both a GeForce and a Radeon card, so I'm pretty sure it's my use of VBOs that is in the wrong.

Does anyone else use shared VBOs for streaming like me, or do each of their dynamic geometries have a streaming VBO (maybe 2 for double buffering)?

(I won't be able to post an example either as it's company code.)


Mark

[markfcsl]

OK, so I just did the obvious thing and looked at the memory at the pointer returned by MapBuffer under a debugger. This may be an unfair test as it's not running in realtime anymore, but heck.

Anyway, the vertex data written to the VBO seems to be preserved across calls to MapBuffer in the same frame. This was on a GeForce4 Ti4600 with latest drivers.

I guess it could be a buffering issue now...


Mark

[markfcsl]

OK, so ignore this post now... it did turn out to be my use of VBOs.

My test data that was failing contained static color and texture coordinates, as well as dynamic positions and normals, but I was updating which VBO the static stream was using rather than the dynamic stream!

Do'h.

[cass]

Just to clarify, you should *not* expect to see data preserved when you map a VBO. This is a mechanism that allows the driver to rename the buffer. If any data is preserved, it is merely coincidence. Don't expect it to always be that way.

Thanks -
Cass

[markfcsl]

Cass,

So the approach I've taken, where I can possibly map the same VBO more than once per frame, and expect the data to be there, is inherently flawed?


Mark

[CybeRUS]

IMHO, by my tests, for best perfomance to render dynamic data(for example Skinned Mesh) you need:
Init (one time at start application):
GenBuffer(1,&ID);

Render (each render cycle):
for each objects {
BindBuffer(...,ID);
BufferData(...,size_of_data_for_object, NULL, ...); // Alloc new memory, it's fast when pMem == NULL
MapBuffer(...);
FillBuffer(...);
UnmapBuffer(..);
RenderObject(...);
};

glBufferDataARB allow fast MapBuffer operation, because it's don't wait for sync from render previeus object and allow async write to video memory and render.
ARB memory manager will delete buffer of previeus object when it finish rendering.

Some time ago i wrote same manager for VAR extensions with fence sync for mem blocks, it work very well, and i see same perfomance for VBO. I think it's same algorithms.

[Ysaneya]

That's a very interesting trick. But are you sure there's really a performance improvement when you do a "NULL" BufferData call ? Did you make a comparison ? If so, what were the results ?

Y.

[Korval]

Is this implementation specific? It is always a speed-up, or just for the particular card/driver combo you're using?