[Linaro-mm-sig] Memory Management Discussion

[Marcus Lorentzon]

On 04/20/2011 02:23 PM, Tom Cooksey wrote:
>> On Wed, Apr 20, 2011 at 8:25 AM, Arnd Bergmann<arnd at arndb.de>  wrote:
>>      
>>> On Wednesday 20 April 2011 03:52:53 Clark, Rob wrote:
>>>        
>>>>  From DRI perspective.. I guess the global buffer name is restricted
>>>> to a 4 byte integer, unless you change the DRI proto..
>>>>          
>>> I still like the idea of using file handles to pass the buffers
>>> between kernel subsystems. Maybe there could be an ioctl to encapsulate
>>> a buffer from DRI in a file so we can give it to another subsystem,
>>> and/or an ioctl to register a buffer from a file handle with DRI.
>>>        
>> That's been the original design of gem, i.e. using fd handles (and
>> perhaps even passing them around in unix domain sockets). There's one
>> small problem with that approach: You're quickly running out of fds
>> with the linux default limit of 1024. Hence the roll-your-own approach.
>>      
> There's a big difference between GEM and what we're trying to do. GEM is
> designed to manage _all_ buffers used by the graphics hardware. What I
> believe we're trying to do is only provide a manager which allows buffers
> to be shared between devices. Of all the buffers and textures a GPU needs
> to access, only a tiny fraction of them need to be shared between devices
> and userspace processes. How large that fraction is I don't know, it might
> still be approaching the 1024 limit, but I doubt it...
>    

Why is it that everyone want it to be fds? It just put requirements on 
dup-ing the fds on IPC instead of sending a simple int. What is wrong 
with the GEM FLINK names? In STE HWMEM we use the same concepts as GEM 
with local device ids for buffers and exported global names (since we 
also planned to merge HWMEM with GEM when time permits). But kernel 
ioctl API is just one piece. Then we have a kernel internal API for 
other devices to use, like V4L2 drivers. These can then just use the 
global GEM FLINK name as input in a "register_gem_buffer_ioctl". Then 
the driver resolve and check rights for this name/buffer on 
register/import. And adding some in kernel API to GEM for resolving 
buffers from global names shouldn't need any big breaking changes or new 
revs of ioctl API.

But then we have platforms like Android that use fds as part of their 
buffer security model (binder-dup(fd), like pipes). To support this, 
drivers need to add an extra ioctl for exporting a local buffer handle 
to a fd (as we allow in HWMEM). But maybe Android will change their 
model once we have this Unified manager in Linaro/ARM (which could be an 
extended GEM). Of course we also need some way to disable the 
"autenticate and get access to all flinked buffers" feature (unless I 
misunderstood that). But since Android abstract this in a HAL layer, 
each driver could have their own ioctls for these fd exports (but I 
prefer a common API). In HWMEM we also added a more granular security 
model, where the buffer allocator can set global &| per process rights 
in form of Read/Write/Import on each buffer.

And for the 1024 limit, I don't think the backbuffers or shared textures 
need to be device-to-device capable. GEM should be fine, since this 
sharing is just inter process, but same device (as already proven in DRI 
& Wayland).
> So, the buffers we're interested in sharing between different processes
> and devices are:
>
> * Decoded video buffers (from both cameras&  video decoders)
> * Window back-buffers
> * System-wide theme textures and font glyph caches
>
> ... Anyone know of other candidates?
>    
The only buffers I can think of are V4L2 <-> DRM, multimedia & graphics. 
But that also include GEM buffers targeted for video encode and misc 
V4L2 mem2mem devices.

/BR
/Marcus