On 04/20/2011 02:23 PM, Tom Cooksey wrote:
On Wed, Apr 20, 2011 at 8:25 AM, Arnd Bergmannarnd@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