[1/5] WineD3D: Revert the GL usage confusion

[Roderick Colenbrander]

On Tue, Dec 22, 2009 at 5:08 PM, Roderick Colenbrander
<thunderbird2k at gmail.com> wrote:
> On Tue, Dec 22, 2009 at 4:51 PM, Stefan Dösinger <stefan at 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