On 03/05/18 19:00, Tvrtko Ursulin wrote:
On 03/05/2018 18:31, Lionel Landwerlin wrote:
On 03/05/18 18:12, Tvrtko Ursulin wrote:
On 30/04/2018 15:37, Lionel Landwerlin wrote:
On 25/04/18 12:50, Chris Wilson wrote:
Quoting Lionel Landwerlin (2018-04-25 12:45:14)
This function will be used later by the per (context,engine) power
programming interface.
No. This is not the appropriate uABI, please see
intel_engine_lookup_user().
-Chris
uAPI wise, does this sound okay? :
#define I915_CONTEXT_PARAM_SSEU 0x7
__u64 value;
struct drm_i915_gem_context_param_sseu {
/*
* Engine to be configured or queried.
*/
__u32 class;
__u32 instance;
/*
* Setting slice_mask or subslice_mask to 0 will make the
context use
* masks reported respectively by I915_PARAM_SLICE_MASK or
* I915_PARAM_SUBSLICE_MASK.
*/
union {
struct {
__u8 slice_mask;
__u8 subslice_mask;
__u8 min_eus_per_subslice;
__u8 max_eus_per_subslice;
} packed;
__u64 value;
};
};
Is it possible (now or in the future) to have different configs per
slice or subslice? And if so, is the way this uAPI handles that
passing these packets multiple times every time with different
slices and subslice mask?
For instance:
class=0, instance=0, slice_mask=0x1, subslice=0x10
class=0, instance=0, slice_mask=0x10, subslice=0x1
Is this something we should support?
It's not supported in any configuration I'm aware of. It's always a
uniform subslice programming across slices. > It's actually a number
of slice/subslice to enable (through the register
interface), not a mask (i.e. we can't choose which ones get used)
which is what this interface exposes.
I thought for Gen11 it cannot be just number of slices but must be a
mask? since media will want to make sure some slices are not enabled,
and some are, for its workloads.
Interesting question. I'll try to get an understanding on that.
I'm guessing that you program it to half the number of subslices and it
just works.
But in general I guess I don't understand the semantics of slice and
subslice masks (and eu counts). Say if you pass in slice_mask=0x1
subslice_mask=0x1 - this means you are only enabling subslice 0x1 on
slice 0x1 - but what happens on other slices? They are all disabled?
slice_mask=0x1 means you only enable the first slice
subslice_mask=0x1 means for each slice, you only enable the first subslice.
So essentially on a GT4 (3 slices), slices 1 & 2 would be disable
completely (all subslices included) and only subslice0 in slice0 would
be powered.
It's a fair comment though. We didn't plan for asymmetric slice
fusing initially and it just happened.
Okay so you think uAPI should support it to be more future proof?
I don't feel like HW engineers want to give us that amount of say in
what can be powered.
So I wouldn't make it more flexible than it currently is.
We explicitly say that subslice_mask is uniform for all slices. And if
hardware ever grows more capability we add a new enum.
One other thing I've been wondering is whether we should strictly
validate the input from userspace.
Right now we min/max the numbers and never raise any error.
It does feel low level enough that we should reject userspace trying
to feed in nonsense for its own good.
Okay, adding that.
Thanks!
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
