XRender acceleration

[Carsten Haitzler (The Rasterman)]

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 (東京 日本)