From patchwork Mon Dec 8 16:12:42 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paulo Zanoni X-Patchwork-Id: 5457471 Return-Path: X-Original-To: patchwork-intel-gfx@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9FD01BEEA8 for ; Mon, 8 Dec 2014 16:13:36 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C2B292015A for ; Mon, 8 Dec 2014 16:13:35 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by mail.kernel.org (Postfix) with ESMTP id 7C1A820155 for ; Mon, 8 Dec 2014 16:13:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id DC1626E7C5; Mon, 8 Dec 2014 08:13:33 -0800 (PST) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by gabe.freedesktop.org (Postfix) with ESMTP id E82066E7C5 for ; Mon, 8 Dec 2014 08:13:32 -0800 (PST) Received: by mail-qg0-f46.google.com with SMTP id z107so3636398qgd.19 for ; Mon, 08 Dec 2014 08:13:32 -0800 (PST) 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=xJRwAm5ZCfyIAAngqLIlNnCGp8ImApfS4XH1rGiS0cM=; b=vDTahy+1u6MdXlgNmD6ADD2C4o3VuURq8dPIngY5W6oEvkZfCmQZI0Rc4aUScIYTZM WWqUJ14YRJrD/VL40XE9IEe+ekt7MyLOpEwyx4nlvbfNjLuXjEn/VSNyrmuoOe6l1xIA sUnbgA1oP5K0uAsGgi6MYxclwxC7FpwRiA5A15Zy+3/E81mya/76FxIqj9EwYlh4MMzY bqBqqEVjV4yY3p1fa0aclBHNluKltr9XF0t0NyYOTcULR1U005AItbFBnIKgcgG30LNK 6oU+gBCo8uDoTwXvVb6NZJSoTh8obe6IHyC8ZwxlSrRXKIBbEEOy3l0jq8ZWTy3x7Ss2 vEeQ== X-Received: by 10.224.65.134 with SMTP id j6mr54456326qai.90.1418055212474; Mon, 08 Dec 2014 08:13:32 -0800 (PST) Received: from localhost.localdomain ([187.95.104.42]) by mx.google.com with ESMTPSA id l10sm30480245qas.25.2014.12.08.08.13.30 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 08 Dec 2014 08:13:32 -0800 (PST) From: Paulo Zanoni To: intel-gfx@lists.freedesktop.org Date: Mon, 8 Dec 2014 14:12:42 -0200 Message-Id: <1418055164-1536-2-git-send-email-przanoni@gmail.com> X-Mailer: git-send-email 2.1.3 In-Reply-To: <1418055164-1536-1-git-send-email-przanoni@gmail.com> References: <1418054960-1403-1-git-send-email-przanoni@gmail.com> <1418055164-1536-1-git-send-email-przanoni@gmail.com> MIME-Version: 1.0 Cc: Paulo Zanoni Subject: [Intel-gfx] [PATCH igt 2/4] 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. Cc: Ville Syrjälä 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 32c3d98..7c3a412 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)