On Fri, Sep 6, 2013 at 1:06 AM, John Stultz <john.stultz@xxxxxxxxxx> wrote: > On 09/05/2013 08:26 PM, Rob Clark wrote: >> On Thu, Sep 5, 2013 at 8:49 PM, John Stultz <john.stultz@xxxxxxxxxx> 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 > > > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
