From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 1/3] drm/i915: Unbind the bo if the user requests a different alignment Date: Wed, 14 Apr 2010 14:19:49 -0700 Message-ID: <874ojdohoq.fsf@pollan.anholt.net> References: <1270416921-25483-1-git-send-email-chris@chris-wilson.co.uk> <87ljcswq9t.fsf@pollan.anholt.net> <89khjo$f4ssom@orsmga002.jf.intel.com> <87aat6vrol.fsf@pollan.anholt.net> <89k304$i8icq3@orsmga001.jf.intel.com> <20100414102336.GA3440@viiv.ffwll.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1458221302==" Return-path: In-Reply-To: <20100414102336.GA3440@viiv.ffwll.ch> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: intel-gfx-bounces@lists.freedesktop.org Errors-To: intel-gfx-bounces@lists.freedesktop.org To: Daniel Vetter , Chris Wilson Cc: intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1458221302== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, 14 Apr 2010 12:23:37 +0200, Daniel Vetter wrote: > On Wed, Apr 14, 2010 at 10:29:24AM +0100, Chris Wilson wrote: > > Darn. The current incarnation was literally for glyph masks, clip masks > > and all the other short-lived write-once, immediately use as source > > buffers within the same batch, and then discard. But there is nothing to > > ensure that they exist only within a batch, and so they could well fall > > foul of a17. I wonder if we can simply lazily rebind the bo at the point > > of fence allocation rather than at tiling change. I am not sure if that > > even makes sense yet. The other approach would seem to be to SET_TILING > > on the last use within a batch and hope that doesn't cause a stall. May= be > > also a mechanism to mark the buffer contents as uninitialized so that if > > we need to unbind, we can simply discard and allocate fresh pages? (An > > extension to madvise, MADV_UNINITIALIZED or MADV_CLEAN?) >=20 > At least currently, set_tiling always stalls when actually changing > something (if the alignment doesn't match or if there's a wrong fence reg > attached to the buffer). btw I think the libdrm bo caching has a bug wrt > to this: It resets tiling parameters before inserting a bo into the cache, > while the bo might still be busy. My first try at a patch a few weeks ago > blew up tough, so I left it as-is. Comments? I'd also tried to avoid that stall by just freeing tiled buffers, with no performance success. Your resetting tiling at realloc time instead might be a better plan than I had. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvGMXUACgkQHUdvYGzw6vdDlACfQxW+9nLjCmPBeiuIY/gIpeCs yUgAn10UoOo3fYIveyF57Ii/f/MTtWs4 =CRao -----END PGP SIGNATURE----- --=-=-=-- --===============1458221302== 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 --===============1458221302==--