Re: dynamic DMA-buf sharing between devices
Am 18.04.19 um 11:13 schrieb Daniel Vetter: On Tue, Apr 16, 2019 at 08:38:29PM +0200, Christian König wrote: Hi everybody, core idea in this patch set is that DMA-buf importers can now provide an optional invalidate callback. Using this callback and the reservation object exporters can now avoid pinning DMA-buf memory for a long time while sharing it between devices. I've already send out an older version roughly a year ago, but didn't had time to further look into cleaning this up. The last time a major problem was that we would had to fix up all drivers implementing DMA-buf at once. Now I avoid this by allowing mappings to be cached in the DMA-buf attachment and so driver can optionally move over to the new interface one by one. This is also a prerequisite to my patchset enabling sharing of device memory with DMA-buf. Ok, with the discussions and thinking I think this design is solid and should work out. Bunch of api and documentation polishing still to do, to make sure we have really clear semantics and as little room as possible for misunderstanding - refactoring a mess in dma-buf is a lot more tricky than just ttm, there's a lot more users. Yeah, I'm pretty aware of that after changing all the users of the map API to use a structure for the parameters. Well at least it's not UAPI :) Christian -Daniel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: dynamic DMA-buf sharing between devices
On Tue, Apr 16, 2019 at 08:38:29PM +0200, Christian König wrote: > Hi everybody, > > core idea in this patch set is that DMA-buf importers can now provide an > optional invalidate callback. Using this callback and the reservation object > exporters can now avoid pinning DMA-buf memory for a long time while sharing > it between devices. > > I've already send out an older version roughly a year ago, but didn't had > time to further look into cleaning this up. > > The last time a major problem was that we would had to fix up all drivers > implementing DMA-buf at once. > > Now I avoid this by allowing mappings to be cached in the DMA-buf attachment > and so driver can optionally move over to the new interface one by one. > > This is also a prerequisite to my patchset enabling sharing of device memory > with DMA-buf. Ok, with the discussions and thinking I think this design is solid and should work out. Bunch of api and documentation polishing still to do, to make sure we have really clear semantics and as little room as possible for misunderstanding - refactoring a mess in dma-buf is a lot more tricky than just ttm, there's a lot more users. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: dynamic DMA-buf sharing between devices
I like you do somethings step by step, you can ping me when they are ready. -David 在 2019/4/17 21:59, Christian König 写道: > On top of those I have 6 more patches in the pipeline to enable VRAM > P2P with DMA-buf. > > So that is not the end of the patch set :) > > Christian. > > Am 17.04.19 um 15:52 schrieb Chunming Zhou: >> Thanks Christian, great job. I will verify it this week when I finish my >> current work on hand. >> >> -David >> >> 在 2019/4/17 2:38, Christian König wrote: >>> Hi everybody, >>> >>> core idea in this patch set is that DMA-buf importers can now >>> provide an optional invalidate callback. Using this callback and the >>> reservation object exporters can now avoid pinning DMA-buf memory >>> for a long time while sharing it between devices. >>> >>> I've already send out an older version roughly a year ago, but >>> didn't had time to further look into cleaning this up. >>> >>> The last time a major problem was that we would had to fix up all >>> drivers implementing DMA-buf at once. >>> >>> Now I avoid this by allowing mappings to be cached in the DMA-buf >>> attachment and so driver can optionally move over to the new >>> interface one by one. >>> >>> This is also a prerequisite to my patchset enabling sharing of >>> device memory with DMA-buf. >>> >>> Please review and/or comment, >>> Christian. >>> >>> >>> ___ >>> dri-devel mailing list >>> dri-de...@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: dynamic DMA-buf sharing between devices
On top of those I have 6 more patches in the pipeline to enable VRAM P2P with DMA-buf. So that is not the end of the patch set :) Christian. Am 17.04.19 um 15:52 schrieb Chunming Zhou: Thanks Christian, great job. I will verify it this week when I finish my current work on hand. -David 在 2019/4/17 2:38, Christian König wrote: Hi everybody, core idea in this patch set is that DMA-buf importers can now provide an optional invalidate callback. Using this callback and the reservation object exporters can now avoid pinning DMA-buf memory for a long time while sharing it between devices. I've already send out an older version roughly a year ago, but didn't had time to further look into cleaning this up. The last time a major problem was that we would had to fix up all drivers implementing DMA-buf at once. Now I avoid this by allowing mappings to be cached in the DMA-buf attachment and so driver can optionally move over to the new interface one by one. This is also a prerequisite to my patchset enabling sharing of device memory with DMA-buf. Please review and/or comment, Christian. ___ dri-devel mailing list dri-de...@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
Re: dynamic DMA-buf sharing between devices
Thanks Christian, great job. I will verify it this week when I finish my current work on hand. -David 在 2019/4/17 2:38, Christian König wrote: > Hi everybody, > > core idea in this patch set is that DMA-buf importers can now provide an > optional invalidate callback. Using this callback and the reservation object > exporters can now avoid pinning DMA-buf memory for a long time while sharing > it between devices. > > I've already send out an older version roughly a year ago, but didn't had > time to further look into cleaning this up. > > The last time a major problem was that we would had to fix up all drivers > implementing DMA-buf at once. > > Now I avoid this by allowing mappings to be cached in the DMA-buf attachment > and so driver can optionally move over to the new interface one by one. > > This is also a prerequisite to my patchset enabling sharing of device memory > with DMA-buf. > > Please review and/or comment, > Christian. > > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
dynamic DMA-buf sharing between devices
Hi everybody, core idea in this patch set is that DMA-buf importers can now provide an optional invalidate callback. Using this callback and the reservation object exporters can now avoid pinning DMA-buf memory for a long time while sharing it between devices. I've already send out an older version roughly a year ago, but didn't had time to further look into cleaning this up. The last time a major problem was that we would had to fix up all drivers implementing DMA-buf at once. Now I avoid this by allowing mappings to be cached in the DMA-buf attachment and so driver can optionally move over to the new interface one by one. This is also a prerequisite to my patchset enabling sharing of device memory with DMA-buf. Please review and/or comment, Christian. ___ amd-gfx mailing list amd-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/amd-gfx
