Better gradient handling (migration/fallbacks)
eric at anholt.net
Thu Nov 13 11:16:15 PST 2008
On Thu, 2008-11-13 at 14:30 +0100, Clemens Eisserer wrote:
> I've experienced some performance problems with gradients when working
> on the xrender/java2d backend.
> A typical problematic case is when mask and desitation picture were in
> VRAM, and a gradient is used as source.
> As far as I understand this causes mask and dst to be moved out into
> sysmem, the composition is done by pixman and at the next accalerated
> operation the whole thing is moved back.
> In profiles I saw that about 35% of total cycles where spent in
> moveIn/moveOut and 5% in gradient generation itself, for a rather
> boring UI like the following:
> What I did to work arround the problem was to use a temporary pixmap,
> copy the gradient to the pixmap and use that pixpap later for
> This means only moveIn's and enhanced performance a lot, about 3-4x
> for the UI workload mentioned above.
> This seems to be an acceptable workarround but causes an unnescessary
> burden for UMA architectures like Intel+GEM, so doing this be default
> should be up to the driver.
> Would it be possible to pass gradients down to the driver, to allow
> the driver to decide what to do with the gradient, or even provide
> accaleration for it.
> How complex would it be to provide the nescessary hooks?
> As far as I know two-stop gradients often can be accalerated with some
> texture-mapping tricks, and everything more complex still could be
> done with shaders.
> I am no xorg/exa expert, so maybe I just do not understand things and
> draw wrong conclusions.
We just need to accelerate gradients, and is where any effort in
software should occur. It's on our schedule, but not for quite a while.
Setting up the X Server to allow drivers to request gradients was easy
last time I did it, though I've misplaced the branch it looks like.
Then someone would just have to write the shader for it, and for
915-class hardware that shouldn't be hard.
eric at anholt.net eric.anholt at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part
More information about the xorg