[PATCH 1/2] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[PATCH 1/2] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Daniel Vetter]

We can't elide the fb tracking invalidate if the buffer is already in
the right domain since that would lead to missed screen updates. I'm
pretty sure I've written this already before but must have gotten lost
unfortunately :(

Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f79ce9f22312..36f5e86f9048 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3940,6 +3940,9 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
 	struct i915_vma *vma;
 	int ret;
 
+	if (write)
+		intel_fb_obj_invalidate(obj, ORIGIN_GTT);
+
 	if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
 		return 0;
 
@@ -3982,9 +3985,6 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
 		obj->dirty = 1;
 	}
 
-	if (write)
-		intel_fb_obj_invalidate(obj, ORIGIN_GTT);
-
 	trace_i915_gem_object_change_domain(obj,
 					    old_read_domains,
 					    old_write_domain);
@@ -4224,6 +4224,9 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
 	uint32_t old_write_domain, old_read_domains;
 	int ret;
 
+	if (write)
+		intel_fb_obj_invalidate(obj, ORIGIN_CPU);
+
 	if (obj->base.write_domain == I915_GEM_DOMAIN_CPU)
 		return 0;
 
@@ -4256,9 +4259,6 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
 		obj->base.write_domain = I915_GEM_DOMAIN_CPU;
 	}
 
-	if (write)
-		intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-
 	trace_i915_gem_object_change_domain(obj,
 					    old_read_domains,
 					    old_write_domain);
-- 
2.1.4

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

[PATCH 2/2] drm/i915: Unique frontbuffer_bits for sprites

[Daniel Vetter]

Each bo attachment point (so each data plane on planar yuv if we'd
support that) needs its own frontbuffer tracking bit, otherwise the
collisions could result in invalide/flush getting out of sync.

