On Thu, Aug 15, 2013 at 08:08:12AM -0700, Chad Versace wrote: > On 08/14/2013 12:50 AM, Ville Syrjälä wrote: > > On Wed, Aug 14, 2013 at 10:45:23AM +0300, Ville Syrjälä wrote: > >> On Tue, Aug 13, 2013 at 05:46:55PM -0700, Chad Versace wrote: > >>> On 08/13/2013 03:31 PM, Vedran Rodic wrote: > >>>> On Mon, Aug 12, 2013 at 3:07 PM, <ville.syrj...@linux.intel.com> wrote: > >>>>> From: Ville Syrjälä <ville.syrj...@linux.intel.com> > > > >> For L3 cacheability, IVB won't consult the PTE for anything that has a > >> relevant MOCS field. So even if you make everything L3 cacheable through > >> the PTEs, MOCS will always override it. How do i know you ask? Well, > >> BSpec says so for one, and more importantly I verified this by running > >> some tests [...] > > > I suspected this. Thanks for sharing your experimental evidence. > > > >> For LLC cachebility the story will be different because there IVB MOCS > >> can only say "LLC cacheable" or "consult the PTE". So to make stuff > >> uncached in LLC on IVB, we'd need to issues the set_caching ioctl to > >> change the PTE to uncached, and after that we could use just the MOCS > >> to select the LLC caching policy. Since the set_caching ioctl only needs > >> to be issued once per object (or you could use the , there > > > > Sorry hit send by accident. Was going to say we could use the new > > create2 ioctl Chris has proposed that allows you to set the cache mode > > when creating the object. So there won't be a performance hit from > > extra ioctls getting issued all the time. > > > I would like such a cache-control ioctl, as long the ioctl can also > be used to change the object's cacheing policy in addition to > setting it at object creation. This would be > needed when an object's usage oscillates between texture surface > and render target.
We do have the set_caching ioctl. It's enough to flip the PTEs to UC and let MOCS manage things. I actually did a few experiments on my IVB. I made all Mesa's buffers UC via PTEs by patching libdrm to change the cache mode of each bo after allocation. Then I fiddled with the MOCS LLC bits in various ways. It definitely has an effect, sometimes making things slower, sometimes faster. xonotic again seemed to benefit. IIRC leaving everything LLC uncached was actually the fastest (w/ high quality at least) so we may be thrashing the LLC a bit there. But eg. reaction quake regressed quite a lot if most things were left as UC. I should probably run through a few MOCS combinations and collect a bit more data. But it's looking like some sensible heuristic has to be involved since different benchmarks show conflicting results. Maybe your LLC overcommit prevention approach would be the one. Are you planning to continue with that work? -- Ville Syrjälä Intel OTC _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
