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

[Jose Fonseca]

----- Original Message -----
> On 05.02.2014 18:08, Jose Fonseca wrote:
> > 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
> > 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=pA%2FnK9X3xx0wAlMUZ24PfQ1mW6wAMdTUujz%2Bx7LRwCA%3D%0A&s=ebbe1f51deb46c81578b3c125b16e31b5f4b28c1d47e283bc9ef588e2707024d
> > 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...
> >
> 
> I don't understand your concern, this is exactly the same behavior
> GL_MAP_UNSYCHRONIZED_BIT has, and apps are supposedly using that
> properly. How does apitrace handle it?

GL_AMD_pinned_memory it's nothing like GL_ARB_map_buffer_range's GL_MAP_UNSYCHRONIZED_BIT:

- When an app touches memory returned by glMapBufferRange(GL_MAP_UNSYCHRONIZED_BIT) it will communicate back to the OpenGL driver which bytes it actually touched via the glFlushMappedBufferRange (unless the apps doesn't care about performance and doesn't call glFlushMappedBufferRange at all, which is silly as it will force the OpenGL driver to assumed the whole range changed)

  In this case, the OpenGL driver (hence apitrace) should get all the information it needs about which bytes were updated betwen glMap/glUnmap.

- When an app touches memory bound via GL_AMD_pinned_memory outside glMap/glUnmap, there are be _no_ hints whatsever.  The OpenGL driver might not care as the memory is shared between CPU and GPU, so all is good as far is it is concerned, but all the changes the app does are invisible at an API level, hence apitrace will not be able to catch them unless it does onerous heuristics.


So while both extensions allow unsynchronized access, but lack of synchronization is not my concern. My concern is that GL_AMD_pinned_memory allows *hidden* access to GPU memory. 


Jose