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

[Rob Clark]

On Fri, Sep 6, 2013 at 1:06 AM, John Stultz <john.stultz at linaro.org> wrote:
> 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. :)
>

ahh, ok, that would explain it ;-)

>
>> "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.

for a "pure GEM" (ie. not TTM) driver, drm_gem_get_pages() is where
actual pages get allocated.  This is triggered by various things
(faulting in page for userspace access, dmabuf map_attachment, etc)

BR,
-R

> 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
>
>
>