On Thu, Nov 24, 2016 at 08:35:21AM +0000, Tvrtko Ursulin wrote: > > On 24/11/2016 08:19, Chris Wilson wrote: > >On Thu, Nov 24, 2016 at 08:07:36AM +0000, Tvrtko Ursulin wrote: > >>Because if we would to implement per batch buffer load balancing in > >>the kernel, the driver would have to make sure that it doesn't > >>depend on any state left by the previous batch. Perhaps this is not > >>a concern, I really know nothing of how the BSD engines are used. > > > >Why do this in the kernel when userspace already has the tools to do it? > > Kernel would have the idea on the ring usage. Say one client only > uses BSD0, BSD1 is always idle, and then a second client comes in > who want to round-robin per batch. May be better to fix that one to > BSD1 then, for all batches that are satisfied by the BSD1 feature > set. Or in other words, how would userspace be able to figure the > optimum scheduling?
There is both a need for sort-first/sort-last scheduling. Simply by monitoring its own load-balancing, the application can avoid overcommit to a saturated engine. That gets you very close to ideal without any kernel overhead (all the monitoring of hw for the application's load balancing can be done in userspace). sort-last scheduling allows naive batch submission (e.g. all clients using the same engine) to be spread across the engines, but does not come free. Sort-last scheduling is definitely something that will be useful, more so if we can move contexts between engines i.e. have identical behaviour to the CPU schedulers for load balancing, but I see a missed opportunity in that userspace could already be doing better balancing. > >The only thing preventing them is the abysmal fake BSD selection that > >originated from libva. > > Hm what do you mean? Why it couldn't be used for round-robin for > example, since you explained that the state doesn't matter. It does > enable explicit ring selection at any time. The original ABI was to allow userspace to select exactly which ring to execute on. Now we have a wart whereby we need to consult a second flag to see if the engine the user specified is the one to use - whereas the flag should be an opt-in to pick an alternate equivalent engine, and for all engines to be exposed in the ring selector. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Libva mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/libva
