On 04/20/2011 05:35 PM, Daniel Vetter wrote:
On Wed, Apr 20, 2011 at 5:29 PM, Marcus Lorentzon marcus.xm.lorentzon@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.
/BR /Marcus