From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Anholt Subject: Re: [PATCH 4/6] drm/i915: Add an interface to dynamically change the cache level Date: Wed, 30 Mar 2011 14:45:11 -0700 Message-ID: <87aagcb7vc.fsf@pollan.anholt.net> References: <1301443195-10721-1-git-send-email-eric@anholt.net> <1301443195-10721-5-git-send-email-eric@anholt.net> <87wrjg4k8k.fsf@pollan.anholt.net> <849307$c839fg@azsmga001.ch.intel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1399072054==" Return-path: In-Reply-To: <849307$c839fg@azsmga001.ch.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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: Chris Wilson , intel-gfx@lists.freedesktop.org List-Id: intel-gfx@lists.freedesktop.org --===============1399072054== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, 30 Mar 2011 18:16:11 +0100, Chris Wilson = wrote: > On Wed, 30 Mar 2011 09:59:55 -0700, Eric Anholt wrote: > > On Wed, 30 Mar 2011 08:09:47 +0100, Chris Wilson wrote: > > > The series looks really good, only one quibble below. > > >=20 > > > On Tue, 29 Mar 2011 16:59:53 -0700, Eric Anholt wro= te: > > > > +int i915_gem_object_set_cache_level(struct drm_i915_gem_object *ob= j, > > > > + enum i915_cache_level cache_level) > > > > + if (cache_level =3D=3D I915_CACHE_NONE) { > > > > + /* If we're coming frm LLC cached, then we haven't > > > > + * actually been tracking whether the data is in the > > > > + * CPU cache or not, since we only allow one bit set > > > > + * in obj->write_domain. Just set it to the CPU cache > > > > + * for now. > > > > + */ > > > > + BUG_ON(obj->base.write_domain & I915_GEM_GPU_DOMAINS); > > > > + obj->base.write_domain =3D I915_GEM_DOMAIN_CPU; > > > > + } > > >=20 > > > [We can rearrange the code to convert the BUG_ON into a > > > if (WARN_ON()) return -EBUSY;.] > > >=20 > > > I think this is overkill, at least by my interpretation of the old BLT > > > docs which imply that cache line invalidation (both CPU and GPU) is d= one > > > for snooped PTEs on MI_FLUSH. > >=20 > > And what about a CPU write through the GTT? >=20 > Even on SNB these are still UC. And we should try hard not to, as the > specs give dire warnings about writing to snooped PTEs through the GTT. > (Since we will bypass the caches with the write, aiui, and cause > confusion.) Oh, wow. That's really bad. Reject this series if so. If true, then we need to be accurately tracking the CPU write domain. Mapping for GTT would need to actually clflush, and we'd need to clflush to read GTT-written data. On the other hand, I'm surprised things survived the testing I've done if that's true, given that we're surely GTT pwriting the batchbuffer data in, and then reading them through LLC. I would expect to pull in a bunch of zeroes in place of actual commands. Were you perhaps referring to pre-gen6 chipsets? --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk2TpGcACgkQHUdvYGzw6vdmlACeNxGI1Zdk/o2s6BODToI5LUSq SlUAn1Bi6wVozxkNE0PVo2/nOhg3x4UI =qsQu -----END PGP SIGNATURE----- --=-=-=-- --===============1399072054== 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 --===============1399072054==--