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. > 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! -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
