From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kenneth Graunke Subject: Re: [PATCH 00/68] Broadwell 48b addressing and prelocations (no relocs) Date: Thu, 21 Aug 2014 23:59:04 -0700 Message-ID: <3731912.J4bsBzmGca@vakarian> References: <1408677155-1840-1-git-send-email-benjamin.widawsky@intel.com> <20140822063037.GA3249@nuc-i3427.alporthouse.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1517560024==" Return-path: Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by gabe.freedesktop.org (Postfix) with ESMTP id 87CF86E232 for ; Thu, 21 Aug 2014 23:56:55 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id g10so14887837pdj.26 for ; Thu, 21 Aug 2014 23:56:55 -0700 (PDT) In-Reply-To: <20140822063037.GA3249@nuc-i3427.alporthouse.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: intel-gfx@lists.freedesktop.org Cc: mesa-dev , Ben Widawsky , Anthony Bernecky List-Id: intel-gfx@lists.freedesktop.org --===============1517560024== Content-Type: multipart/signed; boundary="nextPart1493748.Qj1dEbbOfp"; micalg="pgp-sha1"; protocol="application/pgp-signature" --nextPart1493748.Qj1dEbbOfp Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" On Friday, August 22, 2014 07:30:37 AM Chris Wilson wrote: > On Thu, Aug 21, 2014 at 08:11:23PM -0700, Ben Widawsky wrote: > > The primary goal of these patches is to introduce what I've started= > > calling, "prelocations" on Broadwell. A prelocation is like a > > relocation, except not. When a GPU client specifies a prelocation, = it is > > instructing the kernel where in the GPU address the buffer should b= e > > mapped. The mechanic works very similarly to a relocation except it= uses > > the execbuffer object to obtain the offset, and bind if needed. >=20 > You are mixing two APIs. One to preallocate an offset at creation > and one to presume relocations during execbuffer. I'd much rather kee= p > the flexible execbuffer approach outlined and first submitted a coupl= e of > years ago. >=20 > > If a GPU > > client uses only prelocations, the relocation process can be entire= ly > > skipped. This sounds like a big win initially, >=20 > Close to zero if the client uses existing interfaces. > -Chris Chris, I don't know if you've seen Ben's libdrm and Mesa patches, but with a f= ew patches to libdrm and virtually zero Mesa changes, he's apparently e= liminated our need to do any relocations for the 3D driver. It wasn't = invasive at all---I was surprised. With both the CPU and GPU using 48-bit addressing, using the same virtu= al address on both sides and never changing it seems quite appealing. = I'm not sure why we would need to do anything different than that. As I understand it, we still need to let the kernel know what buffers w= e need pinned during the course of the batchbuffer, since we can't take= a page fault and fetch them as needed. Reusing the existing relocatio= n list but just not doing relocations seems like a simple way to do tha= t without having to invent much new API... What is the 'flexible execbuffer' approach you mention from a few years= back? I don't remember hearing about it (sorry)... =2D-Ken --nextPart1493748.Qj1dEbbOfp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABAgAGBQJT9uo8AAoJEFtb2gcdScw4r8UP/10sWA9+IzUbHPFm94Gfz88c gFal11xHozEbDtO34MKhrmne8PvUc3T8rzUnpYKcgAvIRmFF82hMyPQ/zeOxnGox R2XQ0zPeb0ECmu/2V/i3xYGE+WbxszWfq/aXC1gDBO8tnO48AWUO0GHmb+j2563x 9AZT3OgBiqeAxJ0TZwux1NN7WZjvF4P3GZFSP0RaY7L4USqb9jDSHuhFr1tlJQzM WVnMT3ro9pLDSTamr2hee8ScOMzzLPfCJW3B0MOrBkDqb5kshcmQp3SpeRrIlKf2 h4KiLJCXFRWcQ61nUXo5wI7fm8Dcc21WXo8FRmy2k/beaeambWC/3Z0AmYhdsyNy vSfiNU/uyyhOdn//ALBnBxvHOHkQeDOnO3NInAfqjbfTz78ruUT1GtIIPQc/bGSh dpDq0sAsQxJrbvGbjNOxz80q82crfxgQ81oX2neBkw5ZOJ3nSGyyV93Vr/e6X0Vr pO7s3SdnWWC8K2wxypCkY3JQeVrSUEqQIRnlZ+Tc/To6zI02gDATW0U1cn+0SdFX ohjQkX1O3tZEQVXDPVwSftPdHSVrZMqMwgAK5fLTen3SwDWIDf7orYzWvpFv4Jb3 DwORT8c+tjO+ndAKSHAu9HTxnopmHtwq7bgSaFqztyO0h+ycjhd5DW2jjPjMxYNR kvtcqD5iZoJNKEkA70mk =6Stb -----END PGP SIGNATURE----- --nextPart1493748.Qj1dEbbOfp-- --===============1517560024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============1517560024==--