Tearing problem at bigger overlay sizes

[Xavier Bestel]

On Wed, 2009-01-14 at 18:47 +0200, Michel Dänzer wrote:
> On Wed, 2009-01-14 at 17:35 +0100, Xavier Bestel wrote:
> > On Tue, 2009-01-13 at 18:55 +0100, Matthias Hopf wrote:
> > > On Jan 13, 09 18:39:10 +0100, Xavier Bestel wrote:
> > > > > Because the chip might reorder memory writes, and decide for later
> > > > > blocks to be pushed out first (or even pushed out to memory w/o changing
> > > > > the cache). That way you *could* see multiple tearings.
> > > > 
> > > > I thought a cache flush acted like a barrier, i.e. even if reordered
> > > > between them all writes before the flush should go.
> > > 
> > > Yes, but the beam could already in the middle of the screen if you flush
> > > only at the end of all blocks.
> > 
> > That would mean the engine isn't way faster than the beam, which I
> > thought was doubtful but after seeing the fillrate¹ of an r300 seems
> > plausible: around 1 Gtex/s means an HD screen (1920*1080 = 2 Gpix) would
> > take 2s to draw ... 
> > I must have missed something, it looks way too slow.
> 
> Well for one, 1920 * 1080 is about two million pixels, not two
> billion. :)

Ahem *blushes* ... so we're down to .002s to draw an HD screen, 1/10th
of a frame at 50Hz. I don't know what's the duration of a vblank with an
LCD using reduced blanking, but it should fit in.

	Xav