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

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

On 13.11.2013 21:20, Daniel Vetter wrote:

Thanks Daniel for your explanations. As always, very helpful.

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

Hmm, then there is something I don't quite understand. If I check the 
code for the plane buffer start address computation, I do indeed see 
something like tile addressing for GEN4 and up, but for GEN2, I simply 
see a linear address = x + y * stride. This does not look consistent:

/* snip : code from i9xx_update_plane() in i915_display.c */

         linear_offset = y * fb->pitches[0] + x * (fb->bits_per_pixel / 8);

         if (INTEL_INFO(dev)->gen >= 4) {
                 intel_crtc->dspaddr_offset =
                         intel_gen4_compute_page_offset(&x, &y, 
obj->tiling_mode,
 
fb->bits_per_pixel / 8,
                                                        fb->pitches[0]);
                 linear_offset -= intel_crtc->dspaddr_offset;
         } else {
                 intel_crtc->dspaddr_offset = linear_offset;
         }

/* snip */

Are you *really sure* GEN2 does have tiling? Or could it be that this 
bit is used for something else and probably turns on some weird 
powersaving feature that creates some mischief with the FIFO? After all, 
a tile cannot always be 128 pixels long independent of the display 
organization (i.e. "pixel format") *and* have the above formula correct?

There is then at least something I must be missing.

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

Actually, scrolling is quite smooth, I doubt it's a software scrolling. 
But anyhow...

Greetings,
	Thomas