[Linaro-mm-sig] Memory Management Discussion

[Marcus Lorentzon]

On 04/20/2011 05:35 PM, Daniel Vetter wrote:
> On Wed, Apr 20, 2011 at 5:29 PM, Marcus Lorentzon
> <marcus.xm.lorentzon at stericsson.com>  wrote:
>    
>> 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).
>>      
> That's a rather important thing. GEM is _only_ for buffer objects of
> one device, no device-device sharing possible.
> Dave Airlie wrote a proof-of-concept for that to enable
> runtime-switchable graphics (where the add-on gpu
> blits to the scanout buffer of the integrated gpu when running):
>
> http://airlied.livejournal.com/71734.html
>    

Where you just emphasizing GEM is _currently_ only for single device, 
which I understand. Or are you also saying it will not be possible to 
extend GEM FLINK names to be airlied PRIME names without messing up 
current behavior of GEM? If so, maybe there's actually a point for a new 
DRM isolated memory manager like HWMEM (which just needed a few lines of 
code anyway to integrate with KMS).

My view has always been that I prefer an isolated memory manager that 
can be used by multiple DRM drivers and V4L2 drivers (like HWMEM and 
some other similar ARM MMs). But maybe GEM doesn't want to fit that target?

Am I right if I say GEM only have 3 standard ioctls, FLINK, OPEN, CLOSE? 
If so, a second implementation/variation of "GEM API" could use the same 
namespace for FLINK names across devices and still be called GEM? Just 
probing GEM ground to see what could be "fixed" in GEM and what is 
written in stone.

What seems clear from Linaro is that we need V4L2<->DRM buffer sharing. 
But I don't think anyone has requested DRM<->DRM sharing like PRIME. But 
a common Linaro embedded & x86 desktop solution probably needs that. The 
simplification here is that V4L2-x<->single DRM sharing could be easier 
to implement than full DRM-0<->DRM-1<->V4L2-x sharing. Since the DRM 
driver itself could expose the device memory sharing API in kernel, make 
GEM believe it's still single device.

Or maybe just a kernel shared name space where DRM/V4L2/CMA drivers 
register/resolve exported buffers is easier and more flexible (no 
DRM/GEM specifics in buffer sharing). Since allocation ioctl is anyway 
driver specific, adding a "register_global_buffer" ioctl could also be 
made to work like any normal GEM allocation, just give it a global name 
instead of size. Like an in kernel hub for sharing memory buffers 
between devices independent of allocators and users.

/BR
/Marcus