From: Daniel Vetter <daniel@ffwll.ch>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org, stable@kernel.org
Subject: Re: [PATCH] drm/i915: Seperate fence pin counting from normal bind pin counting
Date: Wed, 23 Nov 2011 13:38:44 +0100 [thread overview]
Message-ID: <20111123123844.GD3864@phenom.ffwll.local> (raw)
In-Reply-To: <1321182022-7158-1-git-send-email-chris@chris-wilson.co.uk>
On Sun, Nov 13, 2011 at 11:00:22AM +0000, 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 EDADLK upon fence starvation, the
> batchbuffer can fail with only one fence required...
>
> Fixes intel-gpu-tools/tests/gem_fenced_exec_thrash
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=38735
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> Tested-by: Paul Neumann <paul104x@yahoo.de>
> Cc: stable@kernel.org
How embarassing, I've re-reviewed the wrong patch without noticing.
Anyway, still looks good and I like the pin_count moved to the fence quite
a bit more ...
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
next prev parent reply other threads:[~2011-11-23 12:37 UTC|newest]
Thread overview: 17+ 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
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 [this message]
2011-11-23 13:04 ` [PATCH] drm/i915: Separate " Chris Wilson
2012-01-29 17:25 ` Daniel Vetter
-- strict thread matches above, loose matches on Subject: below --
2011-07-09 8:25 [PATCH] drm/i915: Seperate " Chris Wilson
2011-07-09 10:23 ` Paul Menzel
2011-07-09 10:32 ` Chris Wilson
2011-11-23 10:49 ` 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=20111123123844.GD3864@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@kernel.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.