From: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> When we're doing the context subtest, at the end of prepare_test() we exec a single nop batch on the front buffer, which invalidates FBC. With the new frontbuffer tracking scheme it may take a while for FBC to be reenabled, so we end up failing the first fbc_enabled() assertion inside test_crc(). Other possible implementations: - Call gem_sync() at the specific prepare_test() point, not at every exec_nop() call. - Change the fbc_enabled() assertion to wait_for_fbc_enabled() and give it a bigger timeout value. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@xxxxxxxxx> --- tests/kms_fbc_crc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c index 11078e0..d81f4a2 100644 --- a/tests/kms_fbc_crc.c +++ b/tests/kms_fbc_crc.c @@ -155,6 +155,8 @@ static void exec_nop(data_t *data, uint32_t handle, drm_intel_context *context) intel_batchbuffer_flush_with_context(batch, context); intel_batchbuffer_free(batch); + + gem_sync(data->drm_fd, handle); } static void fill_render(data_t *data, uint32_t handle, -- 2.1.4 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
