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