[Libva] BSD ring selection

[Chris Wilson]

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