All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Seung-Woo Kim <sw0312.kim@samsung.com>,
	stable <stable@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	Lyude <cpaul@redhat.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Vincent Abriou <vincent.abriou@st.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Subject: Re: [PATCH] drm: Don't force all planes to be added to the state due to zpos
Date: Mon, 10 Oct 2016 16:32:29 +0300	[thread overview]
Message-ID: <20161010133229.GG4329@intel.com> (raw)
In-Reply-To: <CAKMK7uGjFGHwzH4Fp6_gfV2KiFYjJPjGWUA_8ht0ts3nyy_Cmg@mail.gmail.com>

On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> >> I think the
> >> proper way is to keep track of a per-plane zpos changed (or compute
> >> that ad-hoc, we have both states). And only grab more planes if a zpos
> >> value changed.
> >
> > Doesn't work with normalized zpos. The plane's actual zpos may be
> > unchanged even if the normalized zpos changes.
> 
> Well I meant to do a first loop to check for any zpos changes, and
> only then add all the planes. If no one touched zpos, then also no
> normalized zpos can change. I think at least ... Or what am I missing?

Enabling planes can change zpos. Which is what's currently causing all
the planes to be added to the state every time the cursor is
enabled/disabled on i915. Which isn't nice.

And anyway adding all the planes to the state when some zpos change
happens is entirely pointless on i915. There's no need to run through
any of .check_plane() hooks in this case. The only thing we need to
do is rewrite the sprite control registers (+ base addresses of course
to arm the update). So we could just add the sprite planes to state
after the .check_plane() stuff has been done so that we'll just get the
.commit_plane(). So knowing somehting about the hardware allows us to
do a much better job of this.

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

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Seung-Woo Kim <sw0312.kim@samsung.com>,
	stable <stable@vger.kernel.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
	Lyude <cpaul@redhat.com>, Vincent Abriou <vincent.abriou@st.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH] drm: Don't force all planes to be added to the state due to zpos
Date: Mon, 10 Oct 2016 16:32:29 +0300	[thread overview]
Message-ID: <20161010133229.GG4329@intel.com> (raw)
In-Reply-To: <CAKMK7uGjFGHwzH4Fp6_gfV2KiFYjJPjGWUA_8ht0ts3nyy_Cmg@mail.gmail.com>

On Mon, Oct 10, 2016 at 03:14:22PM +0200, Daniel Vetter wrote:
> On Mon, Oct 10, 2016 at 2:56 PM, Ville Syrj�l�
> <ville.syrjala@linux.intel.com> wrote:
> >> I think the
> >> proper way is to keep track of a per-plane zpos changed (or compute
> >> that ad-hoc, we have both states). And only grab more planes if a zpos
> >> value changed.
> >
> > Doesn't work with normalized zpos. The plane's actual zpos may be
> > unchanged even if the normalized zpos changes.
> 
> Well I meant to do a first loop to check for any zpos changes, and
> only then add all the planes. If no one touched zpos, then also no
> normalized zpos can change. I think at least ... Or what am I missing?

Enabling planes can change zpos. Which is what's currently causing all
the planes to be added to the state every time the cursor is
enabled/disabled on i915. Which isn't nice.

And anyway adding all the planes to the state when some zpos change
happens is entirely pointless on i915. There's no need to run through
any of .check_plane() hooks in this case. The only thing we need to
do is rewrite the sprite control registers (+ base addresses of course
to arm the update). So we could just add the sprite planes to state
after the .check_plane() stuff has been done so that we'll just get the
.commit_plane(). So knowing somehting about the hardware allows us to
do a much better job of this.

-- 
Ville Syrj�l�
Intel OTC

  reply	other threads:[~2016-10-10 13:32 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-10 12:19 [PATCH] drm: Don't force all planes to be added to the state due to zpos ville.syrjala
2016-10-10 12:19 ` ville.syrjala
2016-10-10 12:46 ` Daniel Vetter
2016-10-10 12:56   ` Ville Syrjälä
2016-10-10 12:56     ` Ville Syrjälä
2016-10-10 13:14     ` Daniel Vetter
2016-10-10 13:32       ` Ville Syrjälä [this message]
2016-10-10 13:32         ` Ville Syrjälä
2016-10-10 13:47         ` Daniel Vetter
2016-10-10 13:47           ` Daniel Vetter
2016-10-10 14:50 ` [PATCH v2] " ville.syrjala
2016-10-10 15:31   ` Daniel Vetter
2016-10-10 15:31     ` Daniel Vetter
2016-10-25 14:43 ` [PATCH] " Ville Syrjälä
2016-10-25 14:43   ` Ville Syrjälä
2016-10-25 20:53   ` Sean Paul
2016-10-25 20:53     ` Sean Paul
2016-10-26 14:09     ` Benjamin Gaignard
2016-10-26 16:48       ` Daniel Vetter
2016-10-26 16:48         ` 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=20161010133229.GG4329@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=cpaul@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=m.szyprowski@samsung.com \
    --cc=stable@vger.kernel.org \
    --cc=sw0312.kim@samsung.com \
    --cc=vincent.abriou@st.com \
    /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.