[Mesa-dev] [PATCH 6/7] i965: Reported supported context priorities to EGL/DRI

Kenneth Graunke kenneth at whitecape.org
Mon Oct 2 15:55:39 UTC 2017


On Monday, October 2, 2017 2:44:13 AM PDT Chris Wilson wrote:
> Quoting Kenneth Graunke (2017-09-29 22:59:56)
> > On Friday, September 29, 2017 1:03:14 PM PDT Chris Wilson wrote:
> > > Quoting Kenneth Graunke (2017-09-29 20:55:53)
> > > > On Friday, September 29, 2017 3:25:09 AM PDT Chris Wilson wrote:
> > > > > Hook up the RendererQuery for __DRI2_RENDERER_HAS_CONTEXT_PRIORITY to
> > > > > report the available DRM_I915_GEM_CONTEXT_SETPARAM options based on the
> > > > > the default context. The kernel will validate the request to change the
> > > > > property, so we get an accurate reflection of available support (based on
> > > > > kernel version and privilege) and we should only have to do it once
> > > > > during screen setup -- although the SETPARAM should be fast, they are
> > > > > still an ioctl each.
> > > > > 
> > > > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > > > Cc: Kenneth Graunke <kenneth at whitecape.org>
> > > > > Reviewed-by: Emil Velikov <emil.velikov at collabora.com>
> > > > > ---
> > > > >  src/mesa/drivers/dri/i965/intel_screen.c | 13 +++++++++++++
> > > > >  1 file changed, 13 insertions(+)
> > > > > 
> > > > > diff --git a/src/mesa/drivers/dri/i965/intel_screen.c b/src/mesa/drivers/dri/i965/intel_screen.c
> > > > > index 22d9f19298..112935a580 100644
> > > > > --- a/src/mesa/drivers/dri/i965/intel_screen.c
> > > > > +++ b/src/mesa/drivers/dri/i965/intel_screen.c
> > > > > @@ -1373,6 +1373,19 @@ brw_query_renderer_integer(__DRIscreen *dri_screen,
> > > > >     case __DRI2_RENDERER_HAS_TEXTURE_3D:
> > > > >        value[0] = 1;
> > > > >        return 0;
> > > > > +   case __DRI2_RENDERER_HAS_CONTEXT_PRIORITY:
> > > > > +      value[0] = 0;
> > > > > +      if (brw_hw_context_set_priority(screen->bufmgr,
> > > > > +                                   0, BRW_CONTEXT_HIGH_PRIORITY) == 0)
> > > > > +         value[0] |= __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_HIGH;
> > > > > +      if (brw_hw_context_set_priority(screen->bufmgr,
> > > > > +                                   0, BRW_CONTEXT_LOW_PRIORITY) == 0)
> > > > > +         value[0] |= __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_LOW;
> > > > > +      /* reset to default last, just in case */
> > > > > +      if (brw_hw_context_set_priority(screen->bufmgr,
> > > > > +                                   0, BRW_CONTEXT_MEDIUM_PRIORITY) == 0)
> > > > > +         value[0] |= __DRI2_RENDERER_HAS_CONTEXT_PRIORITY_MEDIUM;
> > > > > +      return 0;
> > > > >     default:
> > > > >        return driQueryRendererIntegerCommon(dri_screen, param, value);
> > > > >     }
> > > > > 
> > > > 
> > > > Interesting, you're setting the priority of the default context (which
> > > > we never use), in order to test whether it works?  Does the kernel
> > > > actually set anything in that case, or does it just ignore it?
> > > 
> > > It sets it. It's just an integer and applied if the context is ever used
> > > for execbuf. As the kernel does apply the change, we reset to the
> > > default value as the last step. Although it is not stated, we do assume
> > > the query is only performed once at screen creation, so shouldn't be any
> > > concurrency issues..
> > 
> > That sounds bad, though, context 0 is the global default context.  So
> > this could affect the rest of the system.  You still have concurrency
> > issues with e.g. VAAPI running in another process, no?
> 
> Global? No, per-fd default context. The context is a slice of driver
> state (that also may happen to hold a copy of the logical GPU state).
> -Chris

Oh, okay, if it's a per-fd default context that should probably be okay.
Nobody ought to be using the default one anyway.

--Ken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20171002/91fe5cf6/attachment-0001.sig>


More information about the mesa-dev mailing list