Re: [PATCH v2 0/4] drm/exec: drm_exec polishing

[Thomas Hellström <thomas.hellstrom@linux.intel.com>]

Hi,

On Wed, 2026-05-20 at 13:34 +0200, Christian König wrote:
> On 5/20/26 12:16, Thomas Hellström wrote:
> > During the work towards enabling exhaustive eviction using full
> > ww locking in TTM, Christian indicated that the path for the
> > drm_exec moving forward was to be a full drm_exec helper with
> > things like userptr validation rather than a WW transaction
> > abstraction. The idea was then briefly discussed to craft a
> > WW transaction helper and then subclass that with drm_exec
> > with the idea that the WW transaction helper could be used in
> > TTM for eviction and for other uses that didn't mandate a full
> > exec sequence.
> 
> BTW Natalie is now trying to polish my TTM patches for doing that
> because some test case for the SteamDeck is running
>  into issues with pinning buffers for display.

Thanks for the review, Christian.

FWIW I did a POC implementation moving drm_exec as a transaction helper
to the dma-buf layer, and then re-implemented drm_exec on top as a
wrapper here:

https://gitlab.freedesktop.org/thomash/xe-vibe/-/commits/ww_transaction?ref_type=heads

Since this would work on any object with a refererence count and a
dma_resv, and even mixing them, it would solve a couple of issues:

1) Decouple the ttm object refcount issue from the TTM exhaustive
eviction (Not saying we shouldn't get rid of the ttm object refcount
anyway).

2) Implement any eviction locking modes (like snapshotting, object
release after slow-lock and similar) separate from drm_exec, and keep
exec as a pure exec-buf helper.

3) Facilitate ww locking in dma_buf_map().

4) Directly lock VMs instead of vm objects.

I haven't posted the patches yet since I wanted to get some feedback
first of whether this is a reasonable direction.

Thanks,
Thomas

> 
> > Regardless whether that actually happens or not, this series
> > aims to clean up abuses of drm_exec internals in drivers
> > so that future development of drm_exec isn't blocked by
> > such driver usage.
> 
> Yeah completely agree, going to review those patches now.
> 
> Regards,
> Christian.
> 
> > 
> > Except for patch 2 which is a small cleanup only.
> > 
> > v2:
> > - An drm/msm patch was already merged.
> > - Use a unique id for the loop variable (patch 1) (Christian)
> > - Move assignment to declaration (patch 2) (Christian)
> > - Declare the retry pointer as void *const. (patch 2)
> > - Only allow if the drm_exec context is newly initialized. (patch
> > 3)
> >   (Christian)
> > - Fix amdgpu compile error (patch 4) (Intel CI)
> > - Update the commit message (patch 4)
> > 
> > Thomas Hellström (4):
> >   drm/exec: Remove the index parameter from
> >     drm_exec_for_each_locked_obj[_reverse]
> >   drm/exec: Make the drm_exec_until_all_locked() macro more
> > readable
> >   drm/exec, drm/xe: Avoid abusing the drm_exec retry pointer
> >   drm/exec, drm/xe, drm/amdgpu: Add an accessor for struct
> >     drm_exec::ticket
> > 
> >  .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c  |  4 +-
> >  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c        | 15 ++--
> >  .../drm/amd/amdgpu/amdgpu_eviction_fence.c    |  3 +-
> >  drivers/gpu/drm/drm_exec.c                    |  9 +--
> >  drivers/gpu/drm/drm_gpuvm.c                   |  3 +-
> >  drivers/gpu/drm/xe/xe_validation.c            |  4 +-
> >  drivers/gpu/drm/xe/xe_validation.h            |  2 +-
> >  drivers/gpu/drm/xe/xe_vm.c                    |  3 +-
> >  include/drm/drm_exec.h                        | 71 ++++++++++++++-
> > ----
> >  9 files changed, 70 insertions(+), 44 deletions(-)
> >