All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 00/14] drm/i915: Moar plane update optimizations
Date: Thu, 23 Mar 2017 16:06:24 +0200	[thread overview]
Message-ID: <20170323140624.GT31595@intel.com> (raw)
In-Reply-To: <20170317211808.14693-1-ville.syrjala@linux.intel.com>

On Fri, Mar 17, 2017 at 11:17:54PM +0200, ville.syrjala@linux.intel.com wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> The plane updates are still taking far too long, at least with
> heavy kernel debug knobs turned on. Using kms_atomic_transitions
> I'm currently seeing numbers as high as 170 usec on my VLV.
> 
> To combat lockdep the most beneficial thing is taking the
> uncore.lock around the entire pipe update. Combined with all
> the other optimizations here I was able to push the max
> duration below 60 usec with my debug kernel.
> 
> The pre-compute stuff isn't supremely important with lockdep/etc.
> turned on, but once those are turned off the few usec saved by
> the other optimizations start to matter. With all the optimization
> and a less debug heavy kernel I was able to get the max duration
> to around 15 usec. It was around 25 usec with the current code.
> 
> Mika was saying that he's still seeing huge numbers (as high
> as 400 usec) with the current drm-tip, and that wasn't even with
> a particularly debug heavy kernel. One theory is that there's
> contention on the uncore.lock. So I'm thinking we may want to
> split the lock into two; one for gt, the other for display. Not
> starving the GPU by hogging the shared lock for display stuff
> might also be a good thing. I've not tried playing with more
> GPU heavy scenarios yet
> 
> Anyways, running out of time to play with this more today so
> I figured I'd post what I have now.
> 
> Series available here:
> git://github.com/vsyrjala/linux.git plane_update_optimization
> 
> Ville Syrjälä (14):
>   drm/i915: Extract skl_plane_ctl()
>   drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes
>   drm/i915: Extract vlv_sprite_ctl()
>   drm/i915: Extract ivb_sprite_ctl()
>   drm/i915: Extract ilk_sprite_ctl()
>   drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl()

I've pushed these to dinq. Thanks for the review.

>   drm/i915: Extract i9xx_plane_ctl()
>   drm/i915: Pre-compute plane control register value
>   drm/i915: Introduce i9xx_check_plane_surface()
>   drm/i915: Eliminate ironlake_update_primary_plane()
>   drm/i915: Use i9xx_check_plane_surface() for sprite planes as well

I'll repost these as new series.

>   drm/i915: Keep vblanks enabled during the entire pipe update
>   WIP/drm/i915: Protect the entire pipe update with uncore.lock
>   WIP/drm/i915: Nuke posting reads from plane updates

And these I'll probably leave out from the next series, and repost
separately later.

> 
>  drivers/gpu/drm/i915/i915_irq.c      |  66 ++++--
>  drivers/gpu/drm/i915/i915_trace.h    |  28 +--
>  drivers/gpu/drm/i915/intel_display.c | 436 +++++++++++++++++------------------
>  drivers/gpu/drm/i915/intel_drv.h     |  16 +-
>  drivers/gpu/drm/i915/intel_pm.c      |  11 +-
>  drivers/gpu/drm/i915/intel_sprite.c  | 355 ++++++++++++----------------
>  6 files changed, 440 insertions(+), 472 deletions(-)
> 
> -- 
> 2.10.2

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

      parent reply	other threads:[~2017-03-23 14:06 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-17 21:17 [PATCH 00/14] drm/i915: Moar plane update optimizations ville.syrjala
2017-03-17 21:17 ` [PATCH 01/14] drm/i915: Extract skl_plane_ctl() ville.syrjala
2017-03-17 21:46   ` Chris Wilson
2017-03-17 21:17 ` [PATCH 02/14] drm/i915: Use skl_plane_ctl() for the SKL "sprite" planes ville.syrjala
2017-03-17 21:48   ` Chris Wilson
2017-03-20 16:09     ` Ville Syrjälä
2017-03-20 16:16       ` Chris Wilson
2017-03-17 21:17 ` [PATCH 03/14] drm/i915: Extract i9xx_plane_ctl() ville.syrjala
2017-03-17 21:50   ` Chris Wilson
2017-03-20 16:47   ` [PATCH v2 03/14] drm/i915: Extract i9xx_plane_ctl() and ironlake_plane_ctl() ville.syrjala
2017-03-20 16:47     ` [PATCH 03.5/14] drm/i915: Nuke ironlake_plane_ctl() ville.syrjala
2017-03-17 21:17 ` [PATCH 04/14] drm/i915: Extract vlv_sprite_ctl() ville.syrjala
2017-03-17 21:51   ` Chris Wilson
2017-03-17 21:17 ` [PATCH 05/14] drm/i915: Extract ivb_sprite_ctl() ville.syrjala
2017-03-17 21:54   ` Chris Wilson
2017-03-17 21:18 ` [PATCH 06/14] drm/i915: Extract ilk_sprite_ctl() ville.syrjala
2017-03-17 21:54   ` Chris Wilson
2017-03-17 21:18 ` [PATCH 07/14] drm/i915: Extract i845_cursor_ctl() and i9xx_cursor_ctl() ville.syrjala
2017-03-17 21:58   ` Chris Wilson
2017-03-17 21:18 ` [PATCH 08/14] drm/i915: Pre-compute plane control register value ville.syrjala
2017-03-17 22:01   ` Chris Wilson
2017-03-17 21:18 ` [PATCH 09/14] drm/i915: Introduce i9xx_check_plane_surface() ville.syrjala
2017-03-17 22:04   ` Chris Wilson
2017-03-20 17:07     ` Ville Syrjälä
2017-03-20 17:33       ` Chris Wilson
2017-03-17 21:18 ` [PATCH 10/14] drm/i915: Eliminate ironlake_update_primary_plane() ville.syrjala
2017-03-17 22:06   ` Chris Wilson
2017-03-17 21:18 ` [PATCH 11/14] drm/i915: Use i9xx_check_plane_surface() for sprite planes as well ville.syrjala
2017-03-17 21:18 ` [PATCH 12/14] drm/i915: Keep vblanks enabled during the entire pipe update ville.syrjala
2017-03-17 21:28   ` Chris Wilson
2017-03-17 21:18 ` [RFC][PATCH 13/14] WIP/drm/i915: Protect the entire pipe update with uncore.lock ville.syrjala
2017-03-17 21:32   ` Chris Wilson
2017-03-17 21:18 ` [RFC][PATCH 14/14] WIP/drm/i915: Nuke posting reads from plane updates ville.syrjala
2017-03-17 22:12   ` Chris Wilson
2017-03-22 10:42     ` Maarten Lankhorst
2017-03-17 21:36 ` ✓ Fi.CI.BAT: success for drm/i915: Moar plane update optimizations Patchwork
2017-03-20 16:49 ` ✗ Fi.CI.BAT: failure for drm/i915: Moar plane update optimizations (rev3) Patchwork
2017-03-23 14:06 ` Ville Syrjälä [this message]

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=20170323140624.GT31595@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --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.