Discussion starters for ION session at Linux Plumbers Android+Graphics microconf

[John Stultz]

On 09/05/2013 08:26 PM, Rob Clark wrote:
> On Thu, Sep 5, 2013 at 8:49 PM, John Stultz <john.stultz at linaro.org> 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