All of lore.kernel.org
 help / color / mirror / Atom feed
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(-)

             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.