We have more than one sprite plane, and had (on vlv) 1 year before
I've even written the frontbuffer tracking code. Oops. Fix this, which
is much easier with Ville's rework to store the frontbuffer_bit in the
intel_plane structure.

Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/i915_drv.h     | 10 +++++-----
 drivers/gpu/drm/i915/intel_psr.c    |  2 +-
 drivers/gpu/drm/i915/intel_sprite.c |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ea9caf22283f..9d63a2067443 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1962,19 +1962,19 @@ struct drm_i915_gem_object_ops {
  *
  * We have one bit per pipe and per scanout plane type.
  */
-#define INTEL_FRONTBUFFER_BITS_PER_PIPE 4
+#define INTEL_FRONTBUFFER_BITS_PER_PIPE 8
 #define INTEL_FRONTBUFFER_BITS \
 	(INTEL_FRONTBUFFER_BITS_PER_PIPE * I915_MAX_PIPES)
 #define INTEL_FRONTBUFFER_PRIMARY(pipe) \
 	(1 << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
 #define INTEL_FRONTBUFFER_CURSOR(pipe) \
 	(1 << (1 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
-#define INTEL_FRONTBUFFER_SPRITE(pipe) \
-	(1 << (2 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
+#define INTEL_FRONTBUFFER_SPRITE(pipe, plane) \
+	(1 << (2 + (plane) +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
 #define INTEL_FRONTBUFFER_OVERLAY(pipe) \
-	(1 << (3 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
+	(1 << (7 +(INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe))))
 #define INTEL_FRONTBUFFER_ALL_MASK(pipe) \
-	(0xf << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
+	(0xff << (INTEL_FRONTBUFFER_BITS_PER_PIPE * (pipe)))
 
 struct drm_i915_gem_object {
 	struct drm_gem_object base;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d79ba58637d7..dd3cbeeac386 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -714,7 +714,7 @@ void intel_psr_flush(struct drm_device *dev,
 	 * invalidation through frontbuffer rendering.
 	 */
 	if (IS_HASWELL(dev) &&
-	    (frontbuffer_bits & INTEL_FRONTBUFFER_SPRITE(pipe)))
+	    (frontbuffer_bits & INTEL_FRONTBUFFER_SPRITE(pipe, 0)))
 		intel_psr_exit(dev);
 
 	/*
diff --git a/drivers/gpu/drm/i915/intel_sprite.c b/drivers/gpu/drm/i915/intel_sprite.c
index 16be667cc5eb..bc4fe599d836 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1130,7 +1130,7 @@ intel_plane_init(struct drm_device *dev, enum pipe pipe, int plane)
 
 	intel_plane->pipe = pipe;
 	intel_plane->plane = plane;
-	intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe);
+	intel_plane->frontbuffer_bit = INTEL_FRONTBUFFER_SPRITE(pipe, plane);
 	intel_plane->check_plane = intel_check_sprite_plane;
 	intel_plane->commit_plane = intel_commit_sprite_plane;
 	possible_crtcs = (1 << pipe);
-- 
2.1.4

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

Re: [PATCH 1/2] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Chris Wilson]

On Thu, Jun 25, 2015 at 11:47:22PM +0200, Daniel Vetter wrote:
> We can't elide the fb tracking invalidate if the buffer is already in
> the right domain since that would lead to missed screen updates. I'm
> pretty sure I've written this already before but must have gotten lost
> unfortunately :(
> 
> Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Note that I have a variant on this that observes that internally users
all honor the fb invalidation and so we can move this into the
set-domain ioctl.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Daniel Vetter]

We can't elide the fb tracking invalidate if the buffer is already in
the right domain since that would lead to missed screen updates. I'm
pretty sure I've written this already before but must have gotten lost
unfortunately :(

v2: Chris observed that all internal set_domain users already
correctly do the fb invalidate on their own, hence we can move this
just into the set_domain ioctl instead.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 9 +++------
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f79ce9f22312..80b696a8277c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1614,6 +1614,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 	else
 		ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
 
+	if (write_domain != 0)
+		intel_fb_obj_invalidate(obj, ORIGIN_CPU);
+
 unref:
 	drm_gem_object_unreference(&obj->base);
 unlock:
@@ -3982,9 +3985,6 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
 		obj->dirty = 1;
 	}
 
-	if (write)
-		intel_fb_obj_invalidate(obj, ORIGIN_GTT);
-
 	trace_i915_gem_object_change_domain(obj,
 					    old_read_domains,
 					    old_write_domain);
@@ -4256,9 +4256,6 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
 		obj->base.write_domain = I915_GEM_DOMAIN_CPU;
 	}
 
-	if (write)
-		intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-
 	trace_i915_gem_object_change_domain(obj,
 					    old_read_domains,
 					    old_write_domain);
-- 
2.1.4

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

Re: [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Chris Wilson]

On Fri, Jun 26, 2015 at 10:15:08AM +0200, Daniel Vetter wrote:
> We can't elide the fb tracking invalidate if the buffer is already in
> the right domain since that would lead to missed screen updates. I'm
> pretty sure I've written this already before but must have gotten lost
> unfortunately :(
> 
> v2: Chris observed that all internal set_domain users already
> correctly do the fb invalidate on their own, hence we can move this
> just into the set_domain ioctl instead.
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 9 +++------
>  1 file changed, 3 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index f79ce9f22312..80b696a8277c 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1614,6 +1614,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
>  	else
>  		ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
>  
> +	if (write_domain != 0)
> +		intel_fb_obj_invalidate(obj, ORIGIN_CPU);

Just the catch of doing
	write_domain == I915_GEM_DOMAIN_GTT ? ORIGIN_GTT : ORIGIN_CPU
to keep Paulo happy.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Daniel Vetter]

We can't elide the fb tracking invalidate if the buffer is already in
the right domain since that would lead to missed screen updates. I'm
pretty sure I've written this already before but must have gotten lost
unfortunately :(

v2: Chris observed that all internal set_domain users already
correctly do the fb invalidate on their own, hence we can move this
just into the set_domain ioctl instead.

v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris).

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 drivers/gpu/drm/i915/i915_gem.c | 11 +++++------
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f79ce9f22312..dbc93703e280 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1614,6 +1614,11 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data,
 	else
 		ret = i915_gem_object_set_to_cpu_domain(obj, write_domain != 0);
 
+	if (write_domain != 0)
+		intel_fb_obj_invalidate(obj,
+					write_domain == I915_GEM_DOMAIN_GTT ?
+					ORIGIN_GTT : ORIGIN_CPU);
+
 unref:
 	drm_gem_object_unreference(&obj->base);
 unlock:
@@ -3982,9 +3987,6 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
 		obj->dirty = 1;
 	}
 
-	if (write)
-		intel_fb_obj_invalidate(obj, ORIGIN_GTT);
-
 	trace_i915_gem_object_change_domain(obj,
 					    old_read_domains,
 					    old_write_domain);
@@ -4256,9 +4258,6 @@ i915_gem_object_set_to_cpu_domain(struct drm_i915_gem_object *obj, bool write)
 		obj->base.write_domain = I915_GEM_DOMAIN_CPU;
 	}
 
-	if (write)
-		intel_fb_obj_invalidate(obj, ORIGIN_CPU);
-
 	trace_i915_gem_object_change_domain(obj,
 					    old_read_domains,
 					    old_write_domain);
-- 
2.1.4

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

Re: [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Chris Wilson]

On Fri, Jun 26, 2015 at 07:35:16PM +0200, Daniel Vetter wrote:
> We can't elide the fb tracking invalidate if the buffer is already in
> the right domain since that would lead to missed screen updates. I'm
> pretty sure I've written this already before but must have gotten lost
> unfortunately :(
> 
> v2: Chris observed that all internal set_domain users already
> correctly do the fb invalidate on their own, hence we can move this
> just into the set_domain ioctl instead.
> 
> v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris).
> 
> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Paulo Zanoni]

2015-06-26 14:35 GMT-03:00 Chris Wilson <chris@chris-wilson.co.uk>:
> On Fri, Jun 26, 2015 at 07:35:16PM +0200, Daniel Vetter wrote:
>> We can't elide the fb tracking invalidate if the buffer is already in
>> the right domain since that would lead to missed screen updates. I'm
>> pretty sure I've written this already before but must have gotten lost
>> unfortunately :(
>>
>> v2: Chris observed that all internal set_domain users already
>> correctly do the fb invalidate on their own, hence we can move this
>> just into the set_domain ioctl instead.
>>
>> v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris).
>>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
>> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
>> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
>
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris

If you run:
sudo ./kms_frontbuffer_tracking --psr-only --1p-only --use-small-modes

Without the patch, you get 9 failures:
Subtest psr-1p-pri-sfb-multidraw-mmap-gtt: FAIL (10.979s)
Subtest psr-1p-pri-sfb-multidraw-mmap-wc: FAIL (10.982s)
Subtest psr-1p-pri-sfb-multidraw-pwrite: FAIL (9.448s)
Subtest psr-1p-cur-sfb-multidraw-mmap-gtt: FAIL (11.208s)
Subtest psr-1p-cur-sfb-multidraw-mmap-wc: FAIL (11.171s)
Subtest psr-1p-cur-sfb-multidraw-pwrite: FAIL (8.966s)
Subtest psr-1p-spr-sfb-multidraw-mmap-gtt: FAIL (11.536s)
Subtest psr-1p-spr-sfb-multidraw-mmap-wc: FAIL (11.439s)
Subtest psr-1p-spr-sfb-multidraw-pwrite: FAIL (10.043s)

With this patch, you get 0 failures \o/.

The "multidraw" subtest alternates between drawing types. So
multidraw-mmap-gtt will alternate between mmap-gtt and mmap-cpu, then
mmap-gtt and mmap-wc, then mmap-gtt and pwrite, then mmap-gtt and blt,
then mmap-gtt and render.

Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

>
> --
> Chris Wilson, Intel Open Source Technology Centre
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx



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

Re: [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[shuang.he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6556
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
ILK                                  303/303              303/303
SNB                                  312/316              312/316
IVB                                  343/343              343/343
BYT                                  286/286              286/286
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[shuang.he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6572
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
ILK                                  303/303              303/303
SNB                                  312/312              312/312
IVB                                  343/343              343/343
BYT                                  284/284              284/284
HSW                                  380/380              380/380
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/i915: Unconditionally do fb tracking invalidate in set_domain

[Daniel Vetter]

On Fri, Jun 26, 2015 at 05:02:49PM -0300, Paulo Zanoni wrote:
> 2015-06-26 14:35 GMT-03:00 Chris Wilson <chris@chris-wilson.co.uk>:
> > On Fri, Jun 26, 2015 at 07:35:16PM +0200, Daniel Vetter wrote:
> >> We can't elide the fb tracking invalidate if the buffer is already in
> >> the right domain since that would lead to missed screen updates. I'm
> >> pretty sure I've written this already before but must have gotten lost
> >> unfortunately :(
> >>
> >> v2: Chris observed that all internal set_domain users already
> >> correctly do the fb invalidate on their own, hence we can move this
> >> just into the set_domain ioctl instead.
> >>
> >> v3: I screwed up setting the invalidate ORIGIN_* correctly (Chris).
> >>
> >> Cc: Chris Wilson <chris@chris-wilson.co.uk>
> >> Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
> >> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> >
> > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> > -Chris
> 
> If you run:
> sudo ./kms_frontbuffer_tracking --psr-only --1p-only --use-small-modes
> 
> Without the patch, you get 9 failures:
> Subtest psr-1p-pri-sfb-multidraw-mmap-gtt: FAIL (10.979s)
> Subtest psr-1p-pri-sfb-multidraw-mmap-wc: FAIL (10.982s)
> Subtest psr-1p-pri-sfb-multidraw-pwrite: FAIL (9.448s)
> Subtest psr-1p-cur-sfb-multidraw-mmap-gtt: FAIL (11.208s)
> Subtest psr-1p-cur-sfb-multidraw-mmap-wc: FAIL (11.171s)
> Subtest psr-1p-cur-sfb-multidraw-pwrite: FAIL (8.966s)
> Subtest psr-1p-spr-sfb-multidraw-mmap-gtt: FAIL (11.536s)
> Subtest psr-1p-spr-sfb-multidraw-mmap-wc: FAIL (11.439s)
> Subtest psr-1p-spr-sfb-multidraw-pwrite: FAIL (10.043s)
> 
> With this patch, you get 0 failures \o/.
> 
> The "multidraw" subtest alternates between drawing types. So
> multidraw-mmap-gtt will alternate between mmap-gtt and mmap-cpu, then
> mmap-gtt and mmap-wc, then mmap-gtt and pwrite, then mmap-gtt and blt,
> then mmap-gtt and render.
> 
> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

Thanks for testing&review, patch applied to dinq.
-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

Re: [PATCH 2/2] drm/i915: Unique frontbuffer_bits for sprites

[shuang.he]

Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com)
Task id: 6646
-------------------------------------Summary-------------------------------------
Platform          Delta          drm-intel-nightly          Series Applied
ILK                                  302/302              302/302
SNB                                  312/316              312/316
IVB                                  343/343              343/343
BYT                 -2              287/287              285/287
HSW                                  380/380              380/380
-------------------------------------Detailed-------------------------------------
Platform  Test                                drm-intel-nightly          Series Applied
*BYT  igt@gem_partial_pwrite_pread@reads-display      PASS(1)      FAIL(1)
*BYT  igt@gem_partial_pwrite_pread@reads-uncached      PASS(1)      FAIL(1)
Note: You need to pay more attention to line start with '*'
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx