From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Christian_K=c3=b6nig?= Subject: Re: [git pull] drm for v4.15 Date: Fri, 17 Nov 2017 20:18:01 +0100 Message-ID: References: <26729c32-cfd6-82e0-b370-a46ca951adea@gmail.com> <29dd45a7-4a58-ed71-e6d4-1cd4bfc69ee5@amd.com> Reply-To: christian.koenig@amd.com Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8"; Format="flowed" Content-Transfer-Encoding: base64 Return-path: Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) by gabe.freedesktop.org (Postfix) with ESMTPS id DE3756EA85 for ; Fri, 17 Nov 2017 19:18:06 +0000 (UTC) Received: by mail-wm0-x232.google.com with SMTP id g130so4475676wme.0 for ; Fri, 17 Nov 2017 11:18:06 -0800 (PST) In-Reply-To: Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: Linus Torvalds , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: =?UTF-8?Q?Nicolai_H=c3=a4hnle?= , LKML , dri-devel List-Id: dri-devel@lists.freedesktop.org QW0gMTcuMTEuMjAxNyB1bSAxOTo1NSBzY2hyaWViIExpbnVzIFRvcnZhbGRzOgo+IE9uIEZyaSwg Tm92IDE3LCAyMDE3IGF0IDEwOjE0IEFNLCBDaHJpc3RpYW4gS8O2bmlnCj4gPGNocmlzdGlhbi5r b2VuaWdAYW1kLmNvbT4gd3JvdGU6Cj4+IFRha2luZyBhbiBleGFtcGxlIGZyb20gdGhlIEFNRCBo ZWFkZXJzIHdoeSB0aGlzIGF1dG9tYXRpb24gaXMgbW9yZSB0cmlja3kKPj4gdGhhbiBpdCBzb3Vu ZHMgaW4gdGhlIGZpcnN0IHBsYWNlOiBMb29rIGF0IHRoZQo+PiBtbVZNX0NPTlRFWFQqX1BBR0Vf VEFCTEVfQkFTRV9BRERSIHJlZ2lzdGVycyBmb3IgZXhhbXBsZS4KPj4KPj4gUmVnaXN0ZXIgMC03 IGFyZSBjb25zZWN1dGl2ZSBhbmQgc28gY291bGQgYmUgcGVyZmVjdGx5IGFkZHJlc3NhYmxlIHdp dGggYW4KPj4gaW5kZXgsIGJ1dCByZWdpc3RlciA4LTE1IGFyZW4ndCBhbmQgc28gd2UgYWx3YXlz IGVuZCB3aXRoIGxvZ2ljIGxpa2UgaWYoaTw4KQo+PiAuLi4gZWxzZSAuLi4uCj4+Cj4+IFRoZSBy YXRpb25hbCBmcm9tIHRoZSBoYXJkd2FyZSBndXlzIGlzIG9idmlvdXMgdGhhdCB0aGV5IGluaXRp YWxseSBoYWQgb25seQo+PiA4IGFuZCBvbiBhIGxhdGVyIGhhcmR3YXJlIGdlbmVyYXRpb24gZXh0 ZW5kZWQgdGhhdCB0byAxNiByZWdpc3RlcnMuCj4gSGVoLiBJIGRvbid0IGRpc2FncmVlLCBidXQg YXQgdGhlIHNhbWUgdGltZSwgdGhhdCBjYXNlIGlzIGFjdHVhbGx5IGEKPiB3b25kZXJmdWwgZXhh bXBsZS4KPgo+IExldCdzIHRha2UgdGhlIGdtY182XzAgY2FzZSwgYmVjYXVzZSBpdCBzaG93cyB5 b3VyIGlycmVndWxhcml0eSwgYnV0Cj4gaXQgYWxzbyBzaG93cyBhbm90aGVyIGhvcnJpZCBleGFt cGxlIG9mIG5hc3R5IG5hc3R5IGF1dG9tYXRpb246Cj4KPiAgICBtbVZNX0NPTlRFWFQwX1BBR0Vf VEFCTEVfQkFTRV9BRERSIDB4MDU0Rgo+ICAgIG1tVk1fQ09OVEVYVDEwX1BBR0VfVEFCTEVfQkFT RV9BRERSIDB4MDUxMAo+ICAgIG1tVk1fQ09OVEVYVDExX1BBR0VfVEFCTEVfQkFTRV9BRERSIDB4 MDUxMQo+ICAgIG1tVk1fQ09OVEVYVDEyX1BBR0VfVEFCTEVfQkFTRV9BRERSIDB4MDUxMgo+ICAg IG1tVk1fQ09OVEVYVDEzX1BBR0VfVEFCTEVfQkFTRV9BRERSIDB4MDUxMwo+ICAgIG1tVk1fQ09O VEVYVDE0X1BBR0VfVEFCTEVfQkFTRV9BRERSIDB4MDUxNAo+ICAgIG1tVk1fQ09OVEVYVDE1X1BB R0VfVEFCTEVfQkFTRV9BRERSIDB4MDUxNQo+ICAgIG1tVk1fQ09OVEVYVDFfUEFHRV9UQUJMRV9C QVNFX0FERFIgMHgwNTUwCj4gICAgbW1WTV9DT05URVhUMl9QQUdFX1RBQkxFX0JBU0VfQUREUiAw eDA1NTEKPiAgICBtbVZNX0NPTlRFWFQzX1BBR0VfVEFCTEVfQkFTRV9BRERSIDB4MDU1Mgo+ICAg IG1tVk1fQ09OVEVYVDRfUEFHRV9UQUJMRV9CQVNFX0FERFIgMHgwNTUzCj4gICAgbW1WTV9DT05U RVhUNV9QQUdFX1RBQkxFX0JBU0VfQUREUiAweDA1NTQKPiAgICBtbVZNX0NPTlRFWFQ2X1BBR0Vf VEFCTEVfQkFTRV9BRERSIDB4MDU1NQo+ICAgIG1tVk1fQ09OVEVYVDdfUEFHRV9UQUJMRV9CQVNF X0FERFIgMHgwNTU2Cj4gICAgbW1WTV9DT05URVhUOF9QQUdFX1RBQkxFX0JBU0VfQUREUiAweDA1 MEUKPiAgICBtbVZNX0NPTlRFWFQ5X1BBR0VfVEFCTEVfQkFTRV9BRERSIDB4MDUwRgo+Cj4gT29w cy4gVGhvc2Ugd2VyZSBjbGVhcmx5IHNvcnRlZCBhdXRvbWF0aWNhbGx5LCBhbmQgaW4gZW50aXJl bHkgdGhlIHdyb25nIHdheS4KPgo+IFNvIGF1dG9tYXRpb24gaGFzIF9yZWFsbHlfIGRvbmUgc29t ZXRoaW5nIGluZXhjdXNhYmx5IHN0dXBpZCwgYW5kIG1hZGUKPiB0aGUgZW5kIHJlc3VsdCBjb21w bGV0ZWx5IGlsbGVnaWJsZSBpbiB0aGUgcHJvY2Vzcy4KClllYWgsIGJ1dCB0aGF0IGlzIGFscmVh ZHkgdGhlIGlucHV0IHdlIGdldCBmcm9tIHRoZSBoYXJkd2FyZSB0ZWFtcy4gRS5nLiAKaW4gdGhp cyBjYXNlIGEgbGlzdCBvZiByZWdpc3RlcnMgc29ydGVkIGJ5IHRoZWlyIG5hbWUgb3IgYWRkcmVz cyAob3IgCmV2ZW4gc29tZXRpbWVzIHNvbWUgaGFyZHdhcmUgaW50ZXJuYWwgbWFnaWMpLgoKVGhl cmUgaXNuJ3QgbXVjaCB3ZSBjb3VsZCBkbyBhYm91dCB0aGF0IGV4Y2VwdCBmb3IgbWFudWFsIG9y IHNlbWkgCm1hbnVhbGx5IGNsZWFuaW5nIHVwIHRoZSBtZXNzLgoKPiBBbmQgeWVzLCB5b3UnZCBi ZSByaWdodCB0aGF0IGl0J3MgZGlzY29udGlndW91cyBhdCA4LCBidXQgaXQncyBzdGlsbAo+IGFy aXRobWV0aWMsIGllIHlvdSBjb3VsZCBlYXNpbHkgaGF2ZQo+Cj4gICAjZGVmaW5lICBtbVZNX1BB R0VfVEFCTEVfQkFTRV9BRERSKGN0eCkgXAo+ICAgICAgICAgICgoY3R4KSsweDA1NGYtKChjdHgp ICYgOCkqOS0oKGN0eCkmOCkvOCkKPgo+IGFuZCBpZiAiY3R4IiBpcyBhIGNvbnN0YW50LCB0aGVu IHRoZSBlbmQgcmVzdWx0IGlzIHRyaXZpYWxseSBhCj4gY29uc3RhbnQgYW5kIGNhbiBiZSB1c2Vk IGFzIHN1Y2guIEFuZCBpZiBpdCBpc24ndCwgaXQncyBzdGlsbCBhIG11Y2gKPiBjaGVhcGVyIG9w ZXJhdGlvbiB0aGFuIGFuICJpZiIgb3IgInN3aXRjaCAoKSIgc3RhdGVtZW50IChpdCdzIGp1c3Qg YQo+IGJpdG1hc2sgYW5kIHR3byBzaGlmdHMpLgoKSW50ZXJlc3RpbmcgYXBwcm9hY2gsIGJ1dCBp dCBpcyBub3Qgc28gcGVyZm9ybWFuY2UgY3JpdGljYWwuIFNvIEkgd291bGQgCnN0aWxsIGdvIHdp dGggdGhlICJpZiIgb3IgIj8iIG9wZXJhdG9yIGp1c3QgZm9yIHRoZSBpbXByb3ZlZCByZWFkYWJp bGl0eS4KCj4gTm93LCBzZWVpbmcgdGhvc2UgcGF0dGVybnMgaXMgbGlrZWx5IG5vdCBzb21ldGhp bmcgdGhhdCBhdXRvbWF0aW9uCj4gc2hvdWxkIGRvIChhbHRob3VnaCBpdCdzIGRlZmluaXRlbHkg cG9zc2libGUgLSBzdXBlcm9wdGltaXplcnMgZG8gdGhhdAo+IGFsbCB0aGUgdGltZSksIGJ1dCBh dXRvbWF0aW9uIGNvdWxkIHN0aWxsICp2ZXJpZnkqIHRoZSBwYXR0ZXJucyBvbmNlIGEKPiBodW1h biBoYXMgbWFkZSB0aGVtIHVwLgoKV2VsbCwgdGhpcyB3YXMganVzdCBhIHJhdGhlciBzaW1wbGUg ZXhhbXBsZSwgdGhlIHJlYWwgcHJvYmxlbSBpcyB0aGF0IApzb21lIGJsb2NrcyBoYXZlIGEgZG96 ZW4gaW5zdGFuY2VzIGFuZCA+MTBrIHJlZ2lzdGVycyBlYWNoLgoKTWFudWFsIGludGVydmVudGlv biBpcyBqdXN0IGNvbXBsZXRlbHkgb3V0IG9mIHF1ZXN0aW9uIHdoZW4gYXBwbGllZCB0byAKdGhl IGdlbmVyYWwgcHJvYmxlbS4KCldoYXQgd2UgbmVlZCBpcyBzb21lIGF1dG9tYXRpb24sIGJ1dCBh cyB5b3Ugd3JvdGUgYXMgd2VsbCB0aGF0IGlzIApwb3NzaWJsZSBidXQgZmFyIGZyb20gZWFzeS4K Cj4gQW5kIGl0J3MgcXVpdGUgcG9zc2libGUgdGhhdCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0 byBlbmNvZGUgdGhhdAo+IHBhdHRlcm4gZXZlbiBpbiB0aGUgb3JpZ2luYWwgc291cmNlIGNvZGUu IEluIGZhY3QsIGl0IG1heSAqYmUqIHRoZXJlCj4gc29tZXdoZXJlIChub3QgYXMgdGhhdCBhcml0 aG1ldGljIGV4cHJlc3Npb24sIGJ1dCBhcyB0aGUgcmV2ZXJzZQo+IGRlY29kZSBsb2dpYywgb2J2 aW91c2x5KS4KClRoZSBvYnZpb3VzIGFsdGVybmF0aXZlIHdoaWNoIHdlIGFyZSB3b3JraW5nIG9u IGZvciBhIGZldyB5ZWFycyBub3cgaXMgCnRvIGltcHJvdmUgdGhlIGlucHV0IGRhdGEgd2UgZ2V0 IGZyb20gdGhlIGhhcmR3YXJlIHBlb3BsZS4KCkluIG90aGVyIHdvcmRzIGluc3RlYWQgb2YgZ2V0 dGluZyBhIGZsYXQgbGlzdCBvZiByZWdpc3RlcnMgd2Ugd2FudCB0aGUgCmluZm9ybWF0aW9uIGFi b3V0IHdoZXJlIGFuZCBob3cgbWFueSB0aW1lcyBhIGhhcmR3YXJlIGJsb2NrIHdhcyAKaW5zdGFu dGlhdGVkLgoKQnV0IGdldHRpbmcgdGhhdCBwcm92ZWQgbXVjaCBtb3JlIGRpZmZpY3VsdCB0aGFu IHdlIHRob3VnaHQgYW5kIHllcyB3ZSAKYXJlIHdvcmtpbmcgb24gdGhhdCBmb3IgbXVsdGlwbGUg eWVhcnMgbm93LgoKUmVnYXJkcywKQ2hyaXN0aWFuLgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwpkcmktZGV2ZWwgbWFpbGluZyBsaXN0CmRyaS1kZXZlbEBs aXN0cy5mcmVlZGVza3RvcC5vcmcKaHR0cHM6Ly9saXN0cy5mcmVlZGVza3RvcC5vcmcvbWFpbG1h bi9saXN0aW5mby9kcmktZGV2ZWwK From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933840AbdKQTSe (ORCPT ); Fri, 17 Nov 2017 14:18:34 -0500 Received: from mail-wm0-f48.google.com ([74.125.82.48]:34585 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161705AbdKQTSG (ORCPT ); Fri, 17 Nov 2017 14:18:06 -0500 X-Google-Smtp-Source: AGs4zMZj/wOoPdtZ7XHLXK2bwg13BDlfQeH952mNRCDWMzUMSJ3D7ClM5ZMGsb0F8qX0VJOsNpPt5g== Reply-To: christian.koenig@amd.com Subject: Re: [git pull] drm for v4.15 To: Linus Torvalds , =?UTF-8?Q?Christian_K=c3=b6nig?= Cc: =?UTF-8?Q?Nicolai_H=c3=a4hnle?= , LKML , dri-devel References: <26729c32-cfd6-82e0-b370-a46ca951adea@gmail.com> <29dd45a7-4a58-ed71-e6d4-1cd4bfc69ee5@amd.com> From: =?UTF-8?Q?Christian_K=c3=b6nig?= Message-ID: Date: Fri, 17 Nov 2017 20:18:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 17.11.2017 um 19:55 schrieb Linus Torvalds: > On Fri, Nov 17, 2017 at 10:14 AM, Christian König > wrote: >> Taking an example from the AMD headers why this automation is more tricky >> than it sounds in the first place: Look at the >> mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example. >> >> Register 0-7 are consecutive and so could be perfectly addressable with an >> index, but register 8-15 aren't and so we always end with logic like if(i<8) >> ... else .... >> >> The rational from the hardware guys is obvious that they initially had only >> 8 and on a later hardware generation extended that to 16 registers. > Heh. I don't disagree, but at the same time, that case is actually a > wonderful example. > > Let's take the gmc_6_0 case, because it shows your irregularity, but > it also shows another horrid example of nasty nasty automation: > > mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x054F > mmVM_CONTEXT10_PAGE_TABLE_BASE_ADDR 0x0510 > mmVM_CONTEXT11_PAGE_TABLE_BASE_ADDR 0x0511 > mmVM_CONTEXT12_PAGE_TABLE_BASE_ADDR 0x0512 > mmVM_CONTEXT13_PAGE_TABLE_BASE_ADDR 0x0513 > mmVM_CONTEXT14_PAGE_TABLE_BASE_ADDR 0x0514 > mmVM_CONTEXT15_PAGE_TABLE_BASE_ADDR 0x0515 > mmVM_CONTEXT1_PAGE_TABLE_BASE_ADDR 0x0550 > mmVM_CONTEXT2_PAGE_TABLE_BASE_ADDR 0x0551 > mmVM_CONTEXT3_PAGE_TABLE_BASE_ADDR 0x0552 > mmVM_CONTEXT4_PAGE_TABLE_BASE_ADDR 0x0553 > mmVM_CONTEXT5_PAGE_TABLE_BASE_ADDR 0x0554 > mmVM_CONTEXT6_PAGE_TABLE_BASE_ADDR 0x0555 > mmVM_CONTEXT7_PAGE_TABLE_BASE_ADDR 0x0556 > mmVM_CONTEXT8_PAGE_TABLE_BASE_ADDR 0x050E > mmVM_CONTEXT9_PAGE_TABLE_BASE_ADDR 0x050F > > Oops. Those were clearly sorted automatically, and in entirely the wrong way. > > So automation has _really_ done something inexcusably stupid, and made > the end result completely illegible in the process. Yeah, but that is already the input we get from the hardware teams. E.g. in this case a list of registers sorted by their name or address (or even sometimes some hardware internal magic). There isn't much we could do about that except for manual or semi manually cleaning up the mess. > And yes, you'd be right that it's discontiguous at 8, but it's still > arithmetic, ie you could easily have > > #define mmVM_PAGE_TABLE_BASE_ADDR(ctx) \ > ((ctx)+0x054f-((ctx) & 8)*9-((ctx)&8)/8) > > and if "ctx" is a constant, then the end result is trivially a > constant and can be used as such. And if it isn't, it's still a much > cheaper operation than an "if" or "switch ()" statement (it's just a > bitmask and two shifts). Interesting approach, but it is not so performance critical. So I would still go with the "if" or "?" operator just for the improved readability. > Now, seeing those patterns is likely not something that automation > should do (although it's definitely possible - superoptimizers do that > all the time), but automation could still *verify* the patterns once a > human has made them up. Well, this was just a rather simple example, the real problem is that some blocks have a dozen instances and >10k registers each. Manual intervention is just completely out of question when applied to the general problem. What we need is some automation, but as you wrote as well that is possible but far from easy. > And it's quite possible that it would be a good idea to encode that > pattern even in the original source code. In fact, it may *be* there > somewhere (not as that arithmetic expression, but as the reverse > decode logic, obviously). The obvious alternative which we are working on for a few years now is to improve the input data we get from the hardware people. In other words instead of getting a flat list of registers we want the information about where and how many times a hardware block was instantiated. But getting that proved much more difficult than we thought and yes we are working on that for multiple years now. Regards, Christian.