Graphics memory management in ARM/Embedded Linux
tomcooksey at gmail.com
Wed Apr 20 09:09:19 PDT 2011
On Wed, Apr 20, 2011 at 2:01 PM, Tiago Vignatti <tiago.vignatti at nokia.com>wrote:
> Hi Tom,
> On 04/20/2011 03:39 PM, ext Tom Cooksey wrote:
>> Hi All,
>> Please excuse the spam... just trying to spread the word: Linaro is
>> currently developing a graphics memory manager for Linux which allows
>> buffers to be shared between different devices and different processes.
>> On ARM SoCs, many different hw devices need to access the same buffer
>> (which E.g. GEM doesn't support). As a simple example, a GPU needs to
>> write to a buffer which a display controller reads from. At least in
>> ARM-Linux land, this is a fairly hot-topic and a dedicated mailing list
>> has been created to discuss different requirements, figure out if
>> TTM/GEM can be adapted, etc.
>> The mailing list is here:
> DRI community has basically the same purpose and, as we said before, this
> is pretty much a nice subject to discuss there. What's the idea for creating
> a new mailing list for instance?
The same could be said about the V4L2 or fbdev mailing lists, or even the
linux-mm mailing list. I think that's kinda the point: the audience of the
DRI mailing list is too focused on graphics, the V4L2 mailing list too
focused on video. Having a seperate mailing list establishes neutral ground
for everyone. Though personally I think a mail thread with all interested
mailing lists on CC would have worked just as well (though may have started
> There's also a wiki page gathering requirements here:
> this document doesn't mention anything like contributing back to Linux
> mainline and current graphics APIs. So this is smelling like an actual fork
> of community...
> I hope I'm understanding it wrongly though!
As this is being driven by Linaro, it is by definition intended to be pushed
up-stream. Linaro doesn't do work not destined for upstream. It's like their
"prime directive". :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel