From: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>
To: Daniel Vetter <daniel@ffwll.ch>, Rob Clark <robdclark@gmail.com>,
Matthew Brost <matthew.brost@intel.com>
Cc: "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>
Subject: drm scheduler and wq flavours
Date: Thu, 2 May 2024 15:33:50 +0100 [thread overview]
Message-ID: <7236d76a-8e6d-4a8e-9e4e-e2644c5df2d7@igalia.com> (raw)
Hi all,
Continuing after the brief IRC discussion yesterday regarding work
queues being prone to deadlocks or not, I had a browse around the code
base and ended up a bit confused.
When drm_sched_init documents and allocates an *ordered* wq, if no
custom one was provided, could someone remind me was the ordered
property fundamental for something to work correctly? Like run_job vs
free_job ordering?
I ask because it appears different drivers to different things and at
the moment it looks we have all possible combos or ordered/unordered,
bound and unbound, shared or not shared with the timeout wq, or even
unbound for the timeout wq.
The drivers worth looking at in this respect are probably nouveau,
panthor, pvr and xe.
Nouveau also talks about a depency betwen run_job and free_job and goes
to create two unordered wqs.
Then xe looks a bit funky with the workaround/hack for lockep where it
creates 512 work queues and hands them over to user queues in
round-robin fashion. (Instead of default 1:1.) Which I suspect is a
problem which should be applicable for any 1:1 driver given a thorough
enough test suite.
So anyway.. ordered vs unordered - drm sched dictated or at driver's choice?
Regards,
Tvrtko
next reply other threads:[~2024-05-02 14:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-02 14:33 Tvrtko Ursulin [this message]
2024-05-06 23:23 ` drm scheduler and wq flavours Matthew Brost
2024-05-07 9:09 ` Tvrtko Ursulin
2024-05-08 19:07 ` 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=7236d76a-8e6d-4a8e-9e4e-e2644c5df2d7@igalia.com \
--to=tvrtko.ursulin@igalia.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=robdclark@gmail.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).