Possible wrong flushes on SNB

Possible wrong flushes on SNB

[Lukas Hejtmanek]

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?

-- 
Lukáš Hejtmánek

Re: Possible wrong flushes on SNB

[Chris Wilson]

On Tue, 11 Oct 2011 14:13:16 +0200, Lukas Hejtmanek <xhejtman@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

Re: Possible wrong flushes on SNB

[Lukas Hejtmanek]

Chris,

On Tue, Oct 11, 2011 at 09:01:20PM +0100, Chris Wilson wrote:
> 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.

I did: #41718 

-- 
Lukáš Hejtmánek