intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org,
	DRI Development <dri-devel@lists.freedesktop.org>,
	mahesh.meena@intel.com
Subject: Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING
Date: Thu, 27 May 2021 12:27:58 +0200	[thread overview]
Message-ID: <YK90LkRrMXTC/hF3@phenom.ffwll.local> (raw)
In-Reply-To: <59d2eee9-35c1-01fc-c226-50ad98aadb99@linux.intel.com>

On Thu, May 27, 2021 at 11:22:16AM +0100, Tvrtko Ursulin wrote:
> 
> On 27/05/2021 11:13, Daniel Vetter wrote:
> > On Wed, May 26, 2021 at 11:20:13AM +0100, Tvrtko Ursulin wrote:
> > > 
> > > On 25/05/2021 15:47, Daniel Vetter wrote:
> > > > On Tue, May 25, 2021 at 03:19:47PM +0100, Tvrtko Ursulin wrote:
> > > > > 
> > > > > + dri-devel as per process
> > > > > 
> > > > > On 25/05/2021 14:55, Tejas Upadhyay wrote:
> > > > > > v2: Only declare timeslicing if we can safely preempt userspace.
> > > > > 
> > > > > Commit message got butchered up somehow so you'll need to fix that at some
> > > > > point.
> > > > > 
> > > > > Regards,
> > > > > 
> > > > > Tvrtko
> > > > > 
> > > > > > Fixes: 8ee36e048c98 ("drm/i915/execlists: Minimalistic timeslicing")
> > > > > > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> > > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > > > > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> > > > > > ---
> > > > > >     drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
> > > > > >     include/uapi/drm/i915_drm.h                 | 1 +
> > > > > >     2 files changed, 2 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > > > index 3cca7ea2d6ea..12d165566ed2 100644
> > > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > > > > > @@ -98,6 +98,7 @@ static void set_scheduler_caps(struct drm_i915_private *i915)
> > > > > >     		MAP(HAS_PREEMPTION, PREEMPTION),
> > > > > >     		MAP(HAS_SEMAPHORES, SEMAPHORES),
> > > > > >     		MAP(SUPPORTS_STATS, ENGINE_BUSY_STATS),
> > > > > > +		MAP(TIMESLICE_BIT, TIMESLICING),
> > > > > >     #undef MAP
> > > > > >     	};
> > > > > >     	struct intel_engine_cs *engine;
> > > > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > > > index c2c7759b7d2e..af2212d6113c 100644
> > > > > > --- a/include/uapi/drm/i915_drm.h
> > > > > > +++ b/include/uapi/drm/i915_drm.h
> > > > > > @@ -572,6 +572,7 @@ typedef struct drm_i915_irq_wait {
> > > > > >     #define   I915_SCHEDULER_CAP_PREEMPTION	(1ul << 2)
> > > > > >     #define   I915_SCHEDULER_CAP_SEMAPHORES	(1ul << 3)
> > > > > >     #define   I915_SCHEDULER_CAP_ENGINE_BUSY_STATS	(1ul << 4)
> > > > > > +#define   I915_SCHEDULER_CAP_TIMESLICING	(1ul << 5)
> > > > 
> > > > Since this is uapi I think we should at least have some nice kerneldoc
> > > > that explains what exactly this is, what for (link to userspace) and all
> > > > that. Ideally also minimally filing in the gaps in our uapi docs for stuff
> > > > this references.
> > > 
> > > IIUC there is no userspace apart from IGT needing it not to fail scheduling
> > > tests on ADL.
> > > 
> > > Current tests use "has preemption + has semaphores" as a proxy to answer the
> > > "does the kernel support timeslicing" question. This stops working with the
> > > Guc backend because GuC decided not to support semaphores (for reasons yet
> > > unknown, see other thread), so explicit "has timeslicing" flag is needed in
> > > order for tests to know that GuC is supposed to support timeslicing, even if
> > > it doesn't use semaphores for inter-ring synchronisation.
> > 
> > Since this if for igt only: Cant we do just extend the check in igt with
> > an || GEN >= 12? I really hope that our future hw will continue to support
> > timeslicing ...
> 
> Not the gen 12 check, but possible I think. Explicit feature test would be better, but if definitely not allowed then along the lines of:
> 
> has_timeslicing =
> 	(has_preemption && has_semaphores) || uses_guc_submission;

That works too. Otoh what exactly is the "uses guc submission" flag and
why do we have that? I've seen media use it as a stand-in for "does the
kernel want bonded or parallel ctx?". Maybe another thing to check.

Another option, if you really think the feature flag is the best approach
(because future hw will drop timeslicing for some reason), then debugfs is
the place of igt-only api.
-Daniel

> 
> Regards,
> 
> Tvrtko
> > Also if it's not there yet, a shared helper to check for that (like we're
> > adding for relocations and stuff like that right now).
> > -Daniel
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2021-05-27 10:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 13:55 [Intel-gfx] [PATCH 0/1] drm/i915/gt: Introduce timeslicing for userspace Tejas Upadhyay
2021-05-25 13:55 ` [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING Tejas Upadhyay
2021-05-25 14:19   ` Tvrtko Ursulin
2021-05-25 14:47     ` Daniel Vetter
2021-05-26 10:20       ` Tvrtko Ursulin
2021-05-27 10:13         ` Daniel Vetter
2021-05-27 10:22           ` Tvrtko Ursulin
2021-05-27 10:27             ` Daniel Vetter [this message]
2021-05-27 12:13               ` Tvrtko Ursulin
2021-06-01 10:09               ` Tvrtko Ursulin
2021-06-01 14:25                 ` Daniel Vetter
2021-06-04 12:53             ` Tvrtko Ursulin
2021-05-25 15:48 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gt: Introduce timeslicing for userspace 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=YK90LkRrMXTC/hF3@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mahesh.meena@intel.com \
    --cc=tvrtko.ursulin@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).