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

[Danilo Krummrich]

On Tue Mar 17, 2026 at 3:25 PM CET, Daniel Almeida wrote:
>
>
>> On 17 Mar 2026, at 09:31, Danilo Krummrich <dakr@xxxxxxxxxx> 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 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.

>> The Rust component should remain independent from this for the reasons mentioned
>> in [1].
>> 
>> [1] https://lore.kernel.org/dri-devel/DH51W6XRQXYX.3M30IRYIWZLFG@xxxxxxxxxx/
>
> Ok
>
> — Daniel