From: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>
To: "Christian König" <ckoenig.leichtzumerken@gmail.com>,
dakr@kernel.org, ecourtney@nvidia.com, simona@ffwll.ch,
matthew.brost@intel.com, nat@pixelcluster.dev, airlied@gmail.com,
dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
amd-gfx@lists.freedesktop.org
Subject: Re: Refcounting dma_resv and using that for drm_exec support in TTM
Date: Mon, 13 Jul 2026 13:32:48 +0200 [thread overview]
Message-ID: <b1eb8f038e0cb094b9df35cdea400b7fd7cd2d54.camel@linux.intel.com> (raw)
In-Reply-To: <20260710190752.2355-1-christian.koenig@amd.com>
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.
Thanks,
Thomas
>
> Cheers,
> Christian.
next prev parent reply other threads:[~2026-07-13 11:32 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 18:52 Refcounting dma_resv and using that for drm_exec support in TTM Christian König
2026-07-10 18:52 ` [PATCH 01/12] dma-buf: Add reference counting to dma_resv Christian König
2026-07-11 1:27 ` Matthew Brost
2026-07-11 13:10 ` Danilo Krummrich
2026-07-12 19:51 ` Matthew Brost
2026-07-13 9:25 ` Christian König
2026-07-13 14:57 ` Matthew Brost
2026-07-10 18:52 ` [PATCH 02/12] dma-buf/tests: Convert st-dma-resv tests to use dma_resv_alloc Christian König
2026-07-10 18:52 ` [PATCH 03/12] drm/gem: Add helper for drm_gem_object resv assignment Christian König
2026-07-10 18:52 ` [PATCH 04/12] drm/ttm: Switch LRU cursor to track dma_resv instead of buffer objects Christian König
2026-07-13 13:40 ` Thomas Hellström
2026-07-13 15:15 ` Matthew Brost
2026-07-10 18:52 ` [PATCH 05/12] drm/ttm: switch to ttm_bo_lru_for_each_reserved_guarded for swapout Christian König
2026-07-10 18:52 ` [PATCH 06/12] drm/ttm: move delete handling into ttm_bo_evict Christian König
2026-07-10 18:52 ` [PATCH 07/12] drm/ttm: use ttm_bo_lru_for_each_reserved_guarded in evict_all Christian König
2026-07-10 18:52 ` [PATCH 08/12] drm/ttm: use dma_resv reference in ttm_device_clear_lru_dma_mappings Christian König
2026-07-10 18:52 ` [PATCH 09/12] drm/ttm: nuke buffer refcounting Christian König
2026-07-11 13:26 ` Danilo Krummrich
2026-07-13 15:06 ` Matthew Brost
2026-07-10 18:52 ` [PATCH 10/12] drm/exec: add drm_exec_lock_resv function Christian König
2026-07-13 11:57 ` Thomas Hellström
2026-07-13 12:07 ` Christian König
2026-07-13 12:19 ` Thomas Hellström
2026-07-13 13:14 ` Christian König
2026-07-13 13:37 ` Thomas Hellström
2026-07-10 18:52 ` [PATCH 11/12] drm/ttm: support using drm_exec during eviction v4 Christian König
2026-07-13 11:59 ` Thomas Hellström
2026-07-10 18:52 ` [PATCH 12/12] drm/amdgpu: use drm_exec during BO validation Christian König
2026-07-10 19:40 ` ✗ Fi.CI.BUILD: failure for series starting with [01/12] dma-buf: Add reference counting to dma_resv Patchwork
2026-07-13 11:32 ` Thomas Hellström [this message]
2026-07-13 15:03 ` Refcounting dma_resv and using that for drm_exec support in TTM Matthew Brost
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1eb8f038e0cb094b9df35cdea400b7fd7cd2d54.camel@linux.intel.com \
--to=thomas.hellstrom@linux.intel.com \
--cc=airlied@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=ecourtney@nvidia.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=nat@pixelcluster.dev \
--cc=simona@ffwll.ch \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.