Re: [RFC PATCH 02/12] drm/dep: Add DRM dependency queue layer

Matthew Brost
2026-03-18T23:02:43Z

On Tue, Mar 17, 2026 at 01:19:47PM +0100, Danilo Krummrich wrote:
> On Tue Mar 17, 2026 at 6:10 AM CET, Matthew Brost wrote:
> > On Mon, Mar 16, 2026 at 11:25:23AM +0100, Danilo Krummrich wrote:
> >> The reason I proposed a new component for Rust, is basically what you also wrote
> >> in your cover letter, plus the fact that it prevents us having to build a Rust
> >> abstraction layer to the DRM GPU scheduler.
> >>
> >> The latter I identified as pretty questionable as building another abstraction
> >> layer on top of some infrastructure is really something that you only want to do
> >> when it is mature enough in terms of lifetime and ownership model.
> >>
> >
> > I personally don’t think the language matters that much. I care about
> > lifetime, ownership, and teardown semantics. I believe I’ve made this
> > clear in C, so the Rust bindings should be trivial.
>
> No, they won't be trivial -- in fact, in the case of the Jobqueue they may even
> end up being more complicated than a native implementation.
>
> We still want to build the object model around it that allows us to catch most
> of the pitfalls at compile time rather than runtime.
>

I do understand this line of thinking.

> For instance, there has been a proposal of having specific work and workqueue
> types that ensure not to violate DMA fence rules, which the Jobqueue can adopt.
>

Yes, want to add that too for C (ofc this can't be enforced at compile time).

I've started on this here [1]

https://patchwork.freedesktop.org/patch/711929/?series=163245&rev=1

> We can also use Klint to ensure correctness for those types at compile time.
>
> So, I can easily see this becoming more complicated when we have to go through
> an FFI layer that makes us loose additional type information / guarantees.
>
> Anyways, I don't want to argue about this. I don't know why the whole thread
> took this direction.

Yea, my bad. I apologize. This shouldn't be about is Rust or C better.

>
> This is not about C vs. Rust, and I see the Rust component to be added
> regardless of this effort.

+1.

>
> The question for me is whether we want to have a second component besides the
> GPU scheduler on the C side or not.
>
> If we can replace the existing scheduler entirely and rework all the drivers
> that'd be great and you absolutely have my blessing.
>

I'll copy paste my reply from [2].

The only weird case I haven't wrapped my head around quite yet is the
ganged submissions that rely on the scheduled fence (PVR, AMDGPU do
this). Pretty much every other driver seems like it could be coverted
with what I have in place in this series + local work to provide a
hardware scheduler...

[2] https://patchwork.freedesktop.org/patch/711933/?series=163245&rev=1#comment_1311418

> But, I don't want to end up in a situation where this is landed, one or two
> drivers are converted, and everything else is left behind in terms of
> maintainance / maintainer commitment.
>

I can get other drivers to compile but I can't do things like test these
changes for other vendors. Also if existing drivers break dma-fencing
rules, those would need to fixed when converting over too.

> >> My point is, the justification for a new Jobqueue component in Rust I consider
> >> given by the fact that it allows us to avoid building another abstraction layer
> >> on top of DRM sched. Additionally, DRM moves to Rust and gathering experience
> >> with building native Rust components seems like a good synergy in this context.
> >>
> >
> > If I knew Rust off-hand, I would have written it in Rust :). Perhaps
> > this is an opportunity to learn. But I think the Rust vs. C holy war
> > isn’t in scope here. The real questions are what semantics we want, the
> > timeline, and maintainability. Certainly more people know C, and most
> > drivers are written in C, so having the common component in C makes more
> > sense at this point, in my opinion. If the objection is really about the
> > language, I’ll rewrite it in Rust.
>
> Again, I'm not talking about Rust vs. C. I'm talking about why a new Rust
> component is much easier to justify maintainance wise than a new C component is.
>
> That is, the existing infrastructure has problems we don't want to build on top
> of and the abstraction ends up being of a similar magnitude as a native
> implementation.
>
> A new C implementation alongside the existing one is a whole different question.
>
> >> Having that said, the obvious question for me for this series is how drm_dep
> >> fits into the bigger picture.
> >>
> >> I.e. what is the maintainance strategy?
> >>
> >
> > I will commit to maintaining code I believe in, and immediately write
> > the bindings on top of this so they’re maintained from day one.
>
> This I am sure about, but what about the existing scheduler infrastructure? Are

+1

> you going to keep this up as well?

The fact is we can't maintain DRM sched as it is now, techincal debt is
just too high.

>
> Who keeps supporting it for all the drivers that can't switch (due to not having
> firmware queues) or simply did not switch yet?
>

I'd say I agree with your no new features statement in DRM sched, if you
want new features in C, fix your driver to use what I have here.

Ofc if bugs pop up in drm sched, happy help fix those.

> >> Do we want to support three components allowing users to do the same thing? What
> >> happens to DRM sched for 1:1 entity / scheduler relationships?
> >>
> >> Is it worth? Do we have enough C users to justify the maintainance of yet
> >> another component? (Again, DRM moves into the direction of Rust drivers, so I
> >> don't know how many new C drivers we will see.) I.e. having this component won't
> >> get us rid of the majority of DRM sched users.
> >>
> >
> > Actually, with [1], I’m fairly certain that pretty much every driver
> > could convert to this new code. Part of the problem, though, is that
> > when looking at this, multiple drivers clearly break dma-fencing rules,
> > so an annotated component like DRM dep would explode their drivers. Not
> > to mention the many driver-side hacks that each individual driver would
> > need to drop (e.g., I would not be receptive to any driver directly
> > touching drm_dep object structs).
>
> I thought the API can't be abused? :) How would you prevent drivers doing this
> in practice? They need to have the struct definition, and once they have it, you
> can't do anything about them peeking internals, if not caught through review.
>

I agree with this statement. So it would require disciplined reviews...

e.g., You are touching this struct directly - why? Is is drm dep missing
something in the API your driver needs, if it is real issue we add to
drm dep.

> > Maintainable, as I understand every single LOC, with verbose documentation
> > (generated with Copilot, but I’ve reviewed it multiple times and it’s
> > correct), etc.
>
> I'm not sure this is the core criteria for evaluating whether something is
> maintainable or not.
>
> To be honest, this does not sound very community focused.
>

That is not my intent. I did write this as common component for driver
and to used by the community.

> > Regardless, given all of the above, at a minimum my driver needs to move
> > on one way or another.
>
> Your driver? What do you mean with "it has to move"?

DRM sched is not maintainable, thus it is not going to fit the needs of
Xe in the longterm. Other drivers like are facing similar issues.

Matt