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

[Ian Romanick]

On 02/05/2014 11:10 AM, Jose Fonseca wrote:
> 
> 
> ----- Original Message -----
>>
>>
>> ----- 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.
> 
> Just for the record, the challenges GL_AMD_pinned_memory presents to Apitrace are much similar to the old-fashioned OpenGL user array pointers: an app is free to change the contents of memory pointed by user arrays pointers at any point in time, except during a draw call.  This means that before every draw call, Apitrace needs to scavenge all the user memory pointers and write their contents to the trace file, just in case the app changed it..
> 
> In order to support GL_AMD_pinned_memory, for every draw call Apitrace would also need to walk over bound GL_AMD_pinned_memory (and nowadays there are loads of bound points!), and check if data changed, and serialize in the trace file if it did...
> 
> 
> I never care much about performance of Apitrace with user array pointers: it is an old paradigm; only old apps use it, or programmers which don't particular care about performance -- either way, a performance conscious app developer would use VBOs hence never hit the problem at all.  My displeasure with GL_AMD_pinned_memory is that it essentially flips everything on its head -- it encourages a paradigm which apitrace will never be able to handle properly. 
> 
> 
> People often complain that OpenGL development tools are poor compared with Direct3D's.  An important fact they often miss is that Direct3D API is several orders of mangnitude tool friendlier: it's clear that Direct3D API's cares about things like allowing to query all state back, whereas OpenGL is more fire and forget and never look back -- the main concern in OpenGL is ensuring that state can go from App to Driver fast, but little thought is often given to ensuring that one can read whole state back, or ensuring that one can intercept all state as it goes between the app and the driver...
> 
> 
> In this particular case, if the answer for "Can the application still use the buffer using the CPU address?" was a NO, the world would be a much better place.

I suspect the reason that they didn't do that is it would imply a very
expensive validation step at draw time.  There are a whole bunch of
technologies in newer GL implementations that will make tracing a
miserable prospect. :(

> Jose
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev