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

[Daniel Almeida]

I still need to digest your answers above, there's quite a bit of information.
Thanks for that. I'll do a pass on it tomorrow.

>>> By the way:
>>> 
>>> I invite you to have a look at this implementation [0]. It currently works in real
>>> hardware i.e.: our downstream "Tyr" driver for Arm Mali is using that at the
>>> moment. It is a mere prototype that we’ve put together to test different
>>> approaches, so it’s not meant to be a “solution” at all. It’s a mere data point
>>> for further discussion.
> 
> I think some of the things I pointed out—async teardown, bypass paths,
> and dropping job refs in IRQ context—would still need to be added,
> though.

That’s ok, I suppose we can find a way to add these things if they’re
needed in order to support other FW scheduling GPUs (i.e.: other than Mali,
which is the only thing I tested on, and Nova, which I assume has very similar
requirements).

> 
>>> 
>>> Philip Stanner is working on this “Job Queue” concept too, but from an upstream
>>> perspective.
>>> 
>>> [0]: https://gitlab.freedesktop.org/panfrost/linux/-/merge_requests/61
> 
> I scanned [0], it looks signicantly better than the post upstream. Let
> me dig in a bit more.
> 
> Matt
> Matt

One thing that is missing is that, at the moment, submit() is fallible and
there is no preallocation. This can be added to the current design rather
easily (i.e. by splitting into two different steps, a fallible prepare() where
rollback is possible, and an infallible commit(), or whatever names get
chosen).

Perhaps we can also split this into two types too, AtomicJobQueue and JobQueue,
where only the first one allows refs to be dropped in IRQ context; i.e.: since
we do not need this in Tyr, and not allowing this makes the design of the
"non-atomic" version much simpler. Or perhaps we can figure out a way to ensure
that we don't drop the last ref in IRQ context. I am just brainstorming some
ideas at this point, and again, I still need to go through your explanations above.

— Daniel