All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Lionel Landwerlin <lionel.g.landwerlin@intel.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 1/8] drm/i915: expose helper mapping exec flag engine to intel_engine_cs
Date: Thu, 3 May 2018 19:00:50 +0100	[thread overview]
Message-ID: <1e03034b-4cc9-47ec-4bc3-a3475d0d2b44@linux.intel.com> (raw)
In-Reply-To: <dcfbe001-8060-0530-f4b6-d9b1d6f048f3@intel.com>


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.

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?

> 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?

> 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.

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-05-03 18:00 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-25 11:45 [PATCH 0/8] drm/i915: per context slice/subslice powergating Lionel Landwerlin
2018-04-25 11:45 ` [PATCH 1/8] drm/i915: expose helper mapping exec flag engine to intel_engine_cs Lionel Landwerlin
2018-04-25 11:50   ` Chris Wilson
2018-04-30 14:37     ` Lionel Landwerlin
2018-05-01 11:13       ` Chris Wilson
2018-05-03 17:12       ` Tvrtko Ursulin
2018-05-03 17:31         ` Lionel Landwerlin
2018-05-03 18:00           ` Tvrtko Ursulin [this message]
2018-05-03 20:09             ` Lionel Landwerlin
2018-05-03 20:15               ` Chris Wilson
2018-04-25 11:45 ` [PATCH 2/8] drm/i915: Program RPCS for Broadwell Lionel Landwerlin
2018-04-25 11:45 ` [PATCH 3/8] drm/i915: don't specify pinned size for wa_bb pin/allocation Lionel Landwerlin
2018-04-25 11:52   ` Chris Wilson
2018-04-25 11:45 ` [PATCH 4/8] drm/i915: extract per-ctx/indirect bb programming Lionel Landwerlin
2018-04-25 11:45 ` [PATCH 5/8] drm/i915: pass wa_ctx as argument Lionel Landwerlin
2018-04-25 11:45 ` [PATCH 6/8] drm/i915: reprogram NOA muxes on context switch when using perf Lionel Landwerlin
2018-04-25 11:57   ` Chris Wilson
2018-04-25 13:23     ` Chris Wilson
2018-04-25 14:35     ` Lionel Landwerlin
2018-04-25 11:45 ` [PATCH 7/8] drm/i915: Record the sseu configuration per-context & engine Lionel Landwerlin
2018-04-25 11:45 ` [PATCH 8/8] drm/i915: Expose RPCS (SSEU) configuration to userspace Lionel Landwerlin
2018-04-26 10:00   ` Joonas Lahtinen
2018-04-26 10:22     ` Lionel Landwerlin
2018-05-03 16:04       ` Joonas Lahtinen
2018-05-03 16:14         ` Chris Wilson
2018-05-03 16:25         ` Lionel Landwerlin
2018-05-03 16:30         ` Tvrtko Ursulin
2018-05-03 17:18   ` Tvrtko Ursulin
2018-05-04 16:25     ` Lionel Landwerlin
2018-05-08  4:04       ` Rogozhkin, Dmitry V
2018-05-08  8:24         ` Tvrtko Ursulin
2018-05-08 16:00           ` Rogozhkin, Dmitry V
2018-05-08 20:56     ` Chris Wilson
2018-05-09 15:35       ` Lionel Landwerlin
2018-04-25 12:34 ` ✗ Fi.CI.CHECKPATCH: warning for drm/i915: per context slice/subslice powergating Patchwork
2018-04-25 12:36 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-04-25 12:49 ` ✓ Fi.CI.BAT: success " Patchwork
2018-04-25 15:39 ` ✗ Fi.CI.IGT: failure " Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1e03034b-4cc9-47ec-4bc3-a3475d0d2b44@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=lionel.g.landwerlin@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.