[Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests

Chris Wilson chris at chris-wilson.co.uk
Wed Jan 13 05:41:00 PST 2016

On Wed, Jan 13, 2016 at 01:27:51PM +0000, Dave Gordon wrote:
> On 12/01/16 14:27, Chris Wilson wrote:
> >On Tue, Jan 12, 2016 at 01:56:48PM +0000, Chris Wilson wrote:
> >>But we were removing the engine->default_context as it complicated the
> >>rest of the code. I strongly prefer keeping the contexts explicit as
> >>context separation should be first and foremost in the driver.
> >
> >$ git grep kernel_context -- drivers/gpu/drm/i915/ | grep request_alloc
> >drivers/gpu/drm/i915/i915_gem_evict.c:		req = i915_gem_request_alloc(ring, dev_priv->kernel_context);
> >drivers/gpu/drm/i915/intel_overlay.c:	return i915_gem_request_alloc(ring, dev_priv->kernel_context);
> >
> >Changing those *two* callsites to pass NULL seems on the odd side, and
> >at least for the eviction case discards important information.
> >-Chris
> Those specific lines won't be touched by my patch, as *they don't
> actually exist in today's drm-intel-nightly* branch. If you want to
> add *new* calls to i915_gem_request_alloc() such as the above then
> you're quite free to pass any context you want, whether it's a real
> user context, the default kernel context explicitly, if you think
> it's important that the reader know that that specific context will
> be used; or NULL if you don't care what context is used.

They are the same calls as the ones you are patching. They are not new
calls, they are the only users of the kernel_context for emission. Which
is why I am suggesting a different series of steps to take in tidying
this up.

Chris Wilson, Intel Open Source Technology Centre

More information about the Intel-gfx mailing list