From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH v6 12/25] drm/i915: Unify intel_ring_begin()
Date: Wed, 27 Apr 2016 13:54:08 +0300 [thread overview]
Message-ID: <1461754448.3986.34.camel@linux.intel.com> (raw)
In-Reply-To: <20160427093744.GX27856@nuc-i3427.alporthouse.com>
On ke, 2016-04-27 at 10:37 +0100, Chris Wilson wrote:
> On Wed, Apr 27, 2016 at 12:21:52PM +0300, Joonas Lahtinen wrote:
> >
> > On ti, 2016-04-26 at 21:06 +0100, Chris Wilson wrote:
> > >
> > > - ret = intel_logical_ring_begin(req, 2 + 2 * GEN9_NUM_MOCS_ENTRIES);
> > > - if (ret) {
> > > - DRM_DEBUG("intel_logical_ring_begin failed %d\n", ret);
> > These debugs disappear in silence. Could be worthy a note in the commit
> > message.
> "Remove useless debugging following WARN in case of real error." ?
Sounds ok.
>
> >
> > >
> > > void intel_ring_reserved_space_cancel(struct intel_ringbuffer *ringbuf)
> > > {
> > > - WARN_ON(ringbuf->reserved_in_use);
> > > -
> > > + GEM_BUG_ON(!ringbuf->reserved_size);
> > > ringbuf->reserved_size = 0;
> > > - ringbuf->reserved_in_use = false;
> > > }
> > >
> > > void intel_ring_reserved_space_use(struct intel_ringbuffer *ringbuf)
> > > {
> > > - WARN_ON(ringbuf->reserved_in_use);
> > > -
> > > - ringbuf->reserved_in_use = true;
> > > - ringbuf->reserved_tail = ringbuf->tail;
> > > + GEM_BUG_ON(!ringbuf->reserved_size);
> > > + ringbuf->reserved_size = 0;
> > > }
> > >
> > Above two functions are now the same, I'd remove the _cancel variant.
> I thought semantically they were different until the next patch. Moving
> reserved onto the request, makes it moot as the cancellation is just
> deleting the incomplete request.
>
> >
> > >
> > > void intel_ring_reserved_space_end(struct intel_ringbuffer *ringbuf)
> > > {
> > > - WARN_ON(!ringbuf->reserved_in_use);
> > > - if (ringbuf->tail > ringbuf->reserved_tail) {
> > > - WARN(ringbuf->tail > ringbuf->reserved_tail + ringbuf->reserved_size,
> > > - "request reserved size too small: %d vs %d!\n",
> > > - ringbuf->tail - ringbuf->reserved_tail, ringbuf->reserved_size);
> > > - } else {
> > > + GEM_BUG_ON(ringbuf->reserved_size);
> > > +}
> > > +
> > > +static int wait_for_space(struct drm_i915_gem_request *req, int bytes)
> > > +{
> > > + struct intel_ringbuffer *ringbuf = req->ringbuf;
> > > + struct intel_engine_cs *engine = req->engine;
> > > + struct drm_i915_gem_request *target;
> > > +
> > > + intel_ring_update_space(ringbuf);
> > > + if (ringbuf->space >= bytes)
> > > + return 0;
> > > +
> > > + /* The whole point of reserving space is to not wait! */
> > > + GEM_BUG_ON(!ringbuf->reserved_size);
> > reserved_size = 0 would indicate we're at __i915_add_request, but the
> > comment and test are not clearest. reserved_size being zero does not
> > directly indicate "aha, reserved bytes are being used", it could very
> > well be no reserved_size was requested. But right.
> /* The whole point of reserving space before the request was not to wait! */
> doesn't fit :|
>
> /* Space is reserved in the ringbuffer for finalising the request,
> * as that cannot be allowed to fail. During request finalisation,
> * reserved_space is set to 0 to stop the overallocation and the
> * assumption is that then we never need to wait (and so risk
> * EINTR).
> */
Looks good too.
Regards, Joonas
> -Chris
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-04-27 10:52 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 20:05 Premature unpinning, finally? Chris Wilson
2016-04-26 20:05 ` [PATCH v6 01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release Chris Wilson
2016-04-27 12:45 ` Tvrtko Ursulin
2016-04-26 20:05 ` [PATCH v6 02/25] drm/i915/overlay: Replace i915_gem_obj_ggtt_offset() with the known flip_addr Chris Wilson
[not found] ` <1461701180-895-1-git-send-email-chris-Y6uKTt2uX1cEflXRtASbqLVCufUGDwFn@public.gmane.org>
2016-04-26 20:05 ` [PATCH v6 03/25] io-mapping: Specify mapping size for io_mapping_map_wc() Chris Wilson
2016-04-26 20:05 ` [PATCH v6 04/25] drm/i915: Introduce i915_vm_to_ggtt() Chris Wilson
2016-04-26 20:06 ` [PATCH v6 05/25] drm/i915: Move ioremap_wc tracking onto VMA Chris Wilson
2016-04-26 20:06 ` [PATCH v6 06/25] drm/i915: Use i915_vma_pin_iomap on the ringbuffer object Chris Wilson
2016-04-26 20:06 ` [PATCH v6 07/25] drm/i915: Mark the current context as lost on suspend Chris Wilson
2016-04-26 20:06 ` [PATCH v6 08/25] drm/i915: L3 cache remapping is part of context switching Chris Wilson
2016-04-26 20:06 ` [PATCH v6 09/25] drm/i915: Consolidate L3 remapping LRI Chris Wilson
2016-04-26 20:06 ` [PATCH v6 10/25] drm/i915: Remove early l3-remap Chris Wilson
2016-04-26 20:06 ` [PATCH v6 11/25] drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use Chris Wilson
2016-04-26 20:06 ` [PATCH v6 12/25] drm/i915: Unify intel_ring_begin() Chris Wilson
2016-04-27 9:21 ` Joonas Lahtinen
2016-04-27 9:37 ` Chris Wilson
2016-04-27 10:54 ` Joonas Lahtinen [this message]
2016-04-26 20:06 ` [PATCH v6 13/25] drm/i915: Remove the identical implementations of request space reservation Chris Wilson
2016-04-27 10:27 ` Joonas Lahtinen
2016-04-26 20:06 ` [PATCH v6 14/25] drm/i915: Manually unwind after a failed request allocation Chris Wilson
2016-04-27 10:48 ` Joonas Lahtinen
2016-04-27 10:59 ` Chris Wilson
2016-04-27 12:51 ` Tvrtko Ursulin
2016-04-27 12:58 ` Chris Wilson
2016-04-27 13:03 ` Tvrtko Ursulin
2016-04-26 20:06 ` [PATCH v6 15/25] drm/i915: Preallocate enough space for the average request Chris Wilson
2016-04-27 13:15 ` Tvrtko Ursulin
2016-04-27 13:26 ` Chris Wilson
2016-04-26 20:06 ` [PATCH v6 16/25] drm/i915: Update execlists context descriptor format commentary Chris Wilson
2016-04-27 13:22 ` Tvrtko Ursulin
2016-04-26 20:06 ` [PATCH v6 17/25] drm/i915: Assign every HW context a unique ID Chris Wilson
2016-04-26 20:06 ` [PATCH v6 18/25] drm/i915: Replace the pinned context address with its " Chris Wilson
2016-04-26 20:06 ` [PATCH v6 19/25] drm/i915: Refactor execlists default context pinning Chris Wilson
2016-04-26 20:06 ` [PATCH v6 20/25] drm/i915: Move the magical deferred context allocation into the request Chris Wilson
2016-04-26 20:06 ` [PATCH v6 21/25] drm/i915: Move releasing of the GEM request from free to retire/cancel Chris Wilson
2016-04-26 20:06 ` [PATCH v6 22/25] drm/i915: Track the previous pinned context inside the request Chris Wilson
2016-04-26 20:06 ` [PATCH v6 23/25] drm/i915: Store LRC hardware id in " Chris Wilson
2016-04-26 20:06 ` [PATCH v6 24/25] drm/i915: Stop tracking execlists retired requests Chris Wilson
2016-04-26 20:06 ` [PATCH v6 25/25] drm/i915: Unify GPU resets upon shutdown Chris Wilson
2016-04-27 7:24 ` ✗ Fi.CI.BAT: failure for series starting with [v6,01/25] drm/i915/fbdev: Call intel_unpin_fb_obj() on release 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=1461754448.3986.34.camel@linux.intel.com \
--to=joonas.lahtinen@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox