New acceleration architecture

Alan Cox alan at
Sun Jun 26 10:44:17 PDT 2005

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)

I assume btw you have a tile cache and block invalidation map/tree so
that you don't generate unneccessary tile fetches, otherwise its going
to suck rocks on low end systems and damage overall system throughput
not just graphics performance.

> I want to make sure the following things are very clear:
> 1) Exa can coexist with XAA. You can keep code for both in your driver.

Are both used together (eg XAA for lines, exa for other stuff. I'm
assuming not

> 3) As everyone can see adding Exa support to a driver which already has 
> XAA support is trivial. 

Does the base exa include an exa->xaa translator for basic operations on
older cards or is it just not practical ?

> 4) Following the 7 steps I outlined above will speed up the common 
> desktop usage by quite a bit. Note that you don't have to be a driver 

You've measured this with one atypical card on one bus (AGP) or done
analysis on hub based systems too ?

> 5) Implementing the download/upload/composite hooks will give us enough 
> power to have very fancy effects that will let us compete with 
> Microsoft/Apple desktops while we work on Xgl.

If you have DMA and a DRI interface to grab tiles, otherwise it's going
to hurt badly. It'll be better than now I'm sure but it'll merely "suck
less", unless there is a good tile cache.

> 6) The code as presented in the snapshot will be checked in on Monday 
> morning/Sunday night, dependently on the feedback I'm going to get.

I'm watching with interest. The Voodoo2 has hardware assist for software
compositing in 2D so this may help make better use of it. (Right now I
don't boot the 3D engine as thats horrendously complex to use).


More information about the xorg mailing list