From patchwork Thu Jul 2 15:37:23 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?VmlsbGUgU3lyasOkbMOk?= X-Patchwork-Id: 11639353 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1F24F13B6 for ; Thu, 2 Jul 2020 15:37:39 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 07CEE208C7 for ; Thu, 2 Jul 2020 15:37:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 07CEE208C7 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 902AF6EB0F; Thu, 2 Jul 2020 15:37:38 +0000 (UTC) X-Original-To: intel-gfx@lists.freedesktop.org Delivered-To: intel-gfx@lists.freedesktop.org Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by gabe.freedesktop.org (Postfix) with ESMTPS id F08446EB0D for ; Thu, 2 Jul 2020 15:37:37 +0000 (UTC) IronPort-SDR: W5Bp8ZJfxhgZk9Zalrpy4BwXD9CNo+kNS2Egb6/0GTEzueFHSqaTr3LYwErpmFnKYqzxdfrEFA TTCZLrp/il6A== X-IronPort-AV: E=McAfee;i="6000,8403,9670"; a="144442627" X-IronPort-AV: E=Sophos;i="5.75,304,1589266800"; d="scan'208";a="144442627" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Jul 2020 08:37:37 -0700 IronPort-SDR: Ll7eJxxhOmEsaVigHGwWTCpk/h46H/YKXHUvDwndezJp1Mcxja1MoricqwvvM1V5w6+xVbdQmH eVGXLxQrxgoA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.75,304,1589266800"; d="scan'208";a="313056669" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga008.jf.intel.com with SMTP; 02 Jul 2020 08:37:35 -0700 Received: by stinkbox (sSMTP sendmail emulation); Thu, 02 Jul 2020 18:37:34 +0300 From: Ville Syrjala To: intel-gfx@lists.freedesktop.org Date: Thu, 2 Jul 2020 18:37:23 +0300 Message-Id: <20200702153723.24327-5-ville.syrjala@linux.intel.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200702153723.24327-1-ville.syrjala@linux.intel.com> References: <20200702153723.24327-1-ville.syrjala@linux.intel.com> MIME-Version: 1.0 Subject: [Intel-gfx] [PATCH 4/4] drm/i915/fbc: Allow FBC to recompress after a 3D workload on i85x/i865 X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 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" From: Ville Syrjälä Normally i85x/i865 3D activity will block FBC until a 2D blit occurs. I suppose this was meant to avoid recompression while 3D activity is still going on but the frame hasn't yet been presented. Unfortunately that also means that a page flipped 3D workload will permanently block FBC even if it only renders a single frame and then does nothing. Since we are using software render tracking anyway we might as well flip the chicken bit so that 3D does not block FBC. This will avoid the permament FBC blockage in the aforemention use case, but thanks to the software tracking the compressor will not disturb 3D rendering activity. Signed-off-by: Ville Syrjälä Reviewed-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 10 ++++++++++ 2 files changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9d6536afc94b..03590d2d75f7 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2827,6 +2827,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define VLV_GU_CTL0 _MMIO(VLV_DISPLAY_BASE + 0x2030) #define VLV_GU_CTL1 _MMIO(VLV_DISPLAY_BASE + 0x2034) #define SCPD0 _MMIO(0x209c) /* 915+ only */ +#define SCPD_FBC_IGNORE_3D (1 << 6) #define CSTATE_RENDER_CLOCK_GATE_DISABLE (1 << 5) #define GEN2_IER _MMIO(0x20a0) #define GEN2_IIR _MMIO(0x20a4) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 565a2b9da3b3..2d980b83a1f1 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7471,6 +7471,16 @@ static void i85x_init_clock_gating(struct drm_i915_private *dev_priv) I915_WRITE(MEM_MODE, _MASKED_BIT_ENABLE(MEM_DISPLAY_TRICKLE_FEED_DISABLE)); + + /* + * Have FBC ignore 3D activity since we use software + * render tracking, and otherwise a pure 3D workload + * (even if it just renders a single frame and then does + * abosultely nothing) would not allow FBC to recompress + * until a 2D blit occurs. + */ + I915_WRITE(SCPD0, + _MASKED_BIT_ENABLE(SCPD_FBC_IGNORE_3D)); } static void i830_init_clock_gating(struct drm_i915_private *dev_priv)