From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> 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@xxxxxxxxx> --- 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@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
