Better gradient handling (migration/fallbacks)

[Eric Anholt]

On Thu, 2008-11-13 at 14:30 +0100, Clemens Eisserer wrote:
> Hi,
> 
> 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:
> http://picasaweb.google.com/linuxhippy/LinuxhippySBlog?authkey=tXfo8RSnq4s#5224085419010972994
> 
> 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
> composition.
> 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 Anholt
eric at anholt.net                         eric.anholt at intel.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20081113/a85f9a7f/attachment.pgp>