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
