From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH] drm/i915: update FBC maximum fb sizes Date: Tue, 4 Jun 2013 20:57:52 +0300 Message-ID: <20130604175752.GF5004@intel.com> References: <1370294136-2977-1-git-send-email-przanoni@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTP id C4D36E5D39 for ; Tue, 4 Jun 2013 10:58:07 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Paulo Zanoni Cc: intel-gfx , Paulo Zanoni List-Id: intel-gfx@lists.freedesktop.org On Tue, Jun 04, 2013 at 02:46:14PM -0300, Paulo Zanoni wrote: > 2013/6/4 Daniel Vetter : > > On Mon, Jun 3, 2013 at 11:15 PM, Paulo Zanoni wrot= e: > >> From: Paulo Zanoni > >> > >> CTG/ILK/SNB/IVB support 4kx2k surfaces. HSW supports 4kx4k, but > >> without proper front buffer invalidation on the last 2k lines, so > >> don't enable FBC on these cases for now. > >> > >> Signed-off-by: Paulo Zanoni > >> --- > >> drivers/gpu/drm/i915/intel_pm.c | 15 ++++++++++++--- > >> 1 file changed, 12 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/in= tel_pm.c > >> index 49a1887..cf123c1 100644 > >> --- a/drivers/gpu/drm/i915/intel_pm.c > >> +++ b/drivers/gpu/drm/i915/intel_pm.c > >> @@ -431,7 +431,7 @@ void intel_disable_fbc(struct drm_device *dev) > >> * - no pixel mulitply/line duplication > >> * - no alpha buffer discard > >> * - no dual wide > >> - * - framebuffer <=3D 2048 in width, 1536 in height > >> + * - framebuffer <=3D max_hdisplay in width, max_vdisplay in height > >> * > >> * We can't assume that any compression will take place (worst case), > >> * so the compressed buffer has to be the same size as the uncompress= ed > >> @@ -449,6 +449,7 @@ void intel_update_fbc(struct drm_device *dev) > >> struct intel_framebuffer *intel_fb; > >> struct drm_i915_gem_object *obj; > >> int enable_fbc; > >> + unsigned int max_hdisplay, max_vdisplay; > >> > >> if (!i915_powersave) > >> return; > >> @@ -507,8 +508,16 @@ void intel_update_fbc(struct drm_device *dev) > >> dev_priv->no_fbc_reason =3D FBC_UNSUPPORTED_MODE; > >> goto out_disable; > >> } > >> - if ((crtc->mode.hdisplay > 2048) || > >> - (crtc->mode.vdisplay > 1536)) { > >> + > >> + if (IS_G4X(dev) || INTEL_INFO(dev)->gen > 4) { > > > > Bikeshed-time: I prefer gen checks to be of the form gen >=3D x or gen < > > y because: > > - It looks more like C code should look like. > > - We we talk about platform ranges we tend to use e.g. ilk+ and > > pre-gen6, so would fit more naturally with the written word. > > > > Patch looks good otherwise, but for a bit I was thinking "wait, g4x is > > gen4, what's going on here?" ... > = > Yeah, you're right. I was trying to find out "how do I check for > Cantiga+?" and basically copied the line I found inside > intel_crtc_compute_config. We could really have a map between these > older codenames and our checks somewhere. We should maybe also have some feature macro for ctg+ display. Much of the north display changed already for ctg rather than ilk. -- = Ville Syrj=E4l=E4 Intel OTC