New acceleration architecture

[Keith Packard]

On Sun, 2005-06-26 at 18:44 +0100, Alan Cox wrote:
> On Sad, 2005-06-25 at 17:20, Zack Rusin wrote:
> > I'll be here to respond to any questions. If there's anything you think 
> > is silly, I'll be more than happy to change it. 
> > 
> > I refuse to add acceleration hooks for low level primitives (e.g. 
> > lines). At this day and age it really just doesn't make any sense. 
> 
> That seems silly. There are several cases where angled lines are
> horrendous worst cases for screen fetch/screen put operations especially
> as Xorg generally doesn't have DMA screen tile fetch so your performance
> for a fetch is a joke. Vertical lines in software also cause tlb
> thrashing. So yes that one does matter as any xtank player would
> understand 8)

When I wrote the current fb software line code, I did some measurements
with a few graphics cards (S3, R128, Mach64) and discovered that 'short'
lines are faster in software because the cost of synchronizing with the
hardware is so high.

For these cards, 'short' was somewhere between 10 and 100 pixels.

Even for longer lines, the performance penalty was not that high; we're
doing pure writes over the AGP bus which is reasonably fast.  We should
do some more measurements on current hardware, but my recollection was
that software was within a factor of 3 of the hardware for even the
longest lines.

The cost of adding zero-width line code to the acceleration architecture
didn't appear worth the effort to me; most people have a hard time
discerning performance differences of less than a factor of 4.

If you have legacy code still drawing thousands of long zero-width
lines, you're welcome to use the older acceleration architecture, which
has the advantage of also accelerating important operations like polygon
fills and stipples.

For those interested in getting O(Xgl) performance instead of O(X)
performance, the new acceleration architecture offers some hope of doing
that in the near future while we work on pushing GL support underneath X
for this class of video cards.

-keith

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20050627/41759866/attachment.pgp>