From: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Cc: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>,
<amd-gfx@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
<etnaviv@lists.freedesktop.org>,
<freedreno@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>, <lima@lists.freedesktop.org>,
<linaro-mm-sig@lists.linaro.org>, <linux-arm-msm@vger.kernel.org>,
<linux-doc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-media@vger.kernel.org>, <nouveau@lists.freedesktop.org>
Subject: [PATCH v7 0/7] Improve gpu_scheduler trace events + uAPI
Date: Fri, 31 Jan 2025 12:02:58 +0100 [thread overview]
Message-ID: <20250131110328.706695-1-pierre-eric.pelloux-prayer@amd.com> (raw)
Hi,
The initial goal of this series was to improve the drm and amdgpu
trace events to be able to expose more of the inner workings of
the scheduler and drivers to developers via tools.
Then, the series evolved to become focused only on gpu_scheduler.
The changes around vblank events will be part of a different
series, as well as the amdgpu ones.
Moreover Sima suggested to make some trace events stable uAPI,
so tools can rely on them long term.
The first patches extend and cleanup the gpu scheduler events.
The last one adds a documentation entry in drm-uapi.rst.
Changes since v6:
* Addressed comments from Philipp, Tvrtko, Steven
* The commit storing drm_client_id in sched_fence adds an extra
field which looks like a duplicate of the owner field. Currently
amdgpu uses the owner field with some magic values, so we have to
have 2 separate fields for now, but ultimately one could be removed.
Similarly storing the drm_client_id in the sched_entity is not
really possible as there's nothing preventing a driver to use a
sched_entity with multiple drm_file instances.
Useful links:
- userspace tool using the updated events:
https://gitlab.freedesktop.org/tomstdenis/umr/-/merge_requests/37
- v6:
https://lists.freedesktop.org/archives/dri-devel/2024-November/477644.html
Pierre-Eric Pelloux-Prayer (7):
drm/debugfs: output client_id in in drm_clients_info
drm/sched: store the drm client_id in drm_sched_fence
drm/sched: add device name to the drm_sched_process_job event
drm/sched: cleanup gpu_scheduler trace events
drm/sched: trace dependencies for gpu jobs
drm/sched: add the drm_client_id to the drm_sched_run/exec_job events
drm/doc: document some tracepoints as uAPI
Documentation/gpu/drm-uapi.rst | 19 +++
drivers/accel/amdxdna/aie2_ctx.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 3 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 8 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 3 +-
drivers/gpu/drm/drm_debugfs.c | 10 +-
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
drivers/gpu/drm/imagination/pvr_job.c | 2 +-
drivers/gpu/drm/imagination/pvr_queue.c | 5 +-
drivers/gpu/drm/imagination/pvr_queue.h | 2 +-
drivers/gpu/drm/lima/lima_gem.c | 2 +-
drivers/gpu/drm/lima/lima_sched.c | 6 +-
drivers/gpu/drm/lima/lima_sched.h | 3 +-
drivers/gpu/drm/msm/msm_gem_submit.c | 8 +-
drivers/gpu/drm/nouveau/nouveau_sched.c | 3 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
drivers/gpu/drm/panthor/panthor_drv.c | 3 +-
drivers/gpu/drm/panthor/panthor_mmu.c | 2 +-
drivers/gpu/drm/panthor/panthor_sched.c | 5 +-
drivers/gpu/drm/panthor/panthor_sched.h | 3 +-
.../gpu/drm/scheduler/gpu_scheduler_trace.h | 123 ++++++++++++++----
drivers/gpu/drm/scheduler/sched_entity.c | 8 +-
drivers/gpu/drm/scheduler/sched_fence.c | 4 +-
drivers/gpu/drm/scheduler/sched_main.c | 8 +-
drivers/gpu/drm/v3d/v3d_submit.c | 2 +-
drivers/gpu/drm/xe/xe_sched_job.c | 3 +-
include/drm/gpu_scheduler.h | 12 +-
28 files changed, 192 insertions(+), 64 deletions(-)
--
2.47.1
next reply other threads:[~2025-01-31 11:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-31 11:02 Pierre-Eric Pelloux-Prayer [this message]
2025-01-31 11:03 ` [PATCH v7 2/7] drm/sched: store the drm client_id in drm_sched_fence Pierre-Eric Pelloux-Prayer
2025-01-31 13:12 ` [PATCH v7 0/7] Improve gpu_scheduler trace events + uAPI Christian König
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=20250131110328.706695-1-pierre-eric.pelloux-prayer@amd.com \
--to=pierre-eric.pelloux-prayer@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=etnaviv@lists.freedesktop.org \
--cc=freedreno@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=lima@lists.freedesktop.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=nouveau@lists.freedesktop.org \
/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