[Intel-gfx] [PATCH 2/7] tests/kms_fb_crc: call gem_sync() instead of gem_bo_busy()
Daniel Vetter
daniel at ffwll.ch
Thu Mar 26 03:06:47 PDT 2015
On Wed, Mar 25, 2015 at 06:50:34PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni <paulo.r.zanoni at 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 at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list