From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH] drm/i915: Update MOCS settings for gen 9 Date: Fri, 05 May 2017 12:36:52 -0700 Message-ID: <8300953.UsdlOxdvAc@eiger> References: <20170426150041.15896-1-david.weinehall@linux.intel.com> <3234648.HkJoGCyhd9@eiger> <9fd0cc7e-d2e7-6fed-b279-98e1b06355e6@intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1465129761==" Return-path: Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) by gabe.freedesktop.org (Postfix) with ESMTPS id 029896E0D0 for ; Fri, 5 May 2017 19:37:01 +0000 (UTC) Received: by mail-pg0-x236.google.com with SMTP id q4so7434964pga.3 for ; Fri, 05 May 2017 12:37:01 -0700 (PDT) In-Reply-To: <9fd0cc7e-d2e7-6fed-b279-98e1b06355e6@intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Dmitry Rogozhkin Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1465129761== Content-Type: multipart/signed; boundary="nextPart10164234.x8GepORzSM"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart10164234.x8GepORzSM Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, May 5, 2017 9:21:54 AM PDT Dmitry Rogozhkin wrote: > > My point largely stands, when redirected - someone is developing a > > broken closed source userspace driver and is apparently unwilling to > > change it. That's the real problem. > Broken? Have you ever attempted to run functional and performance > competitive between closed source and open source user space drivers? I > attempted and a number of others have attempted that. Result is that > open source driver has significantly worse encoding quality, worse to > the degree that any performance comparisons start to make no sense. > (Yep, work in progress to try to fix that, I know.) Decoding quality is > on par, but I saw cases when performance is 5-10% worse (and that's when > both drivers work on their presumably optimal settings). So, "broken" > closed source driver is in use for the _reason_. And which driver could > be considered "broken" after that: closed source one or open source one? I'm not in any way arguing that one driver is superior to the other, nor that anyone should do performance comparisons between the two. > So, why you are addressing that closed source driver is broken? If it > will be put in the environment with the upstream kernel, then it will > eventually be broken and that's what we are trying to fix here. But do > you realize that in the production environment where the driver is > intended to work there is a patched kernel mode driver in place with the > MOCS settings to satisfy the need of the driver? Or you naively think we > use non-modified KMD from the upstream or previously released versions > from kernel.org. Bad guess! In the production environment driver is not > broken. Yes, I'm aware that the closed source userspace relies on a patched non-upstream kernel, and that it's being used in some environments. Presumably it works just fine there. Isn't the goal to make that userspace driver run on the upstream Linux kernel, so people can use it in places other than the environment where it currently exists? Would it not make sense to have it run reasonably well on upstream kernels that are currently shipping? On released upstream kernels, there are only three MOCS entries: UC, PTE, and WB. Using any other entries is ill-advised (even broken), not only because they currently correspond to UC (leading to poor performance), but because they may change meaning in the future. Future upstream kernels may add new entries, and presumably would advertise that via a getparam (i.e. I915_PARAM_MOCS_TABLE_VERSION). The suggestion is to make your userspace driver use entry 2 (WB) for anything you want cached, when running on an upstream kernel (but keep using the existing entries on the patched kernel). That would perform much better than it currently does. You probably won't get the full 60%, but perhaps you'll get 50%. Then, add any additional entries you want to the kernel, advertise it via a GETPARAM, and make your driver use those new entries when they are supported. Benchmark. See how much faster your workload is with the new entries (compared to WB-for-everything). That's the number everyone here wants to see. This should be a trivial amount of work - nobody's asking for any combinatorial explosion of testing. Doing this exercise also means that your software would perform better on currently shipping upstream kernels (arguably improving the driver) - and once you have the full set of entries, it will perform even better. Does that make sense? --Ken --nextPart10164234.x8GepORzSM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAlkM1FQACgkQW1vaBx1J zDjDJQ/8CWEhmAFe6PpqfBA3xTHQ8V2K11RQI2qvLdHKnK5gvCt9iyEK2WN4PnDy E92XZAWR0zeNYJ0BYj2InKOHQ6cLh15hZ1XXJQ3GOAm5lXG1nQNZktV9P6Ii34pi my0JVEke3yoRp47mWJVmFGAO9EQJKB+zIxHeJXqHtwksA/MSf40b2UKnDeOBMxL7 5/BYwFbC9y4Ui77Pum7jMb6vJLJYdqpJwb+GFxrHyCDCJ8mCNDzvhKQCXp4dxGtM ebniMYtvNpTbPFiafXtMhxv4mQCU3DJ7+XH0JZQdAXfJ5cF8z/jbpvsEaES0WCSu UPEXUteLKs1rVAhJKTYZ6QRZ5LxFgnR6z9aeNbd5GKsqj84Q7LhxSXIHZ3OnUbRd 4xbY7WQD4R9y6paAy6nhFF2CBpWRmiKdGC3ZJWFhUHUiVQseiO1mkxrFoOffrxmF gu24fqAIZeONT+mnnU3ojgY0juuChsiLfwbAH8Btx3t2ioy/auCHWo935P3/p3l8 Bn4v61ylKDhxjcHlZeRnkbV4CDN31MifmcpamNXy36Wj8oChQwKQK9xYKehJJFaX 2g/hKd/qQ4xWL1iZHGifTseFOfmkc8mRQ2yC7mn9D0JCop2ihdcwbuRtxcyFJ1a4 acJppxjY1qLNG4KFAYRxqyHlD3q8z/00W2IbqRlSmavjQe/wmmg= =8b7P -----END PGP SIGNATURE----- --nextPart10164234.x8GepORzSM-- --===============1465129761== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1465129761==--