[Linaro-mm-sig] Memory Management Discussion
marcus.xm.lorentzon at stericsson.com
Wed Apr 20 16:31:57 UTC 2011
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):
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.
More information about the Linaro-mm-sig