[Intel-gfx] [PATCH 4/5] drm/i915: Invalidate frontbuffer bits on FBDEV sync

[Rodrigo Vivi]

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 at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20150622/8b4ab6ac/attachment.html>