On Tue, Jun 14, 2016 at 05:45:24PM +0200, Daniel Vetter wrote: > On Tue, Jun 14, 2016 at 04:03:57PM +0100, Chris Wilson wrote: > > obj->base.dma_buf represents a dma-buf exported from this object (for > > use by others). On the contrary, ob->base.import_attach represents the > > source dma-buf that was used to create this object (if any). When > > serialising with third parties, we want to wait on their rendering via > > the import attachment (and not our own via the dma_buf export). > > > > Note that for an object exported from i915 and passed to another i915 > > client, we do not create the import attachment and so serialisation will > > use our native paths. > > But that would break it, if the foreign object attaches a some fence to > the reservation. The foreign object case is the situation that is broken right now. Since obj->base.import_attach != NULL, but obj->base.dma_buf == NULL. > We need things to work both ways, and that is done by > having a reservation pointer, where we either store our own per-bo lock + > list of reservations, or the imported one from the other driver. > > A bit much, but interim we'd need at least both base.dma_buf and > base.import_attach. If you really insist on having both channels being bidirectional, everything needs to be duplicated and then filtered for relevance. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
