All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v4 1/3] drm/i915: simplify allocation of driver-internal requests
Date: Wed, 20 Jan 2016 10:20:36 +0000	[thread overview]
Message-ID: <20160120102036.GI26573@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <569F59BA.8070309@linux.intel.com>

On Wed, Jan 20, 2016 at 09:56:10AM +0000, Tvrtko Ursulin wrote:
> 
> Hi,
> 
> On 19/01/16 19:02, 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)) ...
> >
> >v4:	Rebased
> 
> Wasn't following the discussion in detail but there was always big
> resistance towards API which takes NULLs inferring some default
> state. At least in some of my past work that was an repeated
> objection. Maybe a way around it would be to have two functions,
> like:
> 
> i915_gem_request_alloc(ring); // default context
> i915_gem_request_alloc_ctx(ring, ctx); // user context

There is only one piece of code where we even want to use a default
kernel context, so it makes no sense from that point of view.
Imho, knowing the context is paramount to achieving context separation
in GEM - which we are far from achieving yet.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2016-01-20 10:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 19:02 [PATCH v4 0/3] improve handling of the driver's default (kernel) context Dave Gordon
2016-01-19 19:02 ` [PATCH v4 1/3] drm/i915: simplify allocation of driver-internal requests Dave Gordon
2016-01-20  9:56   ` Tvrtko Ursulin
2016-01-20 10:20     ` Chris Wilson [this message]
2016-01-22 11:12   ` Tvrtko Ursulin
2016-01-22 12:19     ` [PATCH] Fix pointer tests in error-handling paths Dave Gordon
2016-01-22 13:01       ` Chris Wilson
2016-01-22 13:17         ` Tvrtko Ursulin
2016-01-22 13:34           ` Chris Wilson
2016-01-25 17:54             ` Dave Gordon
2016-01-22 13:07       ` Tvrtko Ursulin
2016-01-25 16:28         ` Daniel Vetter
2016-01-25 17:07           ` Tvrtko Ursulin
2016-01-25 17:57       ` [PATCH v2] " Dave Gordon
2016-01-27 12:33         ` Maarten Lankhorst
2016-01-27 12:41           ` Tvrtko Ursulin
2016-01-27 13:45             ` Maarten Lankhorst
2016-01-19 19:02 ` [PATCH v4 2/3] drm/i915: abolish separate per-ring default_context pointers Dave Gordon
2016-01-19 19:02 ` [PATCH v4 3/3] drm/i915: tidy up a few leftovers Dave Gordon
2016-01-20  7:49 ` ✗ Fi.CI.BAT: warning for improve handling of the driver's default (kernel) context Patchwork
2016-01-20 17:31   ` Dave Gordon
2016-01-21  8:19     ` Daniel Vetter
2016-01-21  8:21 ` [PATCH v4 0/3] " Daniel Vetter
2016-01-27 15:43 ` ✓ Fi.CI.BAT: success for improve handling of the driver's default (kernel) context (rev3) Patchwork

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160120102036.GI26573@nuc-i3427.alporthouse.com \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=tvrtko.ursulin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.