New acceleration architecture
Alan Cox
alan at lxorguk.ukuu.org.uk
Mon Jun 27 04:35:20 PDT 2005
On Llu, 2005-06-27 at 08:11, Zack Rusin wrote:
> Not that I'm doubting the greatness of xtank but I do find tailoring of an
> acceleration architecture for the needs of corner cases a little weird. Sure
The original X server line drawing optimisation was done for xtank back
in the 1980's - so its not that weird.
> we could add primitives for lines, rectangles, triangles and so on but at
> some point we have to draw the line and say "alright, that's enough". The
Well rectangles and triangles map directly onto render operations for
most cases and I guess lines too ?
> > 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.
>
> Yes it does, but it's explicitely tailored for XRender.
Fair enough
> for you anyway. On all desktop video hardware released after 2000 I would
> recommend using the 3D engine which idÌ . `Ì .. eÌ èCVS eÌ . dÌ .. fÌ
Repository dË ÔEntries `Ë Ä Entries.Log dË °Entries.Backup iÌ . `Ì .. jÌ èCVS jÌ . iÌ .. kÌ
Repository hË ÔEntries `Ë Ä Entries.Log hË °Entries.Backup at I'm doubting the greatness of xtank but I do find tailoring of
> > > > an acceleration architecture for the needs of corner cases a little
> > > > weird. Sure
> > >
> > > The original X server line drawing optimisation was done for xtank back
> > > in the 1980's - so its not that weird.
>
> And as a result, we have the horror that is cfb8line.c. Don't read that on a
> full stomach.
>
> > Will Xglx run on glide? Have you tried xtank on Xglx? If it is close
> > to working DaveR will probably fix it. It would be interesting to
> > compare if everything is working.
>
> Irrelevant. Core X lines have a pixel-precise spec. GL lines do not. If you
> implement X lines with GL lines you will not conform. Which means they'll be
> done in software in xgl, so they'll be roughly as fast as in kdrive and exa.
Huh? 0 width core X lines have a specification so wide that you can
drive a truck through it. Any thing that goes from one end to the other
qualifies; its problem is the spec is useless.
It is only wide lines that have a (broken) pixel precise specification,
that generates ugly results, and therefore wide lines are almost
entirely unused.
>
> The point here is that modern toolkit usage is >99% solid fills, blits, and
> blends. If your creaky X app isn't doing lines fast enough we can probably
> optimize fb's implementation a bit, but I would stop short of adding it to
> the acceleration API.
>
Optimizing 0 width lines might be worth while, but spending any effort
on wide lines is a waste of effort: spending time getting traps running
well for cairo is much more worthwhile, for wide lines generated that
way.
- Jim
More information about the xorg
mailing list