[Intel-gfx] [RFC v3] drm/i915: Select engines via class and instance in execbuffer2

[Tvrtko Ursulin]

On 18/05/2017 14:37, Chris Wilson wrote:
> On Thu, May 18, 2017 at 02:06:35PM +0100, Tvrtko Ursulin wrote:
>>
>> On 18/05/2017 13:24, Chris Wilson wrote:
>>> Yes, I would argue to defer it until later. One problem I have at the
>>> moment is that not all members of a class are equal, HEVC-capable
>>> engines and the reset do not belong to the same class (i.e. my hope is
>>> that we could just say <class> | [ <mask> | INSTANCE_MASK ] | LOAD_BALANCE)
>>> So I can see the sense in having instance as a mask, or at least making
>>> the current instance field large enough to store a mask in future. I
>>> just feel uneasy as that field could grow quite large, and maybe it will
>>> be better to set the constraint via a context param (all dependency on
>>> frequency and tuning of the LOAD_BALANCE). Hmm, liking having the
>>> instance-mask on the context atm.
>>
>> I don't think per context mask would work unless you won't to
>> mandate multi-contexts where they wouldn't otherwise be needed.
>
> Contexts are not thread-friendly. About the only way you can make them
> safe (wrt execbuf) is through the use of userspace GTT allocation (i.e.
> assigning an address on creation and making it permanent with softpin).
>
> So in general you end up serialising around execbuf and copying the
> state in/out of the ioctl. That gives a window of opportunity to use
> context_setparam as an extension for irregular parameter updates.
>
> It is not as nice as providing space in the execbuf ioctl, because of
> the extra state being carried around in the context.

Yes not nice, I can't say that I like this very much.

>> But this problem in general can also be solved separately from
>> class-instance addressing via engine feature masking.
>
> But imo all members of a class should have the same features. That would
> be my definition of a class!

That sounds very totalitarian! :)) To me a class is a group of some 
entities which share some common characteristics - not necessarily 
completely uniform.

Regards,

Tvrtko