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 "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. At any rate, it might not matter if ION cannot import dma-buf's (as long as every other device importing does not have to differentiate between importing dma-buf's that are also ION buffers vs dma-buf's allocated in some other way). But to be useful upstream, we'd have to ensure that existing drm drivers can somehow plug-in their existing allocation mechanisms in to ION. BR, -R > But I wanted to start a discussion thread here, since the LWN comment > threads (while *much* better then most comment sections) aren't really the > right place for this sort of thing. > > So please feel free to reply to correct any inaccuracies in my summary, > provide your thoughts on the various proposed solutions, or suggest new > solutions that we should also discuss at the micro-conference! > > thanks > -john > > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > http://lists.freedesktop.org/mailman/listinfo/dri-devel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
