From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rodrigo Vivi Subject: Re: [PATCH 4/5] drm/i915: Invalidate frontbuffer bits on FBDEV sync Date: Mon, 22 Jun 2015 16:53:54 +0000 Message-ID: References: <1434653006-5693-1-git-send-email-rodrigo.vivi@intel.com> <1434653006-5693-4-git-send-email-rodrigo.vivi@intel.com> <20150622135853.GF25769@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2034507886==" Return-path: Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by gabe.freedesktop.org (Postfix) with ESMTP id D3B6189993 for ; Mon, 22 Jun 2015 09:54:04 -0700 (PDT) Received: by iebmu5 with SMTP id mu5so119177044ieb.1 for ; Mon, 22 Jun 2015 09:54:04 -0700 (PDT) In-Reply-To: <20150622135853.GF25769@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter , Rodrigo Vivi Cc: Daniel Vetter , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============2034507886== Content-Type: multipart/alternative; boundary=90e6ba6e8bba123a9705191e1f59 --90e6ba6e8bba123a9705191e1f59 Content-Type: text/plain; charset=UTF-8 it didn't destroy the frontbuffer tracking with x running... fb_sync wasn't being called... but it indeed destroyed with igt So I agree this is not the solution to go with... I'm going to check dirty callback... thanks for the suggestion... On Mon, Jun 22, 2015 at 6:56 AM Daniel Vetter wrote: > On Thu, Jun 18, 2015 at 11:43:25AM -0700, Rodrigo Vivi wrote: > > @@ -259,6 +269,15 @@ void intel_frontbuffer_flip_complete(struct > drm_device *dev, > > struct drm_i915_private *dev_priv = dev->dev_private; > > > > mutex_lock(&dev_priv->fb_tracking.lock); > > + > > + /* > > + * Let's assume that if this asynchronous flip happened > > + * FBDEV might not be in use anymore. > > + * If this is not the case fb_sync will happen on next > > + * frontbuffer touch and invalidate bits again > > + */ > > + dev_priv->fb_tracking.fbdev_running = false; > > This pretty much destroys frontbuffer tracking for everyone if they boot > up with fbdev. > > Since this seems to be epic fun indeed I think what we need to do is: > - Fill out the ->dirty callback. > - Extend the drm fbdev helpers to call ->dirty at all suitable places if > needed. > > For an example of how to do this all see udl/udl_fb.c. Imo a good patch > would be to replace all the udl special casing with the new fbdev helpers, > just as a demonstration patch. i915 isn't the only driver where every > frontbuffer change must involve some manual driver action, there's no > reason we need to roll our own solution. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > --90e6ba6e8bba123a9705191e1f59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
it didn't destroy the frontbuffer tracking with x runn= ing... fb_sync wasn't being called... but it indeed destroyed with igt = So I agree this is not the solution to go with...

I'= m going to check dirty callback... thanks for the suggestion...
<= br>


On Mon, Jun 22, 2015 at 6:56 AM Daniel Vetter <daniel@ffwll.ch> wrote:
On Thu, Jun 18, 2015 at 11:43:25AM -0700, Rodrigo Vivi wrote:
> @@ -259,6 +269,15 @@ void intel_frontbuffer_flip_complete(struct drm_d= evice *dev,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0struct drm_i915_private *dev_priv =3D dev-&g= t;dev_private;
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0mutex_lock(&dev_priv->fb_tracking.loc= k);
> +
> +=C2=A0 =C2=A0 =C2=A0/*
> +=C2=A0 =C2=A0 =C2=A0 * Let's assume that if this asynchronous fli= p happened
> +=C2=A0 =C2=A0 =C2=A0 * FBDEV might not be in use anymore.
> +=C2=A0 =C2=A0 =C2=A0 * If this is not the case fb_sync will happen on= next
> +=C2=A0 =C2=A0 =C2=A0 * frontbuffer touch and invalidate bits again > +=C2=A0 =C2=A0 =C2=A0 */
> +=C2=A0 =C2=A0 =C2=A0dev_priv->fb_tracking.fbdev_running =3D false;=

This pretty much destroys frontbuffer tracking for everyone if they boot up with fbdev.

Since this seems to be epic fun indeed I think what we need to do is:
- Fill out the ->dirty callback.
- Extend the drm fbdev helpers to call ->dirty at all suitable places if=
=C2=A0 needed.

For an example of how to do this all see udl/udl_fb.c. Imo a good patch
would be to replace all the udl special casing with the new fbdev helpers,<= br> just as a demonstration patch. i915 isn't the only driver where every frontbuffer change must involve some manual driver action, there's no reason we need to roll our own solution.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http:= //blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-= gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo= /intel-gfx
--90e6ba6e8bba123a9705191e1f59-- --===============2034507886== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHA6Ly9saXN0 cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1hbi9saXN0aW5mby9pbnRlbC1nZngK --===============2034507886==--