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

[Dave Gordon]

On 13/01/16 13:41, Chris Wilson wrote:
> 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

As of now (i.e. pre-conversion of the default_context pointer), there 
are *eight* calls to i915_gem_request_alloc(), but NONE in i915_gem_evict.c:

drm-intel-nightly$ git grep -c 
'i915_gem_request_alloc(.*default_context' -- drivers/gpu/drm/i915/
drivers/gpu/drm/i915/i915_gem.c:3
drivers/gpu/drm/i915/intel_display.c:1
drivers/gpu/drm/i915/intel_overlay.c:4

So you must be looking in a different tree, presumably one where you've 
already done some other bunch of cleanups in a different order.

.Dave.