On 18/05/2017 12:10, Chris Wilson wrote:
On Thu, May 18, 2017 at 01:55:59PM +0300, Joonas Lahtinen wrote:
On ke, 2017-05-17 at 16:40 +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
Building on top of the previous patch which exported the concept
of engine classes and instances, we can also use this instead of
the current awkward engine selection uAPI.
This is primarily interesting for the VCS engine selection which
is a) currently done via disjoint set of flags, and b) the
current I915_EXEC_BSD flags has different semantics depending on
the underlying hardware which is bad.
Proposed idea here is to reserve 16-bits of flags, to pass in
the engine class and instance (8 bits each), and a new flag
named I915_EXEC_CLASS_INSTACE to tell the kernel this new engine
selection API is in use.
Note this text doesn't describe the interface in v3.
Would it make sense to use bitmask for future proofing? Then we could
allow passing multiple options in the future.
No. The first use case has to be explicit control of engine. That's
orthogonal to asking to select any of a particular class.
Was the suggestion to allow instance=any and instance=N? Or even all the
way to instance=N-or-M?
If not the latter, then I can think of two other possible approaches:
1. Reserve 0xff as instance=any, aka 128 instances should be enough for
everbody. :) Could simply enforce in the uAPI that instance ==
I915_EXEC_INSTANCE_MASK = -EINVAL for now or something.
2. Do nothing now and add say I915_EXEC_CLASS at a later point. This
patch adds I915_EXEC_CLASS_INSTANCE so I915_EXEC_CLASS would not sound
out of place.
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
