| Message ID | 1427320239-25667-2-git-send-email-przanoni@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, Mar 25, 2015 at 06:50:34PM -0300, Paulo Zanoni wrote: > 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> Hm maybe we should have 2 subtests: One with the bo_busy which only checks that the screen contents is right. And then after a longer delay checks that fbc gets reentered eventually. One with the gem_sync which also makes sure fbc gets reentered more timely. -Daniel > --- > 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
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)