Re: [PATCH 4/5] drm/i915: Invalidate frontbuffer bits on FBDEV sync

From: Rodrigo Vivi <rodrigo.vivi@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>, Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH 4/5] drm/i915: Invalidate frontbuffer bits on FBDEV sync
Date: Mon, 22 Jun 2015 16:53:54 +0000	[thread overview]
Message-ID: <CABVU7+sK7BZqSsau18ySv8vuybeem1rcm23ECiBHFW3aM8oWRg@mail.gmail.com> (raw)
In-Reply-To: <20150622135853.GF25769@phenom.ffwll.local>

[-- Attachment #1.1: Type: text/plain, Size: 1804 bytes --]

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 <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_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
>

[-- Attachment #1.2: Type: text/html, Size: 2549 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx