From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH] drm/i915: intel hw has only one gpu write domain Date: Fri, 07 May 2010 13:53:29 -0700 Message-ID: <87fx2377sm.fsf@pollan.anholt.net> References: <1268565495-4805-1-git-send-email-daniel.vetter@ffwll.ch> <87hboek6jq.fsf@pollan.anholt.net> <20100317212927.GB3526@viiv.ffwll.ch> <87633o2rtm.fsf@pollan.anholt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0179293315==" Return-path: In-Reply-To: <87633o2rtm.fsf@pollan.anholt.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Mime-version: 1.0 Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: Daniel Vetter , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============0179293315== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Sun, 18 Apr 2010 17:45:25 -0700, Eric Anholt wrote: > On Wed, 17 Mar 2010 22:29:27 +0100, Daniel Vetter wrote: > > On Wed, Mar 17, 2010 at 02:00:09PM -0700, Eric Anholt wrote: > > > On Sun, 14 Mar 2010 12:18:15 +0100, Daniel Vetter wrote: > > > > It therefore holds that all objects on the gpu_write_domain are > > > > in this single write domain. Drop an if checking for the write > > > > domain in process_flushing_list. > > > >=20 > > > > For some odd reason retire_commands thinks that the sampler cache > > > > can be written to. Remove this and the assorted logic in do_execbuf. > > > >=20 > > > > Also check that userspace doesn't try to screw us over by claiming > > > > to write to some strange cache. > > > >=20 > > > > The idea for this patch emerged from a discussion with Chris Wilson. > > >=20 > > > The intent of the flush_domains in retire_commands was to note that t= he > > > read-only sampler cache was flushed and we could clear the read domai= ns > > > so that a later attempt to use it in the sampler cache wouldn't send = out > > > a new flush. > > >=20 > > > You've been looking into this stuff more than I have recently -- do y= ou > > > think that handling that information would be interesting? > >=20 > > atm we don't handle invalidating read-domains as efficient as > > write-domains. Read: We don't globally update all bo's when doing a > > sampler cache invalidations like we do when flushing the render cache. = So > > that flush_domain stuff from retire_commands was pure dead code. > >=20 > > We could do better of course. Problem is that tracking the buffers that > > might benefit from a read_domains with lists like we're doing for the > > write domain needs NUM_READ_DOMAIN list_heads per object. That's rather > > gross. But we could keep track of the last seqno this bo was dirtied > > (by either the gpu or the cpu, for the cpu just take the latest complet= ed > > seqno) and also keep track of the seqno of the last invalidate for each > > read cache. At execbuf time we could then compare these two seqnos and > > decide whether a invalidate is still needed. > >=20 > > I haven't implemented this because > > - I don't have the hw that would benefit the most (i965). > > - On different hw, I don't think we'll gain much. At least as long as > > multi-client drm usage is still uncommon. > > - Currently we still have easier targets for faster performance ;) >=20 > OK. Seems like a fair assessment of the situation. Applied to -next. Actually, having just noticed the "reject user write domains other than RENDER." That will break 965 occlusion queries. I've gone back and removed this patch from my -next tree. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkvkfckACgkQHUdvYGzw6vcRvwCfXHuz8G2mFsRMiw19lny6RFD1 dOkAn0xjnk+CrbJILLMaqeVeMBGytxkQ =tlV4 -----END PGP SIGNATURE----- --=-=-=-- --===============0179293315== 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 --===============0179293315==--