From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S967723AbcHBPtk (ORCPT ); Tue, 2 Aug 2016 11:49:40 -0400 Received: from mga03.intel.com ([134.134.136.65]:39590 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967748AbcHBPsN (ORCPT ); Tue, 2 Aug 2016 11:48:13 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,461,1464678000"; d="scan'208";a="1028398534" Subject: Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= References: <1469554483-24999-1-git-send-email-cpaul@redhat.com> <20160729000352.GR32025@intel.com> <20160729093905.GU4329@intel.com> <20160729203324.GT32025@intel.com> <22e017c0-d886-22b5-b382-d68d79f7774f@linux.intel.com> <20160801114801.GM4329@intel.com> Cc: Matt Roper , Lyude , intel-gfx@lists.freedesktop.org, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter From: Maarten Lankhorst Message-ID: <6cbd3f43-c337-a9e6-0f6b-cd509a45ae24@linux.intel.com> Date: Tue, 2 Aug 2016 17:41:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160801114801.GM4329@intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 01-08-16 om 13:48 schreef Ville Syrjälä: > On Mon, Aug 01, 2016 at 10:48:37AM +0200, Maarten Lankhorst wrote: >> Op 29-07-16 om 22:33 schreef Matt Roper: >>> On Fri, Jul 29, 2016 at 12:39:05PM +0300, Ville Syrjälä wrote: >>>> On Thu, Jul 28, 2016 at 05:03:52PM -0700, Matt Roper wrote: >>>>> This is completely untested (and probably horribly broken/buggy), but >>>>> here's a quick mockup of the general approach I was thinking for >>>>> ensuring DDB & WM's can be updated together while ensuring the >>>>> three-step pipe flushing process is honored: >>>>> >>>>> https://github.com/mattrope/kernel/commits/experimental/lyude_ddb >>>>> >>>>> Basically the idea is to take note of what's happening to the pipe's DDB >>>>> allocation (shrinking, growing, unchanged, etc.) during the atomic check >>>>> phase; >>>> Didn't look too closely, but I think you can't actually do that unless >>>> you lock all the crtcs whenever the number of active pipes is goind to >>>> change. Meaning we'd essentially be back to the one-big-modeset-lock >>>> apporach, which will cause missed flips and whanot on the other pipes. >>>> >>>> The alternative I think would consist of: >>>> - make sure level 0 watermark never exceeds total_ddb_size/max_pipes, >>>> so that a modeset doesn't have to care about the wms for the other >>>> pipes not fitting in >>> Unfortunately this part is the problem. You might get away with doing >>> this on SKL/KBL which only have three planes max per pipe and a large >>> (896 block) DDB, but on BXT you have up to four planes (we don't >>> actually enable the topmost plane in a full-featured manner just yet, >>> but need to soon), yet the total DDB is only 512 blocks. Sadly, the >>> platform with more planes was given a smaller DDB... :-( >>> We're already in trouble because users that are running setups like 3x >>> 4K with most/all planes in use at large sizes can't find level 0 >>> watermarks that satisfy their needs and we have to reject the whole >>> configuration. If we further limit each pipe's usage to total/maxpipes >>> (i.e., 170 blocks per pipe on BXT), then we're going to hit similar >>> issues when only driving one or two displays with with all of the planes >>> in use, even though we should have had more DDB space to work with. >>> >>> I guess serious plane usage isn't too common in desktop setups today, >>> but it's a very critical feature in the embedded world; we can't really >>> afford to cripple plane usage further. Unfortunately, as you point out >>> above, this means that we have to follow the bspec's DDB allocation >>> method, which in turn means we need to grab _all_ CRTC locks any time >>> _any_ CRTC is being turned on or turned off which is a BKL-style way of >>> doing things. >> Meh, I'm running into a similar issue on vlv/chv. I don't see a way around it. :( > Now are you hitting it w/ vlv/chv? They don't even have a shared DDB. Not really the same, but determining what power saving levels + values to set with possibly parallel updates. ~Maarten