Tearing problem at bigger overlay sizes

Michel Dänzer michel at daenzer.net
Wed Jan 14 08:47:58 PST 2009


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


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer


More information about the xorg-driver-ati mailing list