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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
