diff mbox

[4/4] drm/i915: special-case dirtyfb for frontbuffer tracking

Message ID 1436902154-6979-6-git-send-email-przanoni@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paulo Zanoni July 14, 2015, 7:29 p.m. UTC
From: Paulo Zanoni <paulo.r.zanoni@intel.com>

First, an introduction. We currently have two types of GTT mmaps: the
"normal" old mmap, and the WC mmap. For frontbuffer-related features
that have automatic hardware tracking, only the non-WC mmap writes are
detected by the hardware. Since inside the Kernel both are treated as
ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
tracking are destined to fail.

One of the special rules defined for the WC mmaps is that the user
should call the dirtyfb IOCTL after he is done using the pointers, so
that results in an intel_fb_obj_flush() call. The problem is that the
dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
though the hardware tracking is not detecing the WC mmap operations.
So in order to fix that without having to give up the automatic
hardware tracking for GTT mmaps we transform the flush operation from
dirtyfb into a special operation: ORIGIN_DIRTYFB.

This commit fixes all the kms_frontbuffer_tracking subtests that
contain "fbc" and "mmap-wc" in their names and are currently failing
(for a total of 16 subtests).

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h      | 1 +
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

Comments

Rodrigo Vivi July 30, 2015, 11:48 p.m. UTC | #1
Very good. I should've added this when adding the dirtyfb flush...
Thanks,

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>



On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni <przanoni@gmail.com> wrote:

> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
>
> First, an introduction. We currently have two types of GTT mmaps: the
> "normal" old mmap, and the WC mmap. For frontbuffer-related features
> that have automatic hardware tracking, only the non-WC mmap writes are
> detected by the hardware. Since inside the Kernel both are treated as
> ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
> tracking are destined to fail.
>
> One of the special rules defined for the WC mmaps is that the user
> should call the dirtyfb IOCTL after he is done using the pointers, so
> that results in an intel_fb_obj_flush() call. The problem is that the
> dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
> though the hardware tracking is not detecing the WC mmap operations.
> So in order to fix that without having to give up the automatic
> hardware tracking for GTT mmaps we transform the flush operation from
> dirtyfb into a special operation: ORIGIN_DIRTYFB.
>
> This commit fixes all the kms_frontbuffer_tracking subtests that
> contain "fbc" and "mmap-wc" in their names and are currently failing
> (for a total of 16 subtests).
>
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_drv.h      | 1 +
>  drivers/gpu/drm/i915/intel_display.c | 2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index cf6761c..78d21c1 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -894,6 +894,7 @@ enum fb_op_origin {
>         ORIGIN_CPU,
>         ORIGIN_CS,
>         ORIGIN_FLIP,
> +       ORIGIN_DIRTYFB,
>  };
>
>  struct i915_fbc {
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6e3ba5f..cffaaf4a3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14479,7 +14479,7 @@ static int intel_user_framebuffer_dirty(struct
> drm_framebuffer *fb,
>         struct drm_i915_gem_object *obj = intel_fb->obj;
>
>         mutex_lock(&dev->struct_mutex);
> -       intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> +       intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
>         mutex_unlock(&dev->struct_mutex);
>
>         return 0;
> --
> 2.1.4
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
Daniel Vetter Aug. 5, 2015, 8:01 a.m. UTC | #2
On Thu, Jul 30, 2015 at 11:48:12PM +0000, Rodrigo Vivi wrote:
> Very good. I should've added this when adding the dirtyfb flush...
> Thanks,
> 
> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

Merged entire series, thanks.
-Daniel

> 
> 
> 
> On Tue, Jul 14, 2015 at 12:30 PM Paulo Zanoni <przanoni@gmail.com> wrote:
> 
> > From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >
> > First, an introduction. We currently have two types of GTT mmaps: the
> > "normal" old mmap, and the WC mmap. For frontbuffer-related features
> > that have automatic hardware tracking, only the non-WC mmap writes are
> > detected by the hardware. Since inside the Kernel both are treated as
> > ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware
> > tracking are destined to fail.
> >
> > One of the special rules defined for the WC mmaps is that the user
> > should call the dirtyfb IOCTL after he is done using the pointers, so
> > that results in an intel_fb_obj_flush() call. The problem is that the
> > dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even
> > though the hardware tracking is not detecing the WC mmap operations.
> > So in order to fix that without having to give up the automatic
> > hardware tracking for GTT mmaps we transform the flush operation from
> > dirtyfb into a special operation: ORIGIN_DIRTYFB.
> >
> > This commit fixes all the kms_frontbuffer_tracking subtests that
> > contain "fbc" and "mmap-wc" in their names and are currently failing
> > (for a total of 16 subtests).
> >
> > Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h      | 1 +
> >  drivers/gpu/drm/i915/intel_display.c | 2 +-
> >  2 files changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index cf6761c..78d21c1 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -894,6 +894,7 @@ enum fb_op_origin {
> >         ORIGIN_CPU,
> >         ORIGIN_CS,
> >         ORIGIN_FLIP,
> > +       ORIGIN_DIRTYFB,
> >  };
> >
> >  struct i915_fbc {
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 6e3ba5f..cffaaf4a3 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14479,7 +14479,7 @@ static int intel_user_framebuffer_dirty(struct
> > drm_framebuffer *fb,
> >         struct drm_i915_gem_object *obj = intel_fb->obj;
> >
> >         mutex_lock(&dev->struct_mutex);
> > -       intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> > +       intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
> >         mutex_unlock(&dev->struct_mutex);
> >
> >         return 0;
> > --
> > 2.1.4
> >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >

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

Patch

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cf6761c..78d21c1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -894,6 +894,7 @@  enum fb_op_origin {
 	ORIGIN_CPU,
 	ORIGIN_CS,
 	ORIGIN_FLIP,
+	ORIGIN_DIRTYFB,
 };
 
 struct i915_fbc {
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index 6e3ba5f..cffaaf4a3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14479,7 +14479,7 @@  static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
 	struct drm_i915_gem_object *obj = intel_fb->obj;
 
 	mutex_lock(&dev->struct_mutex);
-	intel_fb_obj_flush(obj, false, ORIGIN_GTT);
+	intel_fb_obj_flush(obj, false, ORIGIN_DIRTYFB);
 	mutex_unlock(&dev->struct_mutex);
 
 	return 0;