Re: [PATCH] Workaround for flicker with panning on the i830

[Thomas Richter <thor@math.tu-berlin.de>]

On 12.11.2013 18:22, Daniel Vetter wrote:

Thanks for the explanation how the fifos work, that was helpful.


> Yeah, I've meant BEND = max and AEND split so that the two resulting sizes
> are proportional to the pixel clock (i.e. both pipes should take equal
> amount of time roughly to go through the full fifo). Indeed really strang
> that this doesn't seem to work.
>
> Looking at docs I don't see any mention of a w/a :(

Too bad. I tried to find some systematic in the settings where I do get 
flicker and where not, in specific which settings of AEND create the 
problem. However, it's more complicated than I thought. It not only 
depends on the current scroll position, but also on the history (!) of 
what you did before. It's probably the relative fill position of the 
FIFOs that plays the role here. If the fifo was relatively full before 
starting the scroll, everything remains fine. Otherwise, it runs dry too 
soon. If you keep the history consistent, the outcome is consistent, but 
otherwise results are hard to predict.

Maybe the whole approach of adjusting the start address of the DMA 
engine to realize scrolling is not quite right, and the engine prefers 
to have data aligned to 64 byte boundaries or something like this. Is 
there some other way to delay the output of the FIFO into the pipe? Some 
very antique systems (ehem, like the Atari 800 or Amiga chipsets ;-) had 
"horizontal scroll registers" that realized a pixel delay for an 
otherwise byte-oriented pipeline.

Is there something like this in the i830 such that the actual start 
address of the DMA engine would remain constant, but the pipeline would 
refer or disregard the first n elements? This would avoid the whole problem.

The trouble is not only cosmetical (the flicker): If that happens, any 
application that uses an X video overlay misbehaives (xine crashes the 
system really badly) so the pipe-A underrun should be avoided at all costs.

Concerning the intel gpu tools: Currently, they just brute-force "poke" 
into the display registers. Is there some way to synchronize this 
activity to vblank from user space (I got their sources, so modifying 
them would work, but I would need some kind of mechanism to wait for 
vblank to do that savely).

> The only (totally crazy) idea I have is that the fifo falls over if it
> fetches accross a tile/page boundary. But no idea how to figure out a
> formula that'd work everywhere ...

Exactly. Might be possible, given that I have a relatively easy fix for 
sequential, but not for tiled. If I may add another question: How 
exactly does the tiled access then work? As far as I understand, the 
video RAM is still organized linearly, but the DMA engine fetches data 
differently? Is this right? How exactly are the tiles laid out, and how 
does memory fetches then work?

> To simplify things I'd start with just just one pipe display to VGA and
> then going through different resolutions and different offset. Maybe
> there's a pattern in the display fifo lenghts that work.

See above. Nope. Or rather "to some extend", but it's more complicated 
than that.

I wonder how that works in windows, though. The intel driver does 
support panning to some degree, at least if the resolutions of the 
internal and external display differ.

> Happy hacking!

I'm certainly having fun here. (-:

Greetings,
	Thomas