Re: [PATCH 1/8] drm/i915: expose helper mapping exec flag engine to intel_engine_cs

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

 



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.

It's a fair comment though. We didn't plan for asymmetric slice fusing initially and it just happened.

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.

Thanks,

-
Lionel


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