On Wed, Jan 08, 2025 at 05:57:25PM +0100, Danilo Krummrich wrote: > On Wed, Jan 08, 2025 at 03:13:39PM +0000, Tvrtko Ursulin wrote: Hi, all. Just catching up on this post holidays. A few thoughts below. > > > > On 08/01/2025 08:31, Danilo Krummrich wrote: > > > On Mon, Dec 30, 2024 at 04:52:45PM +0000, Tvrtko Ursulin wrote: > > > > From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxx> > > > > > > "Deadline scheduler and other ideas" > > > > > > There's a few patches that could be sent outside the scope of this series, e.g. > > > the first one. > > > > > > I think it would make sense to do so. > > > > For now I'll keep them at the head of this RFC and as they get acked or > > r-b-ed I can easily send them standalone or re-ordered. Until then having > > the series separate would make the RFC not standalone. > > > > > > <tldr> > > > > Replacing FIFO with a flavour of deadline driven scheduling and removing round- > > > > robin. Connecting the scheduler with dma-fence deadlines. First draft and > > > > testing by different drivers and feedback would be nice. I was only able to test > > > > it with amdgpu. Other drivers may not even compile. > > > > > > What are the results from your tests with amdgpu? Do you have some measurements? > > > > We already covered this in the thread with Philipp to a degree. Tl;dr; the > > main idea is whether we simplify the code and at least not regress. > > > > I don't expect improvements on the amdgpu side with the workloads like games > > and benchmarks. I did not measure anything significant apart that priorities > > seem to work with the run queues removed. > > I appreaciate the effort, and generally I like the idea, but I also must admit > that this isn't the most convincing motiviation for such an integral change > (especially the "at least not regress" part). > > I'd still like to encourage you to send the small cleanups separately, get them > in soon and leave the deadline scheduler as a separate RFC. > > Meanwhile, Philipp is working on getting documentation straight and digging into > all the FIXMEs of the scheduler getting to a cleaner baseline. And with your > cleanups you're already helping with that. > > For now, I'd prefer to leave the deadline scheduler stuff for when things are a > bit more settled and / or drivers declare the need. > I have to agree with Danilo here. Unless there is a clear motivation for deadline scheduler changes, I'm not sure it's worth a rewrite and the potential headaches of things breaking. > > > > Where something could show is if someone is aware of a workload where normal > > prio starves low. Since one part of the idea is that with the "deadline" > > scheme those should work a little bit more balanced. > > > > Also again, feedback (including testing feedback from other drivers) would > > be great, and ideas of which workloads to test. > > Unfortunately, there's not much I can tell from the Nouveau side of things, > since we're using the firmware scheduler scheme (one entity per scheduler) and > hence the scheduling strategy isn't that relevant. > I also agree here. From a Xe perspective, we don’t really have a stake in this since we use a firmware scheduler scheme. Matt > > > > Btw I will send a respin in a day or so which will clean up some things and > > adds some more tiny bits. > > > > Regards, > > > > Tvrtko >
