From: Matthew Brost <matthew.brost@intel.com>
To: 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,
christian.koenig@amd.com, mihail.atanassov@arm.com,
steven.price@arm.com, shashank.sharma@amd.com
Subject: [RFC PATCH 0/6] Common preempt fences and semantics
Date: Sat, 9 Nov 2024 09:29:36 -0800 [thread overview]
Message-ID: <20241109172942.482630-1-matthew.brost@intel.com> (raw)
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).
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
--
2.34.1
next reply other threads:[~2024-11-09 17:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-09 17:29 Matthew Brost [this message]
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 ` [RFC PATCH 0/6] " Christian König
2024-11-12 3:29 ` 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=20241109172942.482630-1-matthew.brost@intel.com \
--to=matthew.brost@intel.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=ltuikov89@gmail.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