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