[Linaro-mm-sig] Memory Management Discussion

Tom Cooksey Tom.Cooksey at arm.com
Wed Apr 20 12:23:18 UTC 2011



> -----Original Message-----
> From: linaro-mm-sig-bounces at lists.linaro.org [mailto:linaro-mm-sig-
> bounces at lists.linaro.org] On Behalf Of Daniel Vetter
> Sent: 20 April 2011 07:56
> To: Arnd Bergmann
> Cc: linaro-mm-sig at lists.linaro.org
> Subject: Re: [Linaro-mm-sig] Memory Management Discussion
>
> 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...

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?

I guess the bottleneck will probably be the window compositor, as it will
need to have a reference to all window back buffers in the system. So, do
any of the DRI folks have any idea how many windows (with back buffers) a
typical desktop session has? Do minimised windows have back buffers
allocated in X11?

Even if there were as many as 100 top-level windows (which seems excessive),
each triple-buffered, that's still pretty far from the 1024 limit?


Cheers,

Tom



-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.




More information about the Linaro-mm-sig mailing list