From patchwork Wed Mar 25 21:50:34 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paulo Zanoni X-Patchwork-Id: 6095291 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 64D089F399 for ; Wed, 25 Mar 2015 21:51:46 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 7B67C2035B for ; Wed, 25 Mar 2015 21:51:45 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 96929202F2 for ; Wed, 25 Mar 2015 21:51:44 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 2257B6E0B7; Wed, 25 Mar 2015 14:51:44 -0700 (PDT) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) by gabe.freedesktop.org (Postfix) with ESMTP id 46BBB6E0B7 for ; Wed, 25 Mar 2015 14:51:43 -0700 (PDT) Received: by qgh3 with SMTP id 3so54014320qgh.2 for ; Wed, 25 Mar 2015 14:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=A0EsGsv7awFmSoLOAHY1FrldYMxqO1E6cMlAUS6/Nok=; b=OM0Ln3/KH0lCZmhQpEQOabEnVY5mOpJSZPuX0jcEw/wW6DSe5qXGmNxVA5QmTNwycc bJtOrn2PqNbKXD0bWksI1/faR1mnKrUKKZ1+Z4x+cK+0XZLb4iLnNy0rR8JaIkEUbcpB TFbqrvQ2qZ5I1TBPID7yvZ+WU0JSiP8cbM7xz862N6Tdljkwmy+wfIVQglZ+9CMpv+i3 3LnuTvJbVTmn4I+Z0lsLb19ntei9J3gxxV2TXosD0VvFxBy2ELZLnDnHX+WNQchYyIWS JMOsDe4z0x+Yv0XXLb979BRhhsDnRB9KC5yYL8Lzw/pnvkmyIVJ3S6+gXIbpftEdxQQG NKfw== X-Received: by 10.55.54.19 with SMTP id d19mr22784199qka.98.1427320302850; Wed, 25 Mar 2015 14:51:42 -0700 (PDT) Received: from localhost.localdomain ([187.121.139.226]) by mx.google.com with ESMTPSA id b52sm2308334qgb.16.2015.03.25.14.51.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 25 Mar 2015 14:51:42 -0700 (PDT) From: Paulo Zanoni To: intel-gfx@lists.freedesktop.org Date: Wed, 25 Mar 2015 18:50:34 -0300 Message-Id: <1427320239-25667-2-git-send-email-przanoni@gmail.com> X-Mailer: git-send-email 2.1.4 In-Reply-To: <1427320239-25667-1-git-send-email-przanoni@gmail.com> References: <1427320239-25667-1-git-send-email-przanoni@gmail.com> MIME-Version: 1.0 Cc: Paulo Zanoni Subject: [Intel-gfx] [PATCH 2/7] tests/kms_fb_crc: call gem_sync() instead of gem_bo_busy() X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_MED, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Paulo Zanoni 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 --- 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)