Jump to content
  • Advertisement
Sign in to follow this  
Galdor

glMapBuffer vs. client-stored datas

This topic is 4168 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!