From: "Christian König" <christian.koenig@amd.com>
To: Matthew Brost <matthew.brost@intel.com>,
intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: simona.vetter@ffwll.ch, thomas.hellstrom@linux.intel.com,
pstanner@redhat.com, boris.brezillon@collabora.com,
airlied@gmail.com, ltuikov89@gmail.com, dakr@kernel.org,
mihail.atanassov@arm.com, steven.price@arm.com,
shashank.sharma@amd.com
Subject: Re: [RFC PATCH 0/6] Common preempt fences and semantics
Date: Mon, 11 Nov 2024 14:42:02 +0100 [thread overview]
Message-ID: <2d634baa-89cc-4b83-a4c4-4d2ca6a4f2b7@amd.com> (raw)
In-Reply-To: <20241109172942.482630-1-matthew.brost@intel.com>
Am 09.11.24 um 18:29 schrieb Matthew Brost:
> The motivation for this series comes from pending UMD submission work by
> AMD [1], ARM [3], and the Xe team, who are also beginning to look at
> this. Sima has suggested [4] some common driver preemptive fences and
> semantics, which we all agree on. This is the first attempt to implement
> them, based on Xe's existing long-running preemptive fences.
>
> The semantics are fairly simple: preemptive fences attached to a
> dma-resv must wait to enable signaling (and thus preempt device
> execution) until all fences in other slots have been signaled. These
> semantics are necessary to avoid deadlocks when preempting a device
> while a user submission is pending, and resuming device execution
> depends on the user submission completing. The semantics align with
> Christian's view [5], which I also arrived at independently (with a
> little help from Sima).
Ah! I was really wondering for a moment why you wanted to add a separate
dma_resv usage for that. But I strongly think that this approach won't work.
The assumption that completion fences which depend on a preemption fence
are always part of the same dma_resv object is most likely false in some
cases.
At least for the AMD design what can easily happen is that we put a
completion fence only into a drm_syncobj for explicit synchronization
and then engines or different devices which still use kernel submissions
depend on it. That can go boom really trivially.
What we do instead is to wait for the latest issued completion fence
while holding a mutex to prevent creating new ones before stopping the
threads and signaling the preemption fence.
That code could of course be made some driver independent component.
Regards,
Christian.
>
> Implemented via the new dma-resv slot DMA_RESV_USAGE_PREEMPT, a common
> embedded base preemptive fence class with driver operations, and updates
> to the scheduler to adhere to these semantics.
>
> The current Xe long-running preemptive fences have been converted to the
> new common code, and UMD submission is expected to follow (hopefully)
> shortly thereafter in a subsequent series.
>
> Not intended to be presented as the final solution, but rather to
> kickstart serious discussions on this topic.
>
> Matt
>
> [1] https://patchwork.freedesktop.org/series/113675/
> [2] https://patchwork.freedesktop.org/series/114385/
> [3] https://patchwork.freedesktop.org/series/137924/
> [4] https://patchwork.kernel.org/project/dri-devel/cover/20240828172605.19176-1-mihail.atanassov@arm.com/#26011577
> [5] https://patchwork.kernel.org/project/dri-devel/cover/20240828172605.19176-1-mihail.atanassov@arm.com/#26011853
>
> Matthew Brost (6):
> dma-resv: Add DMA_RESV_USAGE_PREEMPT
> drm/sched: Teach scheduler about DMA_RESV_USAGE_PREEMPT
> dma-fence: Add dma_fence_preempt base class
> drm/sched: Teach scheduler about dma_fence_prempt type
> drm/xe: Use DMA_RESV_USAGE_PREEMPT for preempt fences
> drm/xe: Use dma_fence_preempt base class
>
> drivers/dma-buf/Makefile | 2 +-
> drivers/dma-buf/dma-fence-preempt.c | 102 ++++++++++++++++++++
> drivers/dma-buf/dma-resv.c | 43 ++++++---
> drivers/dma-buf/st-dma-resv.c | 2 +-
> drivers/gpu/drm/scheduler/sched_entity.c | 29 +++++-
> drivers/gpu/drm/scheduler/sched_main.c | 50 +++++++---
> drivers/gpu/drm/xe/xe_bo.c | 22 +----
> drivers/gpu/drm/xe/xe_guc_submit.c | 3 +
> drivers/gpu/drm/xe/xe_hw_engine_group.c | 4 +-
> drivers/gpu/drm/xe/xe_migrate.c | 4 +-
> drivers/gpu/drm/xe/xe_preempt_fence.c | 81 +++++-----------
> drivers/gpu/drm/xe/xe_preempt_fence.h | 2 +-
> drivers/gpu/drm/xe/xe_preempt_fence_types.h | 11 +--
> drivers/gpu/drm/xe/xe_pt.c | 12 +--
> drivers/gpu/drm/xe/xe_vm.c | 22 +----
> include/drm/gpu_scheduler.h | 15 +++
> include/linux/dma-fence-preempt.h | 54 +++++++++++
> include/linux/dma-fence.h | 1 +
> include/linux/dma-resv.h | 24 +++--
> 19 files changed, 326 insertions(+), 157 deletions(-)
> create mode 100644 drivers/dma-buf/dma-fence-preempt.c
> create mode 100644 include/linux/dma-fence-preempt.h
>
next prev parent reply other threads:[~2024-11-11 13:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-09 17:29 [RFC PATCH 0/6] Common preempt fences and semantics Matthew Brost
2024-11-09 17:29 ` [RFC PATCH 1/6] dma-resv: Add DMA_RESV_USAGE_PREEMPT Matthew Brost
2024-11-09 17:29 ` [RFC PATCH 2/6] drm/sched: Teach scheduler about DMA_RESV_USAGE_PREEMPT Matthew Brost
2024-11-12 9:06 ` Philipp Stanner
2024-11-12 20:08 ` Matthew Brost
2024-11-13 11:03 ` Philipp Stanner
2024-11-09 17:29 ` [RFC PATCH 3/6] dma-fence: Add dma_fence_preempt base class Matthew Brost
2024-11-09 17:29 ` [RFC PATCH 4/6] drm/sched: Teach scheduler about dma_fence_prempt type Matthew Brost
2024-11-09 17:29 ` [RFC PATCH 5/6] drm/xe: Use DMA_RESV_USAGE_PREEMPT for preempt fences Matthew Brost
2024-11-09 17:29 ` [RFC PATCH 6/6] drm/xe: Use dma_fence_preempt base class Matthew Brost
2024-11-09 17:35 ` ✓ CI.Patch_applied: success for Common preempt fences and semantics Patchwork
2024-11-09 17:35 ` ✗ CI.checkpatch: warning " Patchwork
2024-11-09 17:36 ` ✓ CI.KUnit: success " Patchwork
2024-11-09 17:48 ` ✓ CI.Build: " Patchwork
2024-11-09 17:50 ` ✓ CI.Hooks: " Patchwork
2024-11-09 17:51 ` ✗ CI.checksparse: warning " Patchwork
2024-11-09 18:16 ` ✓ CI.BAT: success " Patchwork
2024-11-10 8:13 ` ✗ CI.FULL: failure " Patchwork
2024-11-11 13:42 ` Christian König [this message]
2024-11-12 3:29 ` [RFC PATCH 0/6] " Matthew Brost
2024-11-12 11:09 ` Christian König
2024-11-13 2:27 ` Matthew Brost
2024-11-13 2:30 ` Matthew Brost
2024-11-13 9:02 ` Christian König
2024-11-13 15:34 ` Matthew Brost
2024-11-14 8:38 ` Christian König
2024-11-15 19:38 ` 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=2d634baa-89cc-4b83-a4c4-4d2ca6a4f2b7@amd.com \
--to=christian.koenig@amd.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=ltuikov89@gmail.com \
--cc=matthew.brost@intel.com \
--cc=mihail.atanassov@arm.com \
--cc=pstanner@redhat.com \
--cc=shashank.sharma@amd.com \
--cc=simona.vetter@ffwll.ch \
--cc=steven.price@arm.com \
--cc=thomas.hellstrom@linux.intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox