XRender acceleration
Zack Rusin
zrusin at trolltech.com
Thu Mar 16 11:48:17 PST 2006
Hey, [*1]
we're doing better and better at accelerating XRender. Muchas problemos that
we have on the toolkit level are caused by the fact that we (*2) have no idea
what is accelerated.
What happens right now is that both toolkit and driver developers pick, pretty
much at random, paths that they like. Unfortunately they often don't match
and we end up with a driver nicely accelerating operations that are never
used while toolkit neatly using operations that are not accelerated.
Not that playing guessing game isn't a whole lot of fun (we could have office
parties where people get candy for finding accelerated paths on driver x) but
how about if we make it a little bit more boring and add some more rigid
framework around XRender that defines those things.
For a while I thought about adding XRenderIsAccelerated call where you pass,
op, src, dst, mask and it checks whether the current op with the given
surfaces can be accelerated. This has two unfortunate sideeffects:
- there's a butt (*3) load of combinations. Not only ops but also alpha
handling, formats and filters matter and give us quite a lot of paths there.
- It doesn't make it any easier to figure out what operations are most likely
to be accelerated. It doesn't tell us what things the driver developer should
more likely implement to get a lot smoother desktop experience.
Right now I'm thinking that the best solution might be defining XRender
Level's. I just talked to Fredrik and basically the scheme I think would make
the most sense is this:
- Levels would group XRender functionality in a way that allows clearly naming
of them.
- It's mandatory that individual levels are defined _very_ strictly.
- Drivers advertise supported Levels. Desktop environments/toolkits define
levels they need for best experience. This way a driver developer can take a
toolkit/desktop environment and see what exactly is needed to make it work
and work fast. While toolkit/desktop developers look at levels and see what
are the bounds they need to be working within. This gives both group a clear
and finite set of operations they should be working with.
- Benchmarking application. It's a lot easier to check for "Level 1"
acceleration than to check "for everything that is used by toolkits/desktops
and accelerated by drivers".
So for example:
Level 1 would include only the core Porter&Duff operators. No filters. No
different ways of handling alpha. PictStandardARGB32 format. No
transformations.
Level 2 would for example add transformations.
Level 3 would for example add filters.
Level 4 component alpha. And so on.
...
Level X, where X is the last possible level defined - as set by whatever type
that holds them. Level X would mean that whole freaking current XRender
version is accelerated and I get cookies [*4].
Now before I actually go and do that (define levels, write them up, add level
check call to render, change drivers and write the test app) I'd like to hear
opinions about this. Does anyone see a better solution of figuring out what
is accelerated (from the toolkit side) and what should be accelerated (from
the driver developers side)? Comments? Opinions? Beauty tips [*5]?
[1] Platonic greeting.
[2] As an exercise for your intelligence I'm using "we" interchangeably with
respect to both "toolkit" and "X" developers since I'm a questionably proud
member of both.
[3] For very large butts.
[4] Don't judge me, I like cookies.
[5] Not that I need any since I'm absolutely gorgeous.
More information about the xorg
mailing list