diff mbox

[2/7] tests/kms_fb_crc: call gem_sync() instead of gem_bo_busy()

Message ID 1427320239-25667-2-git-send-email-przanoni@gmail.com (mailing list archive)
State New, archived
Headers show

Commit Message

Paulo Zanoni March 25, 2015, 9:50 p.m. UTC
From: Paulo Zanoni <paulo.r.zanoni@intel.com>

The way kms_fbc_crc works is that it does an operation that may
trigger/invalidate/update FBC, then it sleeps for 300ms to wait for
FBC to kick in again, then it calls "igt_assert(fbc_enabled())".

This was causing problems where the BLT test would eventually fail in
the fbc_eanbled() assertion.

With the recent FBC move to front buffer rendering tracking, if we
don't call gem_sync() after submitting render and blt commands, it may
take much more than 300ms for FBC to be reenabled:
i915_gem_execbuffer2() indirectly calls intel_fb_obj_invalidate(),
which disables FBC, and then it is only reenabled when
i915_gem_retire_work_handler() happens and indirectly calls
intel_frontbuffer_flush(). Notice that while FBC is not yet enabled,
the screen contents are correct, so this shouldn't really be a "bug".

The gem_sync() call will make sure the long waits don't happen. With
this, 300ms should be much more than enough: either we wait about 50ms
for FBC to be re-enabled - intel_enable_fbc() uses a delayed work - or
it's instantaneous - on the cases where we just do the nuke.

Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
---
 tests/kms_fbc_crc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Daniel Vetter March 26, 2015, 10:06 a.m. UTC | #1
On Wed, Mar 25, 2015 at 06:50:34PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni@intel.com>
> 
> The way kms_fbc_crc works is that it does an operation that may
> trigger/invalidate/update FBC, then it sleeps for 300ms to wait for
> FBC to kick in again, then it calls "igt_assert(fbc_enabled())".
> 
> This was causing problems where the BLT test would eventually fail in
> the fbc_eanbled() assertion.
> 
> With the recent FBC move to front buffer rendering tracking, if we
> don't call gem_sync() after submitting render and blt commands, it may
> take much more than 300ms for FBC to be reenabled:
> i915_gem_execbuffer2() indirectly calls intel_fb_obj_invalidate(),
> which disables FBC, and then it is only reenabled when
> i915_gem_retire_work_handler() happens and indirectly calls
> intel_frontbuffer_flush(). Notice that while FBC is not yet enabled,
> the screen contents are correct, so this shouldn't really be a "bug".
> 
> The gem_sync() call will make sure the long waits don't happen. With
> this, 300ms should be much more than enough: either we wait about 50ms
> for FBC to be re-enabled - intel_enable_fbc() uses a delayed work - or
> it's instantaneous - on the cases where we just do the nuke.
> 
> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>

Hm maybe we should have 2 subtests: One with the bo_busy which only checks
that the screen contents is right. And then after a longer delay checks
that fbc gets reentered eventually. One with the gem_sync which also makes
sure fbc gets reentered more timely.
-Daniel

> ---
>  tests/kms_fbc_crc.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
> index 4256fed..b3e6109 100644
> --- a/tests/kms_fbc_crc.c
> +++ b/tests/kms_fbc_crc.c
> @@ -122,7 +122,7 @@ static void fill_blt(data_t *data,
>  	intel_batchbuffer_flush(batch);
>  	intel_batchbuffer_free(batch);
>  
> -	gem_bo_busy(data->drm_fd, handle);
> +	gem_sync(data->drm_fd, handle);
>  }
>  
>  static void scratch_buf_init(struct igt_buf *buf, drm_intel_bo *bo)
> @@ -187,7 +187,7 @@ static void fill_render(data_t *data, uint32_t handle,
>  
>  	intel_batchbuffer_free(batch);
>  
> -	gem_bo_busy(data->drm_fd, handle);
> +	gem_sync(data->drm_fd, handle);
>  }
>  
>  static bool fbc_enabled(data_t *data)
> -- 
> 2.1.4
> 
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
diff mbox

Patch

diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c
index 4256fed..b3e6109 100644
--- a/tests/kms_fbc_crc.c
+++ b/tests/kms_fbc_crc.c
@@ -122,7 +122,7 @@  static void fill_blt(data_t *data,
 	intel_batchbuffer_flush(batch);
 	intel_batchbuffer_free(batch);
 
-	gem_bo_busy(data->drm_fd, handle);
+	gem_sync(data->drm_fd, handle);
 }
 
 static void scratch_buf_init(struct igt_buf *buf, drm_intel_bo *bo)
@@ -187,7 +187,7 @@  static void fill_render(data_t *data, uint32_t handle,
 
 	intel_batchbuffer_free(batch);
 
-	gem_bo_busy(data->drm_fd, handle);
+	gem_sync(data->drm_fd, handle);
 }
 
 static bool fbc_enabled(data_t *data)