Developer's XRender performance report - 173.14.09 / GF6600

[Linuxhippy]

Hello,

I am currently developing a Java2D pipeline which uses XRender a lot, and here are my findings about XRender performance. Maybe this helps driver developers a bit to tune their drivers.

I am using:
- OpenSuse 10.3 Alpha 3
- NVidia 173.14.09
- Geforce 6600, 256MB vram

1.) Repeating a small picture (RepeatNormal) over large areas is horrible slow. My intel-945GM is able to fill a ~1000x700 area with a 10x10 picture with about ~100fps, on my GF6600 it takes 1s.

2.) Transformations (all or just a few) are not accalerated, which is a real problem for the software I am developing.

3.) Gradients are not accalerated.
They are also not accalerated with EXA, but it would be really helpful.
2-stop gradients can be implemented even withought shaders, linear and radial gradients could be done with shaders easily (Java's OpenGL backend does this already).

4.) per-composition overhead is extremly high, this hurts performance of my pipeline on nvidia hardware quite a lot. Its not uncommon for my pipeline to composite only a 10x10 area.

5.) X11-Lines are accalerated and really fast. I need them, so here nvidia definitivly has a performance advantage over EXA based drivers

lg Clemens

[AaronP]

Please attach your test case. We're working on a number of improvements for repeating and transformed source images for a future driver release. I filed an enhancement request a while ago for gradients, but it's unlikely that they'll be implemented very soon.

Zero-width lines are just about the fastest thing the GPU can do, aside from drawing the root weave.

[Plagman]

Accelerated support for all repeating modes and all transformations for Composite operations is implemented and will be available in a future driver release.

Per-composition overhead should be negligible for accelerated operations on accelerated Pictures. Make sure you're using InitialPixmapPlacement=2 and avoid creating Pictures in your inner loop. If you don't feel like you're doing anything wrong and are still bottlenecked, please write a standalone X test case and post it here.

[Linuxhippy]

Originally Posted by AaronP

Please attach your test case.

The pipeline is quite a lot of code itself integrated into even more code and I am quite busy for now. Once my deadline is over I will try to write test-cases for the other mentioned problems too.
Once its in a useful state I could send you a link along with a description howto try it out?

We're working on a number of improvements for repeating and transformed source images for a future driver release.

Good to know, thank you for working on this

I filed an enhancement request a while ago for gradients, but it's unlikely that they'll be implemented very soon.

Well I know its probably a lot of work, but I can only guess gradients will be used more and more.
Although its just a simple UI, gradients kill its performance completly: http://bp1.blogger.com/_Y_-jaz-4d00/...bus_better.png

Zero-width lines are just about the fastest thing the GPU can do, aside from drawing the root weave.

Sad that this is not implemented in EXA. Although I agree that with current GPUs its not worth to worry about complex geometry, the trapezoid approach is a bit to minimalistic for my taste (and also too slow ^^).
This is one of the reasons the pipeline performs very well on nvidia GPUs

Per-composition overhead should be negligible for accelerated operations on accelerated Pictures. Make sure you're using InitialPixmapPlacement=2 and avoid creating Pictures in your inner loop. If you don't feel like you're doing anything wrong and are still bottlenecked, please write a standalone X test case and post it here.

Well, I ran the test and it was really *fast* ... so I played a bit with the mask-size and found out that if the mask is smaller that arround 64x64 composition overhead is really high (maybe such small pixmaps are not migrated to vram?).
I attached the simple benchmark.

Thanks for your helpful comments, lg Clemens