From: Paulo Zanoni <paulo.r.zan...@intel.com>
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.
Cc: Ville Syrjälä <ville.syrj...@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zan...@intel.com>
---
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 354a2b7..decb83e 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.3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
