Potential problem with glMapBuffer

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Potential problem with glMapBuffer

chrtom
I've recently recognized that my JOGL programs slow down significantly over time. After analyzing my code I found that calls to glMapBuffer seem to be the source of the slow down.

I've prepared a minimalistic test case. It basically sets up a VBO with space for 3 float values. In the display method I do nothing else than mapping the VBO and writing 3 float values to it; no actual rendering takes place. I do this 100 times per frame to make the slow down noticeable more quickly.

When you run the test case you will see that the rendering time per frame increases significantly within less than a minute. If tested on Windows 7 (64bit), Ubuntu 13.04 (64bit) with both NVIDIA and AMD cards.

A work-around to the problem is to NOT use glMapBuffer, and instead use glBufferData to create a new buffer with the new data.

I'd appreciate if the JOGL maintainers could look into this and advise me if I'm doing something wrong or maybe fix the problem if it's on the JOGL side.

Thanks a lot!

GlMapBufferTest.java
Reply | Threaded
Open this post in threaded view
|

Re: Potential problem with glMapBuffer

Sven Gothel
Administrator
On 06/12/2013 11:59 AM, chrtom [via jogamp] wrote:

> I've recently recognized that my JOGL programs slow down significantly over
> time. After analyzing my code I found that calls to glMapBuffer seem to be the
> source of the slow down.
>
> I've prepared a minimalistic test case. It basically sets up a VBO with space
> for 3 float values. In the display method I do nothing else than mapping the
> VBO and writing 3 float values to it; no actual rendering takes place. I do
> this 100 times per frame to make the slow down noticeable more quickly.
>
> When you run the test case you will see that the rendering time per frame
> increases significantly within less than a minute. If tested on Windows 7
> (64bit), Ubuntu 13.04 (64bit) with both NVIDIA and AMD cards.
>
> A work-around to the problem is to NOT use glMapBuffer, and instead use
> glBufferData to create a new buffer with the new data.
>
> I'd appreciate if the JOGL maintainers could look into this and advise me if
> I'm doing something wrong or maybe fix the problem if it's on the JOGL side.
>
> Thanks a lot!
>
> GlMapBufferTest.java <http://forum.jogamp.org/file/n4029376/GlMapBufferTest.java>
Thank you for your test case.
Indeed .. glMapBuffer impl. - especially the memory trace, was earmarked for
review.

~Sven



signature.asc (911 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Potential problem with glMapBuffer

gouessej
Administrator
I just hope we won't keep any reference on the direct NIO buffers when unmapping them so that they can be safely destroyed. This is very important. I used glMapBuffer some years ago for very large meshes with a hierarchical cache; if the destruction of direct NIO buffers becomes impossible, its implementation becomes a lot harder, you end up by having to handle the fragmentation by yourself :(
Julien Gouesse | Personal blog | Website