From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [Intel-gfx] [PATCH v4 0/6] Finally fix watermarks Date: Tue, 2 Aug 2016 18:59:33 +0300 Message-ID: <20160802155933.GA4329@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> <20160801114801.GM4329@intel.com> <6cbd3f43-c337-a9e6-0f6b-cd509a45ae24@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: <6cbd3f43-c337-a9e6-0f6b-cd509a45ae24@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Maarten Lankhorst Cc: intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, Daniel Vetter , Lyude List-Id: dri-devel@lists.freedesktop.org T24gVHVlLCBBdWcgMDIsIDIwMTYgYXQgMDU6NDE6NTBQTSArMDIwMCwgTWFhcnRlbiBMYW5raG9y c3Qgd3JvdGU6Cj4gT3AgMDEtMDgtMTYgb20gMTM6NDggc2NocmVlZiBWaWxsZSBTeXJqw6Rsw6Q6 Cj4gPiBPbiBNb24sIEF1ZyAwMSwgMjAxNiBhdCAxMDo0ODozN0FNICswMjAwLCBNYWFydGVuIExh bmtob3JzdCB3cm90ZToKPiA+PiBPcCAyOS0wNy0xNiBvbSAyMjozMyBzY2hyZWVmIE1hdHQgUm9w ZXI6Cj4gPj4+IE9uIEZyaSwgSnVsIDI5LCAyMDE2IGF0IDEyOjM5OjA1UE0gKzAzMDAsIFZpbGxl IFN5cmrDpGzDpCB3cm90ZToKPiA+Pj4+IE9uIFRodSwgSnVsIDI4LCAyMDE2IGF0IDA1OjAzOjUy UE0gLTA3MDAsIE1hdHQgUm9wZXIgd3JvdGU6Cj4gPj4+Pj4gVGhpcyBpcyBjb21wbGV0ZWx5IHVu dGVzdGVkIChhbmQgcHJvYmFibHkgaG9ycmlibHkgYnJva2VuL2J1Z2d5KSwgYnV0Cj4gPj4+Pj4g aGVyZSdzIGEgcXVpY2sgbW9ja3VwIG9mIHRoZSBnZW5lcmFsIGFwcHJvYWNoIEkgd2FzIHRoaW5r aW5nIGZvcgo+ID4+Pj4+IGVuc3VyaW5nIEREQiAmIFdNJ3MgY2FuIGJlIHVwZGF0ZWQgdG9nZXRo ZXIgd2hpbGUgZW5zdXJpbmcgdGhlCj4gPj4+Pj4gdGhyZWUtc3RlcCBwaXBlIGZsdXNoaW5nIHBy b2Nlc3MgaXMgaG9ub3JlZDoKPiA+Pj4+Pgo+ID4+Pj4+ICAgICAgICAgaHR0cHM6Ly9naXRodWIu Y29tL21hdHRyb3BlL2tlcm5lbC9jb21taXRzL2V4cGVyaW1lbnRhbC9seXVkZV9kZGIKPiA+Pj4+ Pgo+ID4+Pj4+IEJhc2ljYWxseSB0aGUgaWRlYSBpcyB0byB0YWtlIG5vdGUgb2Ygd2hhdCdzIGhh cHBlbmluZyB0byB0aGUgcGlwZSdzIEREQgo+ID4+Pj4+IGFsbG9jYXRpb24gKHNocmlua2luZywg Z3Jvd2luZywgdW5jaGFuZ2VkLCBldGMuKSBkdXJpbmcgdGhlIGF0b21pYyBjaGVjawo+ID4+Pj4+ IHBoYXNlOwo+ID4+Pj4gRGlkbid0IGxvb2sgdG9vIGNsb3NlbHksIGJ1dCBJIHRoaW5rIHlvdSBj YW4ndCBhY3R1YWxseSBkbyB0aGF0IHVubGVzcwo+ID4+Pj4geW91IGxvY2sgYWxsIHRoZSBjcnRj cyB3aGVuZXZlciB0aGUgbnVtYmVyIG9mIGFjdGl2ZSBwaXBlcyBpcyBnb2luZCB0bwo+ID4+Pj4g Y2hhbmdlLiBNZWFuaW5nIHdlJ2QgZXNzZW50aWFsbHkgYmUgYmFjayB0byB0aGUgb25lLWJpZy1t b2Rlc2V0LWxvY2sKPiA+Pj4+IGFwcG9yYWNoLCB3aGljaCB3aWxsIGNhdXNlIG1pc3NlZCBmbGlw cyBhbmQgd2hhbm90IG9uIHRoZSBvdGhlciBwaXBlcy4KPiA+Pj4+Cj4gPj4+PiBUaGUgYWx0ZXJu YXRpdmUgSSB0aGluayB3b3VsZCBjb25zaXN0IG9mOgo+ID4+Pj4gLSBtYWtlIHN1cmUgbGV2ZWwg MCB3YXRlcm1hcmsgbmV2ZXIgZXhjZWVkcyB0b3RhbF9kZGJfc2l6ZS9tYXhfcGlwZXMsCj4gPj4+ PiAgIHNvIHRoYXQgYSBtb2Rlc2V0IGRvZXNuJ3QgaGF2ZSB0byBjYXJlIGFib3V0IHRoZSB3bXMg Zm9yIHRoZSBvdGhlcgo+ID4+Pj4gICBwaXBlcyBub3QgZml0dGluZyBpbgo+ID4+PiBVbmZvcnR1 bmF0ZWx5IHRoaXMgcGFydCBpcyB0aGUgcHJvYmxlbS4gIFlvdSBtaWdodCBnZXQgYXdheSB3aXRo IGRvaW5nCj4gPj4+IHRoaXMgb24gU0tML0tCTCB3aGljaCBvbmx5IGhhdmUgdGhyZWUgcGxhbmVz IG1heCBwZXIgcGlwZSBhbmQgYSBsYXJnZQo+ID4+PiAoODk2IGJsb2NrKSBEREIsIGJ1dCBvbiBC WFQgeW91IGhhdmUgdXAgdG8gZm91ciBwbGFuZXMgKHdlIGRvbid0Cj4gPj4+IGFjdHVhbGx5IGVu YWJsZSB0aGUgdG9wbW9zdCBwbGFuZSBpbiBhIGZ1bGwtZmVhdHVyZWQgbWFubmVyIGp1c3QgeWV0 LAo+ID4+PiBidXQgbmVlZCB0byBzb29uKSwgeWV0IHRoZSB0b3RhbCBEREIgaXMgb25seSA1MTIg YmxvY2tzLiAgU2FkbHksIHRoZQo+ID4+PiBwbGF0Zm9ybSB3aXRoIG1vcmUgcGxhbmVzIHdhcyBn aXZlbiBhIHNtYWxsZXIgRERCLi4uICAgOi0oCj4gPj4+IFdlJ3JlIGFscmVhZHkgaW4gdHJvdWJs ZSBiZWNhdXNlIHVzZXJzIHRoYXQgYXJlIHJ1bm5pbmcgc2V0dXBzIGxpa2UgM3gKPiA+Pj4gNEsg d2l0aCBtb3N0L2FsbCBwbGFuZXMgaW4gdXNlIGF0IGxhcmdlIHNpemVzIGNhbid0IGZpbmQgbGV2 ZWwgMAo+ID4+PiB3YXRlcm1hcmtzIHRoYXQgc2F0aXNmeSB0aGVpciBuZWVkcyBhbmQgd2UgaGF2 ZSB0byByZWplY3QgdGhlIHdob2xlCj4gPj4+IGNvbmZpZ3VyYXRpb24uICBJZiB3ZSBmdXJ0aGVy IGxpbWl0IGVhY2ggcGlwZSdzIHVzYWdlIHRvIHRvdGFsL21heHBpcGVzCj4gPj4+IChpLmUuLCAx NzAgYmxvY2tzIHBlciBwaXBlIG9uIEJYVCksIHRoZW4gd2UncmUgZ29pbmcgdG8gaGl0IHNpbWls YXIKPiA+Pj4gaXNzdWVzIHdoZW4gb25seSBkcml2aW5nIG9uZSBvciB0d28gZGlzcGxheXMgd2l0 aCB3aXRoIGFsbCBvZiB0aGUgcGxhbmVzCj4gPj4+IGluIHVzZSwgZXZlbiB0aG91Z2ggd2Ugc2hv dWxkIGhhdmUgaGFkIG1vcmUgRERCIHNwYWNlIHRvIHdvcmsgd2l0aC4KPiA+Pj4KPiA+Pj4gSSBn dWVzcyBzZXJpb3VzIHBsYW5lIHVzYWdlIGlzbid0IHRvbyBjb21tb24gaW4gZGVza3RvcCBzZXR1 cHMgdG9kYXksCj4gPj4+IGJ1dCBpdCdzIGEgdmVyeSBjcml0aWNhbCBmZWF0dXJlIGluIHRoZSBl bWJlZGRlZCB3b3JsZDsgd2UgY2FuJ3QgcmVhbGx5Cj4gPj4+IGFmZm9yZCB0byBjcmlwcGxlIHBs YW5lIHVzYWdlIGZ1cnRoZXIuICBVbmZvcnR1bmF0ZWx5LCBhcyB5b3UgcG9pbnQgb3V0Cj4gPj4+ IGFib3ZlLCB0aGlzIG1lYW5zIHRoYXQgd2UgaGF2ZSB0byBmb2xsb3cgdGhlIGJzcGVjJ3MgRERC IGFsbG9jYXRpb24KPiA+Pj4gbWV0aG9kLCB3aGljaCBpbiB0dXJuIG1lYW5zIHdlIG5lZWQgdG8g Z3JhYiBfYWxsXyBDUlRDIGxvY2tzIGFueSB0aW1lCj4gPj4+IF9hbnlfIENSVEMgaXMgYmVpbmcg dHVybmVkIG9uIG9yIHR1cm5lZCBvZmYgd2hpY2ggaXMgYSBCS0wtc3R5bGUgd2F5IG9mCj4gPj4+ IGRvaW5nIHRoaW5ncy4KPiA+PiBNZWgsIEknbSBydW5uaW5nIGludG8gYSBzaW1pbGFyIGlzc3Vl IG9uIHZsdi9jaHYuIEkgZG9uJ3Qgc2VlIGEgd2F5IGFyb3VuZCBpdC4gOigKPiA+IE5vdyBhcmUg eW91IGhpdHRpbmcgaXQgdy8gdmx2L2Nodj8gVGhleSBkb24ndCBldmVuIGhhdmUgYSBzaGFyZWQg RERCLgo+IE5vdCByZWFsbHkgdGhlIHNhbWUsIGJ1dCBkZXRlcm1pbmluZyB3aGF0IHBvd2VyIHNh dmluZyBsZXZlbHMgKyB2YWx1ZXMgdG8gc2V0IHdpdGggcG9zc2libHkgcGFyYWxsZWwgdXBkYXRl cy4KCkp1c3QgbGlrZSBJTEsgd2UganVzdCBuZWVkIHRvIHRyYWNrIHJlYXNvbmFibHkgY2xvc2Vs eSBob3cgbWFueSBwaXBlcwphcmUgYWN0aXZlLCBhbmQgcmVkbyB0aGUgd20gbGV2ZWwgc2VsZWN0 aW9uIHdoZW4gdGhhdCBjaGFuZ2VzLiBKdXN0Cm1ha2Ugc3VyZSB0aGUgY29kZSBuZXZlciB0aGlu a3MgdGhlcmUgYXJlIGxlc3MgcGlwZXMgYWN0aXZlIHRoYW4gaW4KcmVhbGl0eSwgYW5kIGl0IHNo b3VsZCBhbGwgYmUgc2FmZS4KCkluIHRoZW9yeSB3ZSB3b3VsZG4ndCBldmVuIG5lZWQgdG8gZG8g dGhhdCBzaW5jZSB0aGUgUE01L0REUiBEVkZTIGRvbid0CmFjdHVhbGx5IGRlcGVuZCBvbiB0aGUg bnVtYmVyIG9mIGFjdGl2ZSBwaXBlcy4gSXQncyBqdXN0IHRoYXQgdGhleSBuZXZlcgp2YWxpZGF0 ZWQgdGhhdCBjb21iaW5hdGlvbiwgc28gaXQncyBub3Qgc29tZXRoaW5nIHRoYXQncyByZWNvbW1l bmRlZCB0bwpiZSB1c2VkLiBBbmQgc2luY2UgdGhlIHdob2xlIEREUiBEVkZTIGV4dHJhIGxhdGVu Y3kgdnMuIERETCBkZWFkbGluZXMKaXMgc3VjaCBhIG1lc3MsIGl0IHByb2JhYmx5IHdvdWxkIGVu ZCB1cCBpbiBtb3JlIHVuZGVycnVucy4KCi0tIApWaWxsZSBTeXJqw6Rsw6QKSW50ZWwgT1RDCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmRyaS1kZXZlbCBt YWlsaW5nIGxpc3QKZHJpLWRldmVsQGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RyaS1kZXZlbAo= From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965047AbcHBQBV (ORCPT ); Tue, 2 Aug 2016 12:01:21 -0400 Received: from mga01.intel.com ([192.55.52.88]:40139 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934006AbcHBQBK (ORCPT ); Tue, 2 Aug 2016 12:01:10 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,461,1464678000"; d="scan'208";a="1028407731" Date: Tue, 2 Aug 2016 18:59:33 +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: <20160802155933.GA4329@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> <20160801114801.GM4329@intel.com> <6cbd3f43-c337-a9e6-0f6b-cd509a45ae24@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: <6cbd3f43-c337-a9e6-0f6b-cd509a45ae24@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 Tue, Aug 02, 2016 at 05:41:50PM +0200, Maarten Lankhorst wrote: > 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. Just like ILK we just need to track reasonably closely how many pipes are active, and redo the wm level selection when that changes. Just make sure the code never thinks there are less pipes active than in reality, and it should all be safe. In theory we wouldn't even need to do that since the PM5/DDR DVFS don't actually depend on the number of active pipes. It's just that they never validated that combination, so it's not something that's recommended to be used. And since the whole DDR DVFS extra latency vs. DDL deadlines is such a mess, it probably would end up in more underruns. -- Ville Syrjälä Intel OTC