RFC: unpinned DMA-buf exporting v2

Christian König ckoenig.leichtzumerken at gmail.com
Fri Mar 16 13:20:44 UTC 2018


Hi everybody,

since I've got positive feedback from Daniel I continued working on this approach.

A few issues are still open:
1. Daniel suggested that I make the invalidate_mappings callback a parameter of dma_buf_attach().

This approach unfortunately won't work because when the attachment is created the importer is not necessarily ready to handle invalidation events.

E.g. in the amdgpu example we first need to setup the imported GEM/TMM objects and install that in the attachment.

My solution is to introduce a separate function to grab the locks and set the callback, this function could then be used to pin the buffer later on if that turns out to be necessary after all.

2. With my example setup this currently results in a ping/pong situation because the exporter prefers a VRAM placement while the importer prefers a GTT placement.

This results in quite a performance drop, but can be fixed by a simple mesa patch which allows shred BOs to be placed in both VRAM and GTT.

Question is what should we do in the meantime? Accept the performance drop or only allow unpinned sharing with new Mesa?

Please review and comment,
Christian.



More information about the dri-devel mailing list