From: Philipp Stanner <phasta@mailbox.org>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>, Luke.Wildhardt@proton.me
Cc: Danilo Krummrich <dakr@kernel.org>,
phasta@kernel.org,
"matthew.brost@intel.com" <matthew.brost@intel.com>,
"ckoenig.leichtzumerken@gmail.com"
<ckoenig.leichtzumerken@gmail.com>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
"regressions@lists.linux.dev" <regressions@lists.linux.dev>,
"amd-gfx@lists.freedesktop.org" <amd-gfx@lists.freedesktop.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [REGRESSION] drm/sched: FAIR policy causes serious performance degradation at max GPU load on 9070XT
Date: Wed, 12 Aug 2026 13:58:54 +0200 [thread overview]
Message-ID: <932892b196f7bbba7f5e9bff22f9b484854aaccc.camel@mailbox.org> (raw)
In-Reply-To: <a9ee4edb-e763-4fd7-a510-32191df0cf8f@igalia.com>
On Wed, 2026-08-12 at 12:37 +0100, Tvrtko Ursulin wrote:
> Jokes aside, I agree with the above analysis that a better fix would be
> to pull things under the lock, and interestingly, Philipp had a lock
> widening patch not so long ago but I don't remember what happened it or
> how exactly did it look. It would possibly have fixed this problem.
https://lore.kernel.org/dri-devel/a0d969408a5a55dfb6d0b3e65906fd7bbf3eee1c.camel@mailbox.org/
TBH I got discouraged and increasingly dissatisfied with the state of
our community, because whenever I try to fix things that are
*obviously* broken and incorrect (and which were usually not broken by
me), with relatively simple patches, I have to work uphill and only
receive pushback.
Reviewers and supporters are usually absent unless they want to have
more features or performance-hacks added, though it is apparent that
many indeed read what we are doing.
Should things get better it's usually not acknowledged, and should
things go wrong one runs danger of getting blamed with hindsight-bias.
Had my patch landed and (speculatively) prevented this regression, no
one would have noticed, but Phoronix would write some nice article
about the FPS gain in video games, achieved by Tvrtko Ursulin :)
Ah well.
My vision for drm_sched has been that we absolutely need to start
establishing strict computer science standards and have to prioritze
formal correctness, simplicity and documentation over features and
*especially* performance.
Though I maybe should have tried to be more polite and diplomatic about
it, the evidence that I see is that the DRM community does not actually
want the above. At least I have to conclude that from the lack of
encouraging participation and the presence of discouragement.
So if I want to add a spinlock for something obviously broken, the
burden of proof is on me, not on the one who broke it. If I want to
prevent someone from adding a 4th drm_sched_start_x() function for
performance-reasons, then I receive not-so-nice emails.
Folks here seem to want to continue like they did for the last 15
years.
If anyone here reads this who *doesn't* want to continue like we did
for the last 15 years, then I would kindly ask for public participation
and help with moving things towards the right direction. Simple emails
with "I support this idea, +1", would almost be enough.
It would seem that these recent event might proof that I was right
about our fundamental issues.
P.
next prev parent reply other threads:[~2026-08-12 11:59 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-08 23:33 Luke.Wildhardt
2026-08-10 8:28 ` Philipp Stanner
2026-08-10 12:45 ` Danilo Krummrich
2026-08-10 13:48 ` Tvrtko Ursulin
2026-08-10 16:40 ` Luke.Wildhardt
2026-08-11 7:29 ` Philipp Stanner
2026-08-11 7:49 ` Tvrtko Ursulin
2026-08-11 17:59 ` Luke.Wildhardt
2026-08-12 11:37 ` Tvrtko Ursulin
2026-08-12 11:58 ` Philipp Stanner [this message]
2026-08-12 12:29 ` Tvrtko Ursulin
2026-09-16 7:37 ` Philipp Stanner
2026-08-12 15:12 ` Luke.Wildhardt
2026-08-13 6:42 ` Luke.Wildhardt
2026-08-13 7:58 ` Tvrtko Ursulin
2026-08-13 14:27 ` Luke.Wildhardt
2026-08-14 6:49 ` Luke.Wildhardt
2026-08-14 8:32 ` Feng, Kenneth
2026-08-10 11:36 ` Tvrtko Ursulin
2026-08-11 7:46 ` Tvrtko Ursulin
2026-08-12 4:52 ` Luke.Wildhardt
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=932892b196f7bbba7f5e9bff22f9b484854aaccc.camel@mailbox.org \
--to=phasta@mailbox.org \
--cc=Luke.Wildhardt@proton.me \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
--cc=regressions@lists.linux.dev \
--cc=tvrtko.ursulin@igalia.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
all inboxes | Powered by JetHome®