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

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

On Mon Mar 16, 2026 at 5:32 AM CET, Matthew Brost wrote:
> Diverging requirements between GPU drivers using firmware scheduling
> and those using hardware scheduling have shown that drm_gpu_scheduler is
> no longer sufficient for firmware-scheduled GPU drivers. The technical
> debt, lack of memory-safety guarantees, absence of clear object-lifetime
> rules, and numerous driver-specific hacks have rendered
> drm_gpu_scheduler unmaintainable. It is time for a fresh design for
> firmware-scheduled GPU drivers—one that addresses all of the
> aforementioned shortcomings.

I think we all agree on this and I also think we all agree that this should have
been a separate component in the first place -- and just to be clear, I am
saying this in retrospective.

In fact, this is also the reason why I proposed building the Rust component
differently, i.e. start with a Joqueue (or drm_dep as called in this patch) and
expand as needed with a loosely coupled "orchestrator" for drivers with strictly
limited software/hardware queues later.

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'm not saying it wouldn't be possible, but as mentioned in other threads, I
don't think it is a good idea building new features on top of something that has
known problems, even less when they are barely resolvable due to other existing
dependencies, such as some drivers relying on implementation details
historically, etc.

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.

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?

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.

What are the expected improvements? Given the above, I'm not sure it will
actually decrease the maintainance burdon of DRM sched.