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

["Danilo Krummrich" <dakr@kernel.org>]

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.

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.

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.

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

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.

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.

>> 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
you going to keep this up as well?

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

>> 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.

> 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.

> 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"?