[Mesa-dev] Request for support of GL_AMD_pinned_memory and GL_ARB_buffer_storage extensions

[Jose Fonseca]

I honestly hope that GL_AMD_pinned_memory doesn't become popular. It would have been alright if it wasn't for this bit in http://www.opengl.org/registry/specs/AMD/pinned_memory.txt which says:

    2) Can the application still use the buffer using the CPU address?

        RESOLVED: YES. However, this access would be completely
        non synchronized to the OpenGL pipeline, unless explicit
        synchronization is being used (for example, through glFinish or by using
        sync objects).

And I'm imagining apps which are streaming vertex data doing precisely just that...

This means that, in order to obtain traces of applications that use AMD_pinned_memory like that with Apitrace, we'll need to use heuristics to determine when applications touch the memory behind the scenes and emit fake memcpies, which means slow tracing and/or bloated trace files... Just like user memory pointer arrays...  :(

Instead of that uglyness, maybe Apitrace should just mask out GL_AMD_pinned_memory support, so that I don't have to worry about it, and let apps and OpenGL drivers support/use it at their own peril.

Jose


----- Original Message -----
> Yes, GL_ARB_buffer_storage is being worked on. We'll support it on all
> Radeon cards R300 and up.
> 
> Anyway, GL_STREAM_DRAW should give you the same behavior as
> GL_CLIENT_STORAGE_BIT on open source Radeon drivers.
> 
> Marek
> 
> On Sun, Nov 24, 2013 at 1:19 PM, Tony Wasserka <neobrainx at googlemail.com>
> wrote:
> > Hello everyone,
> > I was told on IRC that my question would get most attention around here -
> > so
> > bear with me if this is the wrong place to ask
> >
> > I'm one of the developers of the GC/Wii emulator Dolphin. We recently
> > rewrote our OpenGL renderer to use modern OpenGL 3 features, however one
> > thing that we stumbled upon are the lack of efficient (vertex/index) buffer
> > data streaming mechanisms in OpenGL. Basically, most of our vertex data is
> > used once and never again after that (we have to do this for accurate
> > emulation) - so all vertex data gets streamed into one huge ring buffer
> > (and
> > analogously for index data, which uses its own huge ring buffer). For
> > buffer
> > streaming, we have multiple code paths using a combination of
> > glMapBufferRange, glBufferSubData, fences and buffer orphaning, yet none of
> > these come anywhere close to the performance of (legacy) rendering from a
> > vertex array stored in RAM.
> >
> > There are two OpenGL extensions which greatly help us in this situation:
> > AMD's pinned memory [1], and buffer storage[2] in GL 4.4. We currently have
> > no buffer storage code path, but usage of pinned memory gave us a speedup
> > of
> > up to 60% under heavy workloads when working with AMD's Catalyst driver
> > under Windows. We expect the same speedup when using buffer storage
> > (specifically we need CLIENT_STORAGE_BIT, if I recall correctly).
> >
> > So the natural question that arises is: Is either of these two extensions
> > going to be supported in mesa anytime soon or is it of lower priority than
> > other extensions? Also, is the pinned memory extension AMD hardware
> > specific
> > or would it be possible to support it for other hardware, too? I'm not sure
> > if buffer storage (being a GL 4.4 extension, and I read that it might
> > actually depend on some other GL 4.3 extension) is possible to implement on
> > older hardware, yet it would be very useful for us to have efficient
> > streaming methods for old GPUs, too.
> >
> > I hope this mail doesn't sound too commanding or anything, it's just
> > supposed to be a friendly question on improving the emulator experience for
> > our user base
> > Thanks in advance!
> >
> > Best regards,
> > Tony
> >
> > [1]
> > https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/AMD/pinned_memory.txt&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0A&s=ede103da8bd227ae11f6ab3a4a6d6b0c673860dc15b6814055302759bf4ef355
> > [2]
> > https://urldefense.proofpoint.com/v1/url?u=http://www.opengl.org/registry/specs/ARB/buffer_storage.txt&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0A&s=7ceb1af3a41882ca6ba4e13bf3df2c8a59b08441835b05174e93968ef8f580f2
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0A&s=5d44af52ecd36e285eff028b59a928ba327a33c57498a7e5d0a3f8e5e12070a9
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.freedesktop.org/mailman/listinfo/mesa-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=NMr9uy2iTjWVixC0wOcYCWEIYhfo80qKwRgdodpoDzA%3D%0A&m=cv4fRRLbo4swWVoK5KeixmMKacksWBLX%2Bi4XDCp0aDI%3D%0A&s=5d44af52ecd36e285eff028b59a928ba327a33c57498a7e5d0a3f8e5e12070a9
>