[Intel-gfx] [PATCH] drm/i915: Serialise presentation with imported dmabufs

[Chris Wilson]

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