From: Daniel Vetter <daniel.vetter@ffwll.ch>
To: Eric Anholt <eric@anholt.net>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: [PATCH 0/4] prevent stalls due to tiling changes and bo reuse
Date: Thu, 22 Apr 2010 22:12:48 +0200 [thread overview]
Message-ID: <1271967172-3174-1-git-send-email-daniel.vetter@ffwll.ch> (raw)
Hi all,
This patch-set prevents stalls due to bo reuse in libdrm. After having
tried to fix the set_tiling stall both in libdrm and the kernel, I think
fixing this in the kernel is the better option: This way gem nicely
abstracts away the execution semantics. The only place where the
asynchronous nature of the gpu leaks is in the busy ioctl, which userspace
should call to check whether a mmap of the bo would stall.
Performance gains are minimal, but strictly positive (neglecting a 1% noise
level). cairo perf traces on my i945:
old: without-patches
new: with-patches
Speedups
========
xlib-rgba firefox-planet-gnome-0 62418.67 (64895.61 1.98%) -> 57833.66
(61105.65 2.92%): 1.08x speedup
A few traces more have small speedups ranging 1%-5%.
I expect this to perform better when all the other tiling related problems
are fixed - unfortunately I can't benchmark this because fixing tiling needs
portions of my pipelined fencing work (the exact fence lru accounting),
which is not (yet) ported to current drm-next.
Please review and consider merging for -next. Patches apply to current
drm-next.
Thanks, Daniel
Daniel Vetter (4):
drm/i915: don't allow tiling changes on pinned buffers
drm/i915: introduce i915_gem_object_adjust_fencing
drm/i915: adjust fence register asynchronously on tiling changes
drm/i915: report all active objects as busy
drivers/gpu/drm/i915/i915_drv.h | 8 +++-
drivers/gpu/drm/i915/i915_gem.c | 88 ++++++++++++++++++++++++++------
drivers/gpu/drm/i915/i915_gem_tiling.c | 29 +++-------
drivers/gpu/drm/i915/intel_display.c | 16 ++----
4 files changed, 92 insertions(+), 49 deletions(-)
next reply other threads:[~2010-04-22 20:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-22 20:12 Daniel Vetter [this message]
2010-04-22 20:12 ` [PATCH 1/4] drm/i915: don't allow tiling changes on pinned buffers Daniel Vetter
2010-04-23 17:34 ` Owain Ainsworth
2010-04-23 21:01 ` [PATCH] drm/i915: don't allow tiling changes on pinned buffers v2 Daniel Vetter
2010-04-22 20:12 ` [PATCH 2/4] drm/i915: introduce i915_gem_object_adjust_fencing Daniel Vetter
2010-04-22 20:12 ` [PATCH 3/4] drm/i915: adjust fence registers asynchronously on tiling changes Daniel Vetter
2010-04-22 22:28 ` [PATCH] drm/i915: adjust fence registers asynchronously on tiling changes v2 Daniel Vetter
2010-05-10 22:49 ` Eric Anholt
2010-04-22 20:12 ` [PATCH 4/4] drm/i915: report all active objects as busy Daniel Vetter
2010-04-23 9:48 ` Chris Wilson
2010-04-23 12:32 ` [PATCH] drm/i915: report all active objects as busy v2 Daniel Vetter
2010-05-02 18:13 ` Eric Anholt
2010-05-02 21:19 ` Daniel Vetter
2010-04-23 11:08 ` [PATCH 0/4] prevent stalls due to tiling changes and bo reuse Chris Wilson
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=1271967172-3174-1-git-send-email-daniel.vetter@ffwll.ch \
--to=daniel.vetter@ffwll.ch \
--cc=eric@anholt.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.