[Intel-gfx] [PATCH v3 1/3] drm/i915: simplify allocation of driver-internal requests
david.s.gordon at intel.com
Wed Jan 13 05:27:51 PST 2016
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.
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.
dev_priv->kernel_context carries exactly the same amount of information
as NULL; they both mean "I don't have a specific context to use here, so
(I'm going to) use the one the driver provides for such activities".
Having the option of using NULL rather than"dev_priv->kernel_context"
explicitly doesn't prevent you from doing so where the caller cares. But
I think most callers *don't* care.
More information about the Intel-gfx