🔒 Locked

Discarding VBO data with BufferData

Started by Promit Jan 12, 2005 at 12:08 PM 2 replies 1.1k views

Original Post

Jan 12, 2005 at 12:08 PM

I have an option in my low level rendering layer to specify that a buffer may be discarded on lock. This is pretty straightforward in D3D, but I'm unsure if manually invoking BufferData with a NULL pointer is beneficial. The D3D docs mention that doing so may help prevent a DMA stall. Is the same true for OGL? I'm not noticing any performance difference, but then again, I'm not dynamically locking buffers at the moment, either. The buffer is already sized once at load by a BufferData call. I don't want the new BufferData call to force the driver to allocate new memory, I just want to indicate that new memory may be used, if desired.

Quote:
GL_ARB_vertex_buffer_object specs Should there be a PRESERVE/DISCARD option on BufferSubDataARB? On MapBufferARB? RESOLVED: NO, NO. ATI_vertex_array_object had this option for UpdateObjectBufferATI, which is the equivalent of BufferSubDataARB, but it's unclear whether this has any utility. There might be some utility for MapBufferARB, but forcing the user to call BufferDataARB again with a NULL data pointer has some advantages of its own, such as forcing the user to respecify the size.

This seems kind of vague to me.

ogracian

Jan 12, 2005 at 12:27 PM

Hi,

I suggest take a look at the following doc from NVIDIA, it contains valuable information regarding to VBO's.

http://www.nvidia.com/object/using_VBOs.html

Hope this helps you,
Oscar

_the_phantom_

Jan 12, 2005 at 12:38 PM

the wonderfull thing about the OpenGL specs is that alot of stuff is just hints, calling glBufferData() with a NULL pointer is a hint to the driver that you wont be reusing the data so it is free to discard it at will.

Now, depending on the state of rendering this may or may not have an effect. If the buffer you are freeing ISNT being rendered from then the buffer can just be overwritten and done with, however if it IS being written to then the driver can grab new memory, assign it to that buffer ID and copy into it avoiding stalls for sync issues.

As noted all this is optional however NV and ATI both advise using this system so its fair to say they both take the hint.

The reason you might not be seeing and difference is simply because its not a stall point, due to syncing issue, in your app.

Promit

Jan 12, 2005 at 1:13 PM

Thanks to both of you.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.