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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux