From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [RFC 1/2] drm/i915: Engine discovery uAPI Date: Tue, 18 Apr 2017 22:22:18 -0700 Message-ID: <6570224.bZGvjJtkdM@eiger> References: <20170418165615.27666-1-tvrtko.ursulin@linux.intel.com> <20170418165615.27666-2-tvrtko.ursulin@linux.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0998343952==" Return-path: In-Reply-To: <20170418165615.27666-2-tvrtko.ursulin@linux.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: mesa-dev-bounces@lists.freedesktop.org Sender: "mesa-dev" To: mesa-dev@lists.freedesktop.org Cc: Oscar Mateo , Ben Widawsky , Joonas Lahtinen , Tvrtko Ursulin , Intel-gfx@lists.freedesktop.org, "Rogozhkin, Dmitry V" , Tvrtko Ursulin , Jon Bloomfield , Daniel Vetter , intel-vaapi-media@lists.01.org, "Gong, Zhipeng" List-Id: intel-gfx@lists.freedesktop.org --===============0998343952== Content-Type: multipart/signed; boundary="nextPart7678077.3t1HU66p44"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart7678077.3t1HU66p44 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tuesday, April 18, 2017 9:56:14 AM PDT Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Engine discovery uAPI allows userspace to probe for engine > configuration and features without needing to maintain the > internal PCI id based database. I don't understand why I would want to query the existence of engines from the kernel. As a userspace driver developer, I have to know how to program the specific generation of hardware I'm on. I better know what engines that GPU has, or else there's no way I can competently program it. In Mesa, we recently imported libdrm and deleted all the engine checks (a460e1eb51406e5ca54abda42112bfb8523ff046). All generations have an RCS, Gen6+ has a separate BLT, and we don't need to use the others. It's completely statically determinable with a simple check. Runtime checks make sense for optional things...but not "is there a 3D engine?". Plus, even if you add this to the kernel, we still support back to 3.6 (and ChromeOS needs us to continue supporting 3.8), so we won't be able to magically use the new uABI - we'd need to support both. Which, if the point is to delete code...we'd actually have /more/ code for a few years. Or, we could not use it...but then nobody would be testing it, and if a bug creeps in...that pushes it back more years still. Sorry :( --nextPart7678077.3t1HU66p44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAlj29AoACgkQW1vaBx1J zDgZlBAAjjoALpu3461yOxcJAMaLnffNjaR9J8tu24w1Pkm2umstoiUI5uaTnv/r RHez+pUu9z70Cop6dWEdztWKas6hpFrQELswLj1N0wOA9Urr256LEWqrFvvtgCzu qmIZXOdtsqXVh+wCJwTlcIlak0iqJ/rY+yt29hGVozb5YndLXoLn6e8X5kDUCyha 1IWR7qEt80Q5f4dMwiooSJr1JRVjn1+5GVDQq2KlPOTB1f6Qx3v5Wj8Ai3N0qppF Je5jp6hqJciO4Ja681rj4jNQL2YXvEaAWoWHQGagHaNpZXQj2v2omPgWDWrUFzOi 9qc1qhIK9Ed9ruoMz7OW9MfWmzxsShAF0QBxGKDLWErHjVJrxyVednnQxaJLLN3b qAQXFrmqbG8pFFe7BrjV7gHPb1nSeUAxoRAHzXtqHKIHsONlPE9Ezui7w82TL9rC yxbslcDlFbtSHGXFZkHp/EGD/tBW8TXwhSUUxNPOQdOa05VdTKoPSn5mc6RW0rA4 oSMKNlkOA0diPz7Bz+4z/CkixS1d6QRujfjVToMYvsNuw3hEvDzyEtimZejlK/Mi qVKV8pOAlXFObK8pWpetRFjuJ0utyxNR6F1vIQHo/KDosptA1fXlnPBac4yr4t8a xSFsGpIKVJZXQtu5++WkSBkPD5XyHVxRmrZkX7+kBk4Np++Ml64= =prCk -----END PGP SIGNATURE----- --nextPart7678077.3t1HU66p44-- --===============0998343952== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbWVzYS1kZXYg bWFpbGluZyBsaXN0Cm1lc2EtZGV2QGxpc3RzLmZyZWVkZXNrdG9wLm9yZwpodHRwczovL2xpc3Rz LmZyZWVkZXNrdG9wLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21lc2EtZGV2Cg== --===============0998343952==--