From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Stultz Subject: Re: Discussion starters for ION session at Linux Plumbers Android+Graphics microconf Date: Thu, 05 Sep 2013 22:06:52 -0700 Message-ID: <522962EC.9030506@linaro.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by gabe.freedesktop.org (Postfix) with ESMTP id C459EE5DCB for ; Thu, 5 Sep 2013 22:06:55 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id w10so2740087pde.23 for ; Thu, 05 Sep 2013 22:06:55 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: Android Kernel Team , Laurent Pinchart , "dri-devel@lists.freedesktop.org" List-Id: dri-devel@lists.freedesktop.org On 09/05/2013 08:26 PM, Rob Clark wrote: > On Thu, Sep 5, 2013 at 8:49 PM, John Stultz wrote: >> Hey everyone, >> In preparation for the Plumbers Android+Graphics microconf, I wanted to >> send out some background documentation to try to get all the context we can >> out there prior to the discussion, as time will be limited and it would be >> best to spend it discussing solutions rather then re-hashing problems and >> requirements. >> >> I'm sure many folks on this list could probably do a better job summarizing >> the issues, but I wanted to get this out there to try to enumerate the >> problems and the different perspectives on the issues that I'm aware of. >> >> The document is on LWN here: >> http://lwn.net/SubscriberLink/565469/9d88daa2282ef6c2/ > oh, I had missed that article.. fwiw It was published just moments before I sent out this thread, so I wouldn't have expected anyone to have seen it yet. :) > "Another possible solution is to allow dma-buf exporters to not > allocate the backing buffers immediately. This would allow multiple > drivers to attach to a dma-buf before the allocation occurs. Then, > when the buffer is first used, the allocation is done; at that time, > the allocator could scan the list of attached drivers and be able to > determine the constraints of the attached devices and allocate memory > accordingly. This would allow user space to not have to deal with any > constraint solving. " > > That is actually how dma-buf works today. And at least with GEM > buffers exported as dma-buf's, the allocation is deferred. It does > require attaching the buffers in all the devices that will be sharing > the buffer up front (but I suppose you need to know the involved > devices one way or another with any solution, so this approach seems > as good as any). We *do* still need to spiff up dev->dma_parms a bit > more, and there might be some room for some helpers to figure out the > union of all attached devices constraints, and allocate suitable > backing pages... so perhaps this is one thing we should be talking > about. Ok. I had gone looking for an example of the deferred allocation, but didn't find it. I'll go look again, but if you have a pointer, that could be useful. So yea, I do think this is the most promising approach, but sorting out the next steps for doing a proof of concept is one thing I'd like to discuss (as mentioned in the article, via a ion-like generic allocator, or trying to wire in the constraint solving to some limited set of drivers via generic helper functions). As well as getting a better understanding the Android developers concern about any non-deterministic cost of allocating at mmap time. Thanks for the feedback and thoughts! I'm hopeful some approach to resolving the various issues can be found, but I suspect it will have a few different parts. thanks -john