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

[Daniel Vetter <daniel@ffwll.ch>]

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

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