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. :) > "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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
