From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH v4 0/6] Finally fix watermarks Date: Mon, 1 Aug 2016 14:48:01 +0300 Message-ID: <20160801114801.GM4329@intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: Content-Disposition: inline In-Reply-To: <22e017c0-d886-22b5-b382-d68d79f7774f@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Maarten Lankhorst Cc: David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter List-Id: dri-devel@lists.freedesktop.org T24gTW9uLCBBdWcgMDEsIDIwMTYgYXQgMTA6NDg6MzdBTSArMDIwMCwgTWFhcnRlbiBMYW5raG9y c3Qgd3JvdGU6Cj4gT3AgMjktMDctMTYgb20gMjI6MzMgc2NocmVlZiBNYXR0IFJvcGVyOgo+ID4g T24gRnJpLCBKdWwgMjksIDIwMTYgYXQgMTI6Mzk6MDVQTSArMDMwMCwgVmlsbGUgU3lyasOkbMOk IHdyb3RlOgo+ID4+IE9uIFRodSwgSnVsIDI4LCAyMDE2IGF0IDA1OjAzOjUyUE0gLTA3MDAsIE1h dHQgUm9wZXIgd3JvdGU6Cj4gPj4+IFRoaXMgaXMgY29tcGxldGVseSB1bnRlc3RlZCAoYW5kIHBy b2JhYmx5IGhvcnJpYmx5IGJyb2tlbi9idWdneSksIGJ1dAo+ID4+PiBoZXJlJ3MgYSBxdWljayBt b2NrdXAgb2YgdGhlIGdlbmVyYWwgYXBwcm9hY2ggSSB3YXMgdGhpbmtpbmcgZm9yCj4gPj4+IGVu c3VyaW5nIEREQiAmIFdNJ3MgY2FuIGJlIHVwZGF0ZWQgdG9nZXRoZXIgd2hpbGUgZW5zdXJpbmcg dGhlCj4gPj4+IHRocmVlLXN0ZXAgcGlwZSBmbHVzaGluZyBwcm9jZXNzIGlzIGhvbm9yZWQ6Cj4g Pj4+Cj4gPj4+ICAgICAgICAgaHR0cHM6Ly9naXRodWIuY29tL21hdHRyb3BlL2tlcm5lbC9jb21t aXRzL2V4cGVyaW1lbnRhbC9seXVkZV9kZGIKPiA+Pj4KPiA+Pj4gQmFzaWNhbGx5IHRoZSBpZGVh IGlzIHRvIHRha2Ugbm90ZSBvZiB3aGF0J3MgaGFwcGVuaW5nIHRvIHRoZSBwaXBlJ3MgRERCCj4g Pj4+IGFsbG9jYXRpb24gKHNocmlua2luZywgZ3Jvd2luZywgdW5jaGFuZ2VkLCBldGMuKSBkdXJp bmcgdGhlIGF0b21pYyBjaGVjawo+ID4+PiBwaGFzZTsKPiA+PiBEaWRuJ3QgbG9vayB0b28gY2xv c2VseSwgYnV0IEkgdGhpbmsgeW91IGNhbid0IGFjdHVhbGx5IGRvIHRoYXQgdW5sZXNzCj4gPj4g eW91IGxvY2sgYWxsIHRoZSBjcnRjcyB3aGVuZXZlciB0aGUgbnVtYmVyIG9mIGFjdGl2ZSBwaXBl cyBpcyBnb2luZCB0bwo+ID4+IGNoYW5nZS4gTWVhbmluZyB3ZSdkIGVzc2VudGlhbGx5IGJlIGJh Y2sgdG8gdGhlIG9uZS1iaWctbW9kZXNldC1sb2NrCj4gPj4gYXBwb3JhY2gsIHdoaWNoIHdpbGwg Y2F1c2UgbWlzc2VkIGZsaXBzIGFuZCB3aGFub3Qgb24gdGhlIG90aGVyIHBpcGVzLgo+ID4+Cj4g Pj4gVGhlIGFsdGVybmF0aXZlIEkgdGhpbmsgd291bGQgY29uc2lzdCBvZjoKPiA+PiAtIG1ha2Ug c3VyZSBsZXZlbCAwIHdhdGVybWFyayBuZXZlciBleGNlZWRzIHRvdGFsX2RkYl9zaXplL21heF9w aXBlcywKPiA+PiAgIHNvIHRoYXQgYSBtb2Rlc2V0IGRvZXNuJ3QgaGF2ZSB0byBjYXJlIGFib3V0 IHRoZSB3bXMgZm9yIHRoZSBvdGhlcgo+ID4+ICAgcGlwZXMgbm90IGZpdHRpbmcgaW4KPiA+IFVu Zm9ydHVuYXRlbHkgdGhpcyBwYXJ0IGlzIHRoZSBwcm9ibGVtLiAgWW91IG1pZ2h0IGdldCBhd2F5 IHdpdGggZG9pbmcKPiA+IHRoaXMgb24gU0tML0tCTCB3aGljaCBvbmx5IGhhdmUgdGhyZWUgcGxh bmVzIG1heCBwZXIgcGlwZSBhbmQgYSBsYXJnZQo+ID4gKDg5NiBibG9jaykgRERCLCBidXQgb24g QlhUIHlvdSBoYXZlIHVwIHRvIGZvdXIgcGxhbmVzICh3ZSBkb24ndAo+ID4gYWN0dWFsbHkgZW5h YmxlIHRoZSB0b3Btb3N0IHBsYW5lIGluIGEgZnVsbC1mZWF0dXJlZCBtYW5uZXIganVzdCB5ZXQs Cj4gPiBidXQgbmVlZCB0byBzb29uKSwgeWV0IHRoZSB0b3RhbCBEREIgaXMgb25seSA1MTIgYmxv Y2tzLiAgU2FkbHksIHRoZQo+ID4gcGxhdGZvcm0gd2l0aCBtb3JlIHBsYW5lcyB3YXMgZ2l2ZW4g YSBzbWFsbGVyIEREQi4uLiAgIDotKAo+ID4gV2UncmUgYWxyZWFkeSBpbiB0cm91YmxlIGJlY2F1 c2UgdXNlcnMgdGhhdCBhcmUgcnVubmluZyBzZXR1cHMgbGlrZSAzeAo+ID4gNEsgd2l0aCBtb3N0 L2FsbCBwbGFuZXMgaW4gdXNlIGF0IGxhcmdlIHNpemVzIGNhbid0IGZpbmQgbGV2ZWwgMAo+ID4g d2F0ZXJtYXJrcyB0aGF0IHNhdGlzZnkgdGhlaXIgbmVlZHMgYW5kIHdlIGhhdmUgdG8gcmVqZWN0 IHRoZSB3aG9sZQo+ID4gY29uZmlndXJhdGlvbi4gIElmIHdlIGZ1cnRoZXIgbGltaXQgZWFjaCBw aXBlJ3MgdXNhZ2UgdG8gdG90YWwvbWF4cGlwZXMKPiA+IChpLmUuLCAxNzAgYmxvY2tzIHBlciBw aXBlIG9uIEJYVCksIHRoZW4gd2UncmUgZ29pbmcgdG8gaGl0IHNpbWlsYXIKPiA+IGlzc3VlcyB3 aGVuIG9ubHkgZHJpdmluZyBvbmUgb3IgdHdvIGRpc3BsYXlzIHdpdGggd2l0aCBhbGwgb2YgdGhl IHBsYW5lcwo+ID4gaW4gdXNlLCBldmVuIHRob3VnaCB3ZSBzaG91bGQgaGF2ZSBoYWQgbW9yZSBE REIgc3BhY2UgdG8gd29yayB3aXRoLgo+ID4KPiA+IEkgZ3Vlc3Mgc2VyaW91cyBwbGFuZSB1c2Fn ZSBpc24ndCB0b28gY29tbW9uIGluIGRlc2t0b3Agc2V0dXBzIHRvZGF5LAo+ID4gYnV0IGl0J3Mg YSB2ZXJ5IGNyaXRpY2FsIGZlYXR1cmUgaW4gdGhlIGVtYmVkZGVkIHdvcmxkOyB3ZSBjYW4ndCBy ZWFsbHkKPiA+IGFmZm9yZCB0byBjcmlwcGxlIHBsYW5lIHVzYWdlIGZ1cnRoZXIuICBVbmZvcnR1 bmF0ZWx5LCBhcyB5b3UgcG9pbnQgb3V0Cj4gPiBhYm92ZSwgdGhpcyBtZWFucyB0aGF0IHdlIGhh dmUgdG8gZm9sbG93IHRoZSBic3BlYydzIEREQiBhbGxvY2F0aW9uCj4gPiBtZXRob2QsIHdoaWNo IGluIHR1cm4gbWVhbnMgd2UgbmVlZCB0byBncmFiIF9hbGxfIENSVEMgbG9ja3MgYW55IHRpbWUK PiA+IF9hbnlfIENSVEMgaXMgYmVpbmcgdHVybmVkIG9uIG9yIHR1cm5lZCBvZmYgd2hpY2ggaXMg YSBCS0wtc3R5bGUgd2F5IG9mCj4gPiBkb2luZyB0aGluZ3MuCj4gTWVoLCBJJ20gcnVubmluZyBp bnRvIGEgc2ltaWxhciBpc3N1ZSBvbiB2bHYvY2h2LiBJIGRvbid0IHNlZSBhIHdheSBhcm91bmQg aXQuIDooCgpOb3cgYXJlIHlvdSBoaXR0aW5nIGl0IHcvIHZsdi9jaHY/IFRoZXkgZG9uJ3QgZXZl biBoYXZlIGEgc2hhcmVkIEREQi4KCj4gT25seSB0aGluZyB3ZSBjb3VsZCBkbyBpcyBzcGxpdCB1 cCB0aGUgc3RhdGUgdG8gbWFrZSB0aGUgbm9uLW1vZGVzZXQKPiBjcnRjJ3MgY29tcGxldGUgZWFy bHkuCgotLSAKVmlsbGUgU3lyasOkbMOkCkludGVsIE9UQwpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXwpJbnRlbC1nZnggbWFpbGluZyBsaXN0CkludGVsLWdm eEBsaXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFp bG1hbi9saXN0aW5mby9pbnRlbC1nZngK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753448AbcHALtG (ORCPT ); Mon, 1 Aug 2016 07:49:06 -0400 Received: from mga14.intel.com ([192.55.52.115]:40883 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753330AbcHALst (ORCPT ); Mon, 1 Aug 2016 07:48:49 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,454,1464678000"; d="scan'208";a="742558763" Date: Mon, 1 Aug 2016 14:48:01 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Maarten Lankhorst Cc: Matt Roper , Lyude , intel-gfx@lists.freedesktop.org, David Airlie , linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter Subject: Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Message-ID: <20160801114801.GM4329@intel.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <22e017c0-d886-22b5-b382-d68d79f7774f@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > Only thing we could do is split up the state to make the non-modeset > crtc's complete early. -- Ville Syrjälä Intel OTC