On Mon, Jul 13, 2026 at 01:32:48PM +0200, Thomas Hellström wrote: > Hi, Christian, > > On Fri, 2026-07-10 at 20:52 +0200, Christian König wrote: > > Hi everybody, > > > > The idea of ref-counting dma_resv or ww_mutex came up multiple times > > from > > different people, but so far at least I have abandoned that as to > > complicated to implement considering how widely used that object is. > > > > Thanks to AI I gave the task to refcount dma_resv to Claude Sonet 4 > > just > > to check how horrible it would look like. > > > > Well turns out that this is actually a cleanup we should most likely > > aim > > for and I'm really wondering why we haven't done it like this in the > > first place. > > > > Not only resolves it a bunch of issues with dma_resv instances shared > > by > > multiple GEM objects (we just recently had a bunch of patches for > > that on > > the mailing list), but also allows TTM to implement it's delayed > > delete > > handling without any zombie resurrection or similar hacks. > > > > The patch set is totally work in progress and only survives a smoke > > test > > with amdgpu, but I still wanted to check if the idea is valuable and > > should be looked in further. > > > > Please comment and/or tear apart :) > > Before starting to look at this, in the spirit of trying to aligning on > a "final" solution for ww transactions used in TTM, could we agree on > how we are supposed to pass the importer's ww transaction context to > the exporter's dma_map_attachment() operation to handle exporter > evictions while mapping, because that decides what abstaction we should > use for WW transations within TTM. > > drm_exec_init() > xe_bo_validate() // IMporter > dma_buf_map() // importer; > map_attachment() // callback in exporter > xe_bo_validate() // exporter tries to move exportert bo to VRAM but > runs out of memory. > ttm_bo_evict() // exporter's evict needs importer's drm_exec > > As mentioned a couple of times before, we can't pass a drm_exec to the > exporter because that would make dma-buf depend on drm. > > So with this series it would be sufficient to move drm_exec to the dma- > buf layer and rename it, but I still think we should have a plan.
+1 to Thomas's thinking here — drm_exec should be moved to the dma-buf layer. I think that would involve dropping the GEM references from the base layer and instead operating on dma-resv objects. Of course, if we want a drm_exec layer that operates on GEM objects, it could be built on top of the base dma-buf mechanism. Matt > > Thanks, > Thomas > > > > > > > > Cheers, > > Christian.
