From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH 13/15] drm/i915: Allow execbuffer to use the first object as the batch Date: Fri, 07 Jul 2017 20:54:41 -0700 Message-ID: <78921289.IyuHic4ye4@kirito> References: <20170316132006.7976-1-chris@chris-wilson.co.uk> <1489749359.2892.13.camel@linux.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1898718750==" Return-path: Received: from smtp65.iad3a.emailsrvr.com (smtp65.iad3a.emailsrvr.com [173.203.187.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id A2F266E033 for ; Sat, 8 Jul 2017 04:01:42 +0000 (UTC) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Daniel Vetter Cc: Dave Airlie , intel-gfx List-Id: intel-gfx@lists.freedesktop.org --===============1898718750== Content-Type: multipart/signed; boundary="nextPart5049743.8RZ4r1aGJd"; micalg="pgp-sha256"; protocol="application/pgp-signature" --nextPart5049743.8RZ4r1aGJd Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Friday, July 7, 2017 3:17:22 AM PDT Daniel Vetter wrote: > On Fri, Mar 17, 2017 at 12:15 PM, Joonas Lahtinen > wrote: > > On to, 2017-03-16 at 13:20 +0000, Chris Wilson wrote: > >> Currently, the last object in the execlist is the always the batch. > >> However, when building the batch buffer we often know the batch object > >> first and if we can use the first slot in the execlist we can emit > >> relocation instructions relative to it immediately and avoid a separate > >> pass to adjust the relocations to point to the last execlist slot. > >> > >> Signed-off-by: Chris Wilson > > > > Reviewed-by: Joonas Lahtinen > > This patch was reviewed/pushed full month before the mesa patch was > fully reviewed and ready for merging. That's not how uapi is done. > > I've fixed this up now by at least reviewing the mesa patch, but for > next time around: If you review uapi, and you don't make sure the > userspace side is in good shape too, then you've not reviewed the > patch properly. > > Same goes for reviewing and not making sure there's tests, but that's > another rant. > > Ken, pls make sure we don't end up with another case like resource > streamer (or tell me I should revert this). > -Daniel Sorry, that's partly my bad - I had mentioned to Chris that I wanted this feature, and planned to use it, but then got distracted with other work and didn't get around to actually shipping a patch to do so. Both Chris and I wrote patches, and IIRC I was benchmarking things when I got distracted. Basically, I915_EXEC_HANDLE_LUT appeared to be a performance loss in the CPU bound benchmarks I looked at, because we had to walk over one of the lists and patch up references to the batch (-1 => actual index). BATCH_FIRST eliminates that overhead, making HANDLE_LUT actually useful (although only a small amount). --Ken --nextPart5049743.8RZ4r1aGJd Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE6OtbNAgc4e6ibv4ZW1vaBx1JzDgFAllgV4EACgkQW1vaBx1J zDhU/Q/+ISDm4k71h+dkjfJoGH7fvB1F5SUw+kmfKJbZ+co9CAnKzoCzlklNYIh/ irekEFlML3W8YeBuRuOLZ0NbKUaID7D4kWsJBIKnU1JjbDbOYHfk2vWmKPUetk/P iIZgQ4ebSVS9mT/Y4RP0rO+XEvYwUCBSW9fED/rJItt19YIjbHWoqV9549UR526w 5aduxLiofRtTWWIWbSVL4wa8Nqa/2RiQD+bhNC+1rrC0rincWwScVOv2SUeKOeob wQX9LuHVZRzuM0IrcF7vC4bg65hjXCeidPMLCp2o3Lhx8KkDylUa2DhJGmNPyoRp sJQOex0q2iL9Stnur7ozf3trmu0cGA6OkxqUOC29oR0bh76u+J5QtTNSoi7gQSlE S4fFKKx/NoVzo07FgzmgCWZNMRAWQ6tzG46fGjcP29GhIZkIQGCDv7hOU0mI4vcn IX0brtZ0FkKzRaxjiL4IQJqzys6Zhs1fTMSxOkjLdyDl4B66QhBhmBz+UkuGUfSM JpomJr/kEoBzjND10cG/QewKe2yauMqhterG25MKTIQNbbzpDz/dr1McvZ1nCchM akq/PwdDXbwvedU8Hoyx5dDWgp0J9v3jCZ3Azcu8j1aK168TVPbBAICG92LJvr+V 4Y6grO6byXHkbyz9E2VJViP9uVYkUt+GsHBqfC7KyxFupJoP5uk= =yhNe -----END PGP SIGNATURE----- --nextPart5049743.8RZ4r1aGJd-- --===============1898718750== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSW50ZWwtZ2Z4 IG1haWxpbmcgbGlzdApJbnRlbC1nZnhAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vaW50ZWwtZ2Z4Cg== --===============1898718750==--