Am 16.03.2018 um 14:51 schrieb Chris Wilson:
> Quoting Christian König (2018-03-16 13:20:45)
>> @@ -326,6 +338,29 @@ struct dma_buf_attachment {
>> struct device *dev;
>> struct list_head node;
>> void *priv;
>> +
>> + /**
>> + * @invalidate_mappings:
>> + *
>> + * Optional callback provided by the importer of the attachment which
>> + * must be set before mappings are created.
>> + *
>> + * If provided the exporter can avoid pinning the backing store while
>> + * mappings exists.
> Hmm, no I don't think it avoids the pinning issue entirely. As it stands,
> the importer doesn't have a page refcount and so they all rely on the
> exporter keeping the dmabuf pages pinned while attached. What can happen
> is that given the invalidate cb, the importers can revoke their
> attachments, letting the exporter recover the pages/sg, and then start
> again from scratch.
Yes, exactly. The wording is just not 100% precise and I haven't found
something better so far.
> That also neatly answers what happens if not all importers provide an
> invalidate cb, or fail, the dmabuf remains pinned and the exporter must
> retreat.
Yes, exactly as well. As soon as at least one importer says "I can't do
this", we must fallback to the old behavior.
>> + *
>> + * The function is called with the lock of the reservation object
>> + * associated with the dma_buf held and the mapping function must be
>> + * called with this lock held as well. This makes sure that no mapping
>> + * is created concurrently with an ongoing invalidation.
>> + *
>> + * After the callback all existing mappings are still valid until all
>> + * fences in the dma_bufs reservation object are signaled, but should be
>> + * destroyed by the importer as soon as possible.
>> + *
>> + * New mappings can be created immediately, but can't be used before the
>> + * exclusive fence in the dma_bufs reservation object is signaled.
>> + */
>> + void (*invalidate_mappings)(struct dma_buf_attachment *attach);
> The intent is that the invalidate is synchronous and immediate, while
> locked? We are looking at recursing back into the dma_buf functions to
> remove each attachment from the invalidate cb (as well as waiting for
> dma), won't that cause some nasty issues?
No, with this idea invalidation is asynchronous. Already discussed that
with Daniel as well and YES Daniel also already pointed out that I need
to better document this.
When the exporter calls invalidate_mappings() it just means that all
importers can no longer use their sg tables for new submissions, old
ones stay active.
The existing sg tables are guaranteed to stay valid until all fences in
the reservation object have signaled and the importer should also delay
it's call to call dma_buf_unmap_attachment() until all the fences have
signaled.
When the importer has new work to do, e.g. wants to attach a new fence
to the reservation object, it must grab a new sg table for that. The
importer also needs to make sure that all new work touching the dma-buf
doesn't start before the exclusive fence in the reservation object signals.
This allows for full grown pipelining, e.g. the exporter can say I need
to move the buffer for some operation. Then let the move operation wait
for all existing fences in the reservation object and install the fence
of the move operation as exclusive fence.
The importer can then immediately grab a new sg table for the new
location of the buffer and use it to prepare the next operation.
Regards,
Christian.
> -Chris
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
