On Mon, Sep 29, 2014 at 09:46:48AM +0200, Daniel Vetter wrote:
On Fri, Sep 26, 2014 at 01:00:12PM +0300, Lauri Peltonen wrote:
Allow user space to provide an explicit sync fence fd when exporting a dma-buf from gem handle. The fence will be stored as the explicit fence to the reservation object.
Signed-off-by: Lauri Peltonen lpeltonen@nvidia.com
All existing userspace treats dma_bufs as long-lived objects. Well, all the userspace that expects implicit syncing, afaik Android shovels lots of dma-bufs around all the time (since ion is using them as it's native buffer handles).
So adding an exclusive fence once at export time isn't going to be terribly useful.
So I think a better approach would be to add this as ioctls to the dma-buf fd itself. Then you can also add a "give me the fence(s) for this dma_buf" ioctl, which is useful for interop the other way round (i.e. implicit -> explicit).
Yes, I like this. I thought that one could support long-lived dma-bufs by doing a "re-export" when a new fence needs to be attached, but your model is indeed much nicer!
On Sat, Sep 27, 2014 at 08:49:39AM +0200, Maarten Lankhorst wrote:
This is never true. A default resv gets allocated, see dma_buf's create function.
Ah, ok. I'll keep that in mind when writing new versions. :-)
Thanks, Lauri