On Tue, Mar 17, 2026 at 03:33:13PM +0100, Danilo Krummrich wrote: > On Tue Mar 17, 2026 at 3:25 PM CET, Daniel Almeida wrote: > > > > > >> On 17 Mar 2026, at 09:31, Danilo Krummrich <[email protected]> wrote: > >> > >> On Tue Mar 17, 2026 at 3:47 AM CET, Daniel Almeida wrote: > >>> I agree with what Danilo said below, i.e.: IMHO, with the direction that > >>> DRM > >>> is going, it is much more ergonomic to add a Rust component with a nice C > >>> interface than doing it the other way around. > >> > >> This is not exactly what I said. I was talking about the maintainance > >> aspects > >> and that a Rust Jobqueue implementation (for the reasons explained in my > >> initial > >> reply) is easily justifiable in this aspect, whereas another C > >> implementation, > >> that does *not* replace the existing DRM scheduler entirely, is much > >> harder to > >> justify from a maintainance perspective. > > > > Ok, I misunderstood your point a bit. > > > >> > >> I'm also not sure whether a C interface from the Rust side is easy to > >> establish. > >> We don't want to limit ourselves in terms of language capabilities for > >> this and > >> passing through all the additional infromation Rust carries in the type > >> system > >> might not be straight forward. > >> > >> It would be an experiment, and it was one of the ideas behind the Rust > >> Jobqueue > >> to see how it turns if we try. Always with the fallback of having C > >> infrastructure as an alternative when it doesn't work out well. > > > > From previous experience in doing Rust to C FFI in NVK, I don’t see, at > > first, why this can’t work. But I agree with you, there may very well be > > unanticipated things here and this part is indeed an experiment. No argument > > from me here. > > > >> > >> Having this said, I don't see an issue with the drm_dep thing going > >> forward if > >> there is a path to replacing DRM sched entirely.
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... > > > > The issues I pointed out remain. Even if the plan is to have drm_dep + > > JobQueue > > (and no drm_sched). I feel that my point of considering doing it in Rust > > remains. > > I mean, as mentioned below, we should have a Rust Jobqueue as independent > component. Or are you saying you'd consdider having only a Rust component > with a > C API eventually? If so, that'd be way too early to consider for various > reasons. > We need to some C story one way or another as we have C drivers and DRM sched is not cutting it nor is maitainable. > >> The Rust component should remain independent from this for the reasons > >> mentioned > >> in [1]. > >> > >> [1] > >> https://lore.kernel.org/dri-devel/[email protected]/ Fair enough. I read through [1], let me respond there. Matt > > > > Ok > > > > — Daniel >
