All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eugeni Dodonov <eugeni@dodonov.net>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Separate fence pin counting from normal bind pin counting
Date: Fri, 02 Sep 2011 15:43:51 -0300	[thread overview]
Message-ID: <4E6123E7.5070804@dodonov.net> (raw)
In-Reply-To: <1307340601-32259-1-git-send-email-chris@chris-wilson.co.uk>

On 06/06/2011 03:10 AM, Chris Wilson wrote:
> In order to correctly account for reserving space in the GTT and fences
> for a batch buffer, we need to independently track whether the fence is
> pinned due to a fenced GPU access in the batch from from whether the
> buffer is pinned in the aperture. Currently we count the fenced as
> pinned if the buffer has already been seen in the execbuffer. This leads
> to a false accounting of available fence registers, causing frequent
> mass evictions. Worse, if coupled with the change to make
> i915_gem_object_get_fence() report EDEADLK upon fence starvation, the
> batchbuffer can fail with only one fence required...
>
> In order to trigger the false accounting, one can simply submit two
> batches containing the same 18 [2*(num_avail_fences+1)] buffers. In the
> first batch, the first 9 buffers require a fence. In the second batch,
> the latter half require a fence. Due to prior pinning of all buffers,
> which also then pins the fence register, this results in the false
> starvation and forced eviction of the currently active buffers.
> Admittedly, such batch buffers require pipelined fencing...
>
> Note, this fixes a severe performance regression with heavy fenced BLT
> users such as the Cairo traces firefox-planet-gnome and midori-zoomed on
> gen3.
>
> Signed-off-by: Chris Wilson<chris at chris-wilson.co.uk>
> Cc: Daniel Vetter<daniel.vetter at ffwll.ch>
> Reviewed-by: Daniel Vetter<daniel.vetter at ffwll.ch>
> ---
>   drivers/gpu/drm/i915/i915_drv.h            |   21 ++++
>   drivers/gpu/drm/i915/i915_gem.c            |    7 +-
>   drivers/gpu/drm/i915/i915_gem_execbuffer.c |  161 +++++++++++++++++++---------
>   drivers/gpu/drm/i915/intel_display.c       |   21 +++-
>   4 files changed, 155 insertions(+), 55 deletions(-)
>

Bringing back this June's thread to live, I noticed that this patch 
never made it to the kernel.. is anything still pending on it by a 
chance, or it was just MIA?

-- 
Eugeni Dodonov

  reply	other threads:[~2011-09-02 18:44 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-04  8:55 [PATCH] drm/i915: Seperate fence pin counting from normal bind pin counting Chris Wilson
2011-06-04 17:38 ` Keith Packard
2011-06-04 18:31   ` Chris Wilson
2011-06-05  1:07     ` Keith Packard
2011-06-04 22:18   ` Chris Wilson
2011-06-05 20:55 ` Daniel Vetter
2011-06-06  6:10   ` [PATCH] drm/i915: Separate " Chris Wilson
2011-09-02 18:43     ` Eugeni Dodonov [this message]
2011-11-13 11:00 ` [PATCH] drm/i915: Seperate " Chris Wilson
2011-11-13 11:21   ` Paul Menzel
2011-11-23 12:38   ` Daniel Vetter
2011-11-23 13:04     ` [PATCH] drm/i915: Separate " Chris Wilson
2012-01-29 17:25       ` Daniel Vetter

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=4E6123E7.5070804@dodonov.net \
    --to=eugeni@dodonov.net \
    --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 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.