[Intel-gfx] [PATCH] drm/i915: Track dirtying of CPU cache for LLC
Daniel Vetter
daniel at ffwll.ch
Mon Feb 27 18:50:33 CET 2012
On Mon, Feb 27, 2012 at 05:10:24PM +0000, Chris Wilson wrote:
> On Mon, 27 Feb 2012 17:30:19 +0100, Daniel Vetter <daniel at ffwll.ch> wrote:
> > On Fri, Feb 24, 2012 at 09:21:51PM +0000, Chris Wilson wrote:
> > > Doing mixed rendering into the front/back scanout buffers lead to the
> > > interesting rediscovery of clflushing when page-flipping. A painful
> > > experience indeed.
> > >
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >
> > Hm, I might be a bit dense here (again ...) but I don't follow what this
> > exactly fixes. Care to elaborate a bit?
>
> When we are page-flipping, we take an active render buffer and flush it
> to the display plane. This involves a migration into the uncached
> domain and a clflush. If we allow the bo to transistion back to LLC
> cached for fast rendering when it becomes the back-buffer again, we
> incur another clflush back into the display place, even though we never
> touch it with the CPU whilst it is in the CPU domain. Similarly, if we
> are recycling bo used else for render buffers to be page-flipped. The
> patch avoids the defensive clflush by recording when we ignore transitions
> in and out of the CPU cache domain due to cache coherency and replaying
> those missed clflushes when the object is no longer cache coherent.
>
> The effect of the extra clflushes is quite pronounced (>30% framerate
> drop for glxgears) and really does interfere with experiments to manage
> cache levels. It's not the only bottleneck, but it is the major one.
Ah, so you're playing around and have fun ;-) I think I'll wait with
picking this up until you come up with the real deal ...
-Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the Intel-gfx
mailing list