[Intel-gfx] [PATCH] Workaround for flicker with panning on the i830

[Daniel Vetter]

On Wed, Nov 13, 2013 at 08:50:50PM +0100, Thomas Richter wrote:
> 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.

Hm, scrolling should be vsynced, and I'd expect the fifo to properly
refill in the vblank. So this is pretty astonishing. Could it be that
rendering activity affects this, or is this always with an otherwise
completely idle desktop?

> 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.

Nope, we don't have a buffer offset in pixels like on later generations.

> 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.

Yeah, the overlay is extremely fickle and if it's dead it'll never work
again until you reboot. And once it crashed all Xv apps won't work any
more :(

> 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 registers are vblank synced already. So if you poke both the dsparb
and the plane base register from userspace to fake scrolling you should
have as good a vsync as the kernel will get (if you script both register
writes together ofc).
> 
> >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?

Tile buffers aren't linear any more in memory. Tiles are 2kb in size and
are laid out in x-major direction. The tile itself is  128 bytes wide and
16 lines high. So presuming you start scanning out out at offset 0 the
dma-engine will read:

0 - 127, 2k - (2k+127), 4k - (4k+127), ... for the first display lane
128 - 255, (2k+128) - (2k+255), (4k+128) - (4k+255), ... for the 2nd display lane
...

> >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.

Could be that windows scrolls in software by copying the buffer around.
Maybe the tearfree option can help here, although I expect it to hurt
badly for gtt constrained i830M platforms. And tbh I don't know whether it
works with panning.

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch