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

Jose Fonseca jfonseca at vmware.com
Wed Feb 5 10:26:05 PST 2014


Yes, precisely.

Jose

----- Original Message -----
> My understanding is that this is like having MAP_UNSYNCHRONIZED on at all
> times, even when it isn't "mapped", because it is always mapped (into
> memory). Is that correct Jose?
> 
> Patrick
> 
> 
> On Wed, Feb 5, 2014 at 11:53 AM, Grigori Goronzy <greg at chown.ath.cx> wrote:
> 
> > 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=vU0qdyo0bT3OlrdDiNzEDE1rwoALRno8drdsy3dobcI%3D%0A&s=0068372b93924b1324d4b77b80c5deec67683c1a59a9b2e91255c5a041603274
> >> 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?
> >
> > Grigori
> >
> > _______________________________________________
> > 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=vU0qdyo0bT3OlrdDiNzEDE1rwoALRno8drdsy3dobcI%3D%0A&s=5f37c510dc241c96f7f1918728b86768c5ad61c70a9281e5b46a460197cec9ee
> >
> 


More information about the mesa-dev mailing list