All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paulo Zanoni <przanoni@gmail.com>
To: intel-gfx@lists.freedesktop.org
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Subject: [PATCH 2/7] tests/kms_fb_crc: call gem_sync() instead of gem_bo_busy()
Date: Wed, 25 Mar 2015 18:50:34 -0300	[thread overview]
Message-ID: <1427320239-25667-2-git-send-email-przanoni@gmail.com> (raw)
In-Reply-To: <1427320239-25667-1-git-send-email-przanoni@gmail.com>

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

  reply	other threads:[~2015-03-25 21:51 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-25 21:50 [PATCH 1/7] lib: add igt_wait() Paulo Zanoni
2015-03-25 21:50 ` Paulo Zanoni [this message]
2015-03-26 10:06   ` [PATCH 2/7] tests/kms_fb_crc: call gem_sync() instead of gem_bo_busy() Daniel Vetter
2015-03-25 21:50 ` [PATCH 3/7] tests/kms_fbc_crc: add wait_for_fbc_enabled() Paulo Zanoni
2015-03-26 10:07   ` Daniel Vetter
2015-03-25 21:50 ` [PATCH 4/7] tests/kms_fbc_crc: also gem_sync() on exec_nop() Paulo Zanoni
2015-03-25 21:50 ` [PATCH 5/7] tests/kms_fbc_crc: use igt_pipe_crc_collect_crc() Paulo Zanoni
2015-03-25 21:50 ` [PATCH 6/7] tests/kms_fbc_crc: remove redundant information from data_t Paulo Zanoni
2015-03-25 21:50 ` [PATCH 7/7] lib: add igt_draw Paulo Zanoni
2015-03-26 10:19   ` Daniel Vetter
2015-03-30 19:45     ` Paulo Zanoni
2015-03-31 13:07       ` Daniel Vetter
2015-03-31 14:03         ` Paulo Zanoni
2015-03-31 21:52           ` Paulo Zanoni
2015-03-31 22:05             ` Chris Wilson
2015-04-01 22:08               ` Paulo Zanoni
2015-04-01 22:22                 ` Chris Wilson
2015-04-01 22:33                   ` Paulo Zanoni
2015-04-01 22:40                     ` Paulo Zanoni
2015-04-01 23:15                       ` Chris Wilson
2015-04-01 23:17                         ` Chris Wilson
2015-04-07  8:10                         ` Daniel Vetter
2015-04-07  8:36                           ` Chris Wilson
2015-04-07  9:07                             ` Daniel Vetter
2015-04-07 10:12                               ` Chris Wilson
2015-04-07 13:44                                 ` Daniel Vetter
2015-05-05 21:30                                   ` Paulo Zanoni
2015-05-06  9:00                                     ` Daniel Vetter
2015-04-01 23:03                     ` Chris Wilson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1427320239-25667-2-git-send-email-przanoni@gmail.com \
    --to=przanoni@gmail.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=paulo.r.zanoni@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.