glMapBuffer vs. client-stored datas

Started by
4 comments, last by DELETE_MY_ACCOUNT 16 years, 12 months ago
Hi, I'm playing with vertex buffer objects, and am comparing mapped buffer and client-stored buffers. For a mapped buffer, I call glBufferData() with NULL avoid sync problems, then I call glMapBuffer(), fill the buffer, then unmap it. It works perfectly, 390fps with a single textured quad on a Radeon X200M. For a client-stored buffer, I create a buffer (new float[foo]), fill it, then call glBufferData(). It works too, with more than 470fps for the same scene. On this scene, VBO is STATIC_DRAW, and of course, is never modified. I thought client-stored buffer was useful only for frequently modified datas, but it seems there are faster anyway. Does anyone knows why I should use mapped buffer, except to avoid datas in main memory ? Thanks.
Advertisement
Hi Galdor,

I could not tell you a great deal about your question exactly.

However, from what I hear and read, I think it's unreasonable to be able to benchmark any application using "1 quad".

I think you should try this again, with a few hundred or even a thousands, and run several times, before you can have any kind of frame rate comparison.

Try something a little more intensive, and let us know the results [wink]
----------------------------------------Now just hit that link that says 'Rate This User' [wink]
I tested with the stanford bunny, 8100 tris, and have the same perfs (33fps on x200m), but this bunny has no index buffer, perhaps there's something related.

Anyway, I find this a bit strange.
I find it strange too and unexpected. Mapping a buffer and filling it should be no different then glBufferData. Even using glBufferSubData should yeild same results.
Do you have up to date drivers?

It really depends on how ATI has coded their drivers. Perhaps they use glMapBuffer as a hint instead of actually looking at STATIC_DRAW
Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);
Quote:Original post by Galdor
Hi,

I'm playing with vertex buffer objects, and am comparing mapped buffer and client-stored buffers.

For a mapped buffer, I call glBufferData() with NULL avoid sync problems, then I call glMapBuffer(), fill the buffer, then unmap it. It works perfectly, 390fps with a single textured quad on a Radeon X200M.

For a client-stored buffer, I create a buffer (new float[foo]), fill it, then call glBufferData(). It works too, with more than 470fps for the same scene.

On this scene, VBO is STATIC_DRAW, and of course, is never modified.

I thought client-stored buffer was useful only for frequently modified datas, but it seems there are faster anyway.

Does anyone knows why I should use mapped buffer, except to avoid datas in main memory ?

Thanks.


I don't think you really understand what's going on here. In both versions, you are not using client-side memory at all. When you unmap, data gets copied to some part of GPU-accessible memory. However, the same thing happens with glBufferData. Even more so, you can delete your own buffer (the one you allocated with new) immediately thereafter. In fact, I can't really explain the difference in framerate, but as darren_mfuk pointed out, one quad isn't really up to the test either. It could be pretty much anything, even external factors.
I use the term "client-side" to mark the difference with mapped memory, I know how vbo's content is stored.

For the drivers, they are Linux driver 8.35.5, I would'nt be surprized if they are clumsy (ATI+linux+mobile card = shit, nothing new).

This topic is closed to new replies.

Advertisement