diff mbox

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

Message ID 568E5B5F.8020109@intel.com (mailing list archive)
State New, archived
Headers show

Commit Message

Dave Gordon Jan. 7, 2016, 12:34 p.m. UTC
On 07/01/16 11:58, Chris Wilson wrote:
> On Thu, Jan 07, 2016 at 10:20:50AM +0000, Dave Gordon wrote:
>> There are a number of places where the driver needs a request, but isn't
>> working on behalf of any specific user or in a specific context. At
>> present, we associate them with the per-engine default context. A future
>> patch will abolish those per-engine context pointers; but we can already
>> eliminate a lot of the references to them, just by making the allocator
>> allow NULL as a shorthand for "an appropriate context for this ring",
>> which will mean that the callers don't need to know anything about how
>> the "appropriate context" is found (e.g. per-ring vs per-device, etc).
>>
>> So this patch renames the existing i915_gem_request_alloc(), and makes
>> it local (static inline), and replaces it with a wrapper that provides
>> a default if the context is NULL, and also has a nicer calling
>> convention (doesn't require a pointer to an output parameter). Then we
>> change all callers to use the new convention:
>> OLD:
>> 	err = i915_gem_request_alloc(ring, user_ctx, &req);
>> 	if (err) ...
>> NEW:
>> 	req = i915_gem_request_alloc(ring, user_ctx);
>> 	if (IS_ERR(req)) ...
>> OLD:
>> 	err = i915_gem_request_alloc(ring, ring->default_context, &req);
>> 	if (err) ...
>> NEW:
>> 	req = i915_gem_request_alloc(ring, NULL);
>> 	if (IS_ERR(req)) ...
>
> Nak. You haven't fixed i915_gem_request_alloc() at all.
>
> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=82c72e1a2b4385f0ab07dccee45acef38303e96f
> is the patch I have been carrying ever since.
> -Chris

I think you'll find that the version of i915_gem_request_alloc() I've 
implemented is equivalent to yours, with the *additional* (and better) 
semantic of not requiring the caller to specify (ring->default_param) as 
the context parameter (which is the main point, as far as I'm concerned; 
making the calling convention nicer was just incidental).

*MINE*:
...

You seem to have done EXACTLY THE SAME transformation of the function 
signature (except I remembered to add __must_check, and wrote some 
kerneldoc for it), so what's not to like?

I haven't done anything to {__}i915_gem_object_sync(), but that's a 
separate issue that you can fix on top of this.

.Dave.

Comments

Chris Wilson Jan. 7, 2016, 4:56 p.m. UTC | #1
On Thu, Jan 07, 2016 at 12:34:39PM +0000, Dave Gordon wrote:
> On 07/01/16 11:58, Chris Wilson wrote:
> >On Thu, Jan 07, 2016 at 10:20:50AM +0000, Dave Gordon wrote:
> >>There are a number of places where the driver needs a request, but isn't
> >>working on behalf of any specific user or in a specific context. At
> >>present, we associate them with the per-engine default context. A future
> >>patch will abolish those per-engine context pointers; but we can already
> >>eliminate a lot of the references to them, just by making the allocator
> >>allow NULL as a shorthand for "an appropriate context for this ring",
> >>which will mean that the callers don't need to know anything about how
> >>the "appropriate context" is found (e.g. per-ring vs per-device, etc).
> >>
> >>So this patch renames the existing i915_gem_request_alloc(), and makes
> >>it local (static inline), and replaces it with a wrapper that provides
> >>a default if the context is NULL, and also has a nicer calling
> >>convention (doesn't require a pointer to an output parameter). Then we
> >>change all callers to use the new convention:
> >>OLD:
> >>	err = i915_gem_request_alloc(ring, user_ctx, &req);
> >>	if (err) ...
> >>NEW:
> >>	req = i915_gem_request_alloc(ring, user_ctx);
> >>	if (IS_ERR(req)) ...
> >>OLD:
> >>	err = i915_gem_request_alloc(ring, ring->default_context, &req);
> >>	if (err) ...
> >>NEW:
> >>	req = i915_gem_request_alloc(ring, NULL);
> >>	if (IS_ERR(req)) ...
> >
> >Nak. You haven't fixed i915_gem_request_alloc() at all.
> >
> >http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=82c72e1a2b4385f0ab07dccee45acef38303e96f
> >is the patch I have been carrying ever since.
> >-Chris
> 
> I think you'll find that the version of i915_gem_request_alloc()
> I've implemented is equivalent to yours, with the *additional* (and
> better) semantic of not requiring the caller to specify
> (ring->default_param) as the context parameter (which is the main
> point, as far as I'm concerned; making the calling convention nicer
> was just incidental).

No. Specifying the context is crucial to request allocation. The issue
in the current function call chains are the requests appear out of
nowhere rather than being created with explicit context.

Hiding the context is bad.
-Chris
Dave Gordon Jan. 11, 2016, 12:45 p.m. UTC | #2
On 07/01/16 16:56, Chris Wilson wrote:
> On Thu, Jan 07, 2016 at 12:34:39PM +0000, Dave Gordon wrote:
>> On 07/01/16 11:58, Chris Wilson wrote:
>>> On Thu, Jan 07, 2016 at 10:20:50AM +0000, Dave Gordon wrote:
>>>> There are a number of places where the driver needs a request, but isn't
>>>> working on behalf of any specific user or in a specific context. At
>>>> present, we associate them with the per-engine default context. A future
>>>> patch will abolish those per-engine context pointers; but we can already
>>>> eliminate a lot of the references to them, just by making the allocator
>>>> allow NULL as a shorthand for "an appropriate context for this ring",
>>>> which will mean that the callers don't need to know anything about how
>>>> the "appropriate context" is found (e.g. per-ring vs per-device, etc).
>>>>
>>>> So this patch renames the existing i915_gem_request_alloc(), and makes
>>>> it local (static inline), and replaces it with a wrapper that provides
>>>> a default if the context is NULL, and also has a nicer calling
>>>> convention (doesn't require a pointer to an output parameter). Then we
>>>> change all callers to use the new convention:
>>>> OLD:
>>>> 	err = i915_gem_request_alloc(ring, user_ctx, &req);
>>>> 	if (err) ...
>>>> NEW:
>>>> 	req = i915_gem_request_alloc(ring, user_ctx);
>>>> 	if (IS_ERR(req)) ...
>>>> OLD:
>>>> 	err = i915_gem_request_alloc(ring, ring->default_context, &req);
>>>> 	if (err) ...
>>>> NEW:
>>>> 	req = i915_gem_request_alloc(ring, NULL);
>>>> 	if (IS_ERR(req)) ...
>>>
>>> Nak. You haven't fixed i915_gem_request_alloc() at all.
>>>
>>> http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=breadcrumbs&id=82c72e1a2b4385f0ab07dccee45acef38303e96f
>>> is the patch I have been carrying ever since.
>>> -Chris
>>
>> I think you'll find that the version of i915_gem_request_alloc()
>> I've implemented is equivalent to yours, with the *additional* (and
>> better) semantic of not requiring the caller to specify
>> (ring->default_param) as the context parameter (which is the main
>> point, as far as I'm concerned; making the calling convention nicer
>> was just incidental).
>
> No. Specifying the context is crucial to request allocation. The issue
> in the current function call chains are the requests appear out of
> nowhere rather than being created with explicit context.
>
> Hiding the context is bad.
> -Chris

Why would it be better to name dev_priv->kernel_context at every 
callsite rather than once in the called function (especially in my 
version where it's very obvious that the new wrapper provides that 
default before calling the original underlying allocator).

The context is only important to callers who have one in hand. To the 
others, it's an irrelevance; they're just saying, "hey, I want a request 
but it's not connected to any context I know of, so gimme a default". 
The proof of that is that we can switch them from a per-engine default 
to a per-driver default without changing anything else about them. They 
really don't need to know how to find the default context, so let the 
allocator find it for them.

<aside>
Suppose we some day decide that perhaps there should be *multiple* 
/kernel contexts/ (maybe for greater parallelism); my approach will let 
us spread non-user requests across all suitable contexts just by 
implementing that choice in one place (the new wrapper). By contrast, 
naming the default kernel context at every callsite would make this a 
far more invasive change.
</aside>

It is a commonplace of modern software practice that encapsulating (and 
thus hiding) irrelevant detail is GOOD practice; it is the exposing of 
internal implementation detail that is BAD.

.Dave.
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/i915_drv.h 
b/drivers/gpu/drm/i915/i915_drv.h
index c6dd4db..c2b000a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2260,9 +2260,9 @@  struct drm_i915_gem_request {

  };

-int i915_gem_request_alloc(struct intel_engine_cs *ring,
-			   struct intel_context *ctx,
-			   struct drm_i915_gem_request **req_out);
+struct drm_i915_gem_request * __must_check
+i915_gem_request_alloc(struct intel_engine_cs *engine,
+		       struct intel_context *ctx);
  void i915_gem_request_cancel(struct drm_i915_gem_request *req);
  void i915_gem_request_free(struct kref *req_ref);
  int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
...

*YOURS*:
diff --git a/drivers/gpu/drm/i915/i915_gem_request.h 
b/drivers/gpu/drm/i915/i915_gem_request.h
index 0869505..2da9e0b 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.h
+++ b/drivers/gpu/drm/i915/i915_gem_request.h
@@ -118,9 +118,9 @@  struct drm_i915_gem_request {
  	int elsp_submitted;
  };

-int i915_gem_request_alloc(struct intel_engine_cs *ring,
-			   struct intel_context *ctx,
-			   struct drm_i915_gem_request **req_out);
+struct drm_i915_gem_request *
+i915_gem_request_alloc(struct intel_engine_cs *ring,
+		       struct intel_context *ctx);
  void i915_gem_request_cancel(struct drm_i915_gem_request *req);
  int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
  				   struct drm_file *file);