diff options
| author | Paulo Zanoni <paulo.r.zanoni@intel.com> | 2014-12-05 18:46:06 -0200 |
|---|---|---|
| committer | Paulo Zanoni <paulo.r.zanoni@intel.com> | 2014-12-08 11:30:23 -0200 |
| commit | 0615e6eabca9dc74649f0af797730c978abcc73e (patch) | |
| tree | 8e4849e21a0d0927ae1b2da7c87028fdb5744543 | |
| parent | eac4c339e96994f27080ed720061b3957f331716 (diff) | |
tests/kms_fbc_crc: also gem_sync() on exec_nop()
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.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
| -rw-r--r-- | tests/kms_fbc_crc.c | 2 |
1 files changed, 2 insertions, 0 deletions
diff --git a/tests/kms_fbc_crc.c b/tests/kms_fbc_crc.c index 354a2b71..decb83ed 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, |