XRender acceleration
Carsten Haitzler (The Rasterman)
raster at rasterman.com
Thu Mar 16 15:44:14 PST 2006
On Thu, 16 Mar 2006 14:48:17 -0500 Zack Rusin <zrusin at trolltech.com> babbled:
> 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".
sorry to sound a little negative - but just write a benchmarker that uses the ops your toolkit typically does and produces an ugly number at the end. then driver devs can have fun and games making that number get bigger :) i have had 1 benchmark around for many years as a first step to point out bad paths in xrender i at least needed and even compared them against equivalent pure-software routines (renderbench - google for it). this gives a good first level to "beat" - if a driver is doing sw fallbacks it should be within the same ballpark as renderbench for its sw routines - (within 50% lets say), and if going via accelerated paths - should be beating renderbench several times over at LEAST. it's a good first step - and if you use ops you are noticing are not accelerated a lot and are causing issues - make a benchmark for it and x devs can then use it as a tool to know what to tune.
> 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]?
i reckon as i said above - make a benchmarker that spews out 1 or more numbers for the ops you typically use/need. if you have a "target" to bench against (a client-side entirely software implementation - evas has this - as well as a pure opengl rendering implementation etc, and it ships with benchmark/test suites that give a good overall rating for its needs), then the driver developers have a target to aim for. :)
>
> [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.
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)
More information about the xorg
mailing list