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

Tony Wasserka neobrainx at googlemail.com
Thu Nov 28 08:18:16 PST 2013


Hi Tim,
I've given your suggestion some thought - and while it looks like 
something which would work, my time schedule currently is too tight 
(regardless of money involved) to implement support for the extension. I 
might think about it again in three months, if the extension has not 
been implemented by then by someone else. Thanks for bringing this up 
though, it definitely would've been an option that I hadn't thought of, 
if only I had any time to spend on it :)

Best regards,
Tony



Am 25.11.2013 22:45, schrieb Timothy Arceri:
> Hi Tony,
>
> I'm not one of the main Mesa devs just an independent developer that 
> works on Mesa in my spare time. All I can suggest is you have a go at 
> implementing the features yourself. You obviously have a lot of talent 
> and I'm sure you would be able to accomplish the task. If time is an 
> issue there is a lot of interest in the Linux community for improving 
> Mesa and I myself have run two successful crowd funding campaigns to 
> be able to support some full time work on Mesa. See: 
> http://www.indiegogo.com/projects/improve-opengl-support-for-the-linux-graphics-drivers-mesa/x/2053460
> Maybe you could do something similar. If you do decide to do this I 
> find its useful to start working on the extension (showing work on 
> github etc) before running the campaign as people like to be sure you 
> can accomplish what you are promising.
> Anyway this is just an option for you to think about.
>
> Tim
>
>
> On Sunday, 24 November 2013 11:57 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] http://www.opengl.org/registry/specs/AMD/pinned_memory.txt
> [2] http://www.opengl.org/registry/specs/ARB/buffer_storage.txt
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org <mailto:mesa-dev at lists.freedesktop.org>
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20131128/40c8878f/attachment.html>


More information about the mesa-dev mailing list