[Intel-gfx] Possible wrong flushes on SNB

Chris Wilson chris at chris-wilson.co.uk
Tue Oct 11 22:01:20 CEST 2011


On Tue, 11 Oct 2011 14:13:16 +0200, Lukas Hejtmanek <xhejtman at ics.muni.cz> wrote:
> Hi, 
> 
> I have SNB chip, with git driver 5913c90967091124e7c7b262782f0e99cf400eab,
> 3.1-rc9 kernel. I noticed that refresh of notification area or e.g., xosview
> refresh is linked with flashing. Looks like background exposing is synced with
> vertical refresh so it is visible and disturbing. 
> 
> This behaviour is more noticable at fresh start of system (after boot). If
> I run my desktop for several days, the problem disappears.
> 
> Is it something new? Or something interesting so I should create a bug on fdo?

If you are using SNA, the likely cause of the flash is the flush, read,
modify, write of a fallback. That is we flush pending operations in the
batchbuffer (likely a fill to the scanout), read back from the scanout
the just modified region and perform the fallback with the CPU. That
modification is then queued up to be written out sometime in the near
future. That delay between the fill and the final write can cause
flickering.

By contrast UXA performs its fallbacks inplace and so such flicker
should not be any more perceivable than any other drawing operation.

File a bug. If you are using SNA, I'd like to prevent the fallback and
so avoid the flicker. Or I may have misdiagnosed it entirely, so in any
case I want sufficient information to reproduce.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre



More information about the Intel-gfx mailing list