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.
