On Tue, Dec 22, 2009 at 5:08 PM, Roderick Colenbrander thunderbird2k@gmail.com wrote:
On Tue, Dec 22, 2009 at 4:51 PM, Stefan Dösinger stefan@codeweavers.com wrote:
We had a discussion in wine-devel a few days ago about which GL usage is better. The red book also agrees with the GL wiki, but the GL 3.0 spec uses the confusing language the extension used.
In my performance testing there is no difference, which suggests that this is a rather academic issue, unless you happen to run a game that is exactly hitting your card's bus transfer limits and/or video memory limits, but not the CPU and GPU ALU performance limits.
I'm not convinced the code should be changed back. All docs mention to use DYNAMIC_DRAW. On some implementations there might be a difference. I don't see a reason to change it. Did you get a response on the question you submitted to opengl.org? From what I understood the main difference between STREAM_DRAW and DYNAMIC_DRAW is that in case of dynamic, system memory which can be accessed using DMA is used and else this guarantee isn't given. I would keep it at the value which is correct as indicated by all documentation. If you want to change it, tests should be carried out on different drivers and GPUs OR wait for the feedback from opengl.org/
Roderick
Just from the VBO docs, something similar is in the PBO ones and the red book: STREAM_DRAW_ARB The data store contents will be specified once by the application, and used at most a few times as the source of a GL (drawing) command. DYNAMIC_DRAW_ARB The data store contents will be respecified repeatedly by the application, and used many times as the source for GL (drawing) commands.
I think the website you refer to mixes these two up,
I talked a bit to Eric Anholt (Intel) about buffer objects in case of their drivers. In case of Intel the drivers ignore the usage flags altogether and just use DMA memory (likely because the GPUs only use system memory). They do care about the GL_READ_ONLY / GL_WRITE_ONLY flags passed to glMapBuffer. GL_WRITE_ONLY can be quite efficient on their drivers.
In general I think even when you need conversion that just calling glBufferSubData or glMapBuffer + memcpy + glUnmapBuffer in combination with a VBO might still help a lot.
Roderick