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