Lets take a simple application, called qgears2, based on David Reveman cairogears and see how it performs with different rendering backends. Pay attention to zero relation to llamas or any other animals. The application takes a few options, -image: to render using a CPU based raster engine, -render: to render using X11's Xrender and -gl to render using OpenGL (-llama option is not accepted). It has three basic tests, "GEARSFANCY" which renders a few basic paths with a linear gradient alpha blended on top, TEXT that tests some very simple text rendering and COMPO which is just compostion and scaling of images.
The numbers come from two different machines. One is my laptop which is running Xorg server version 1.4.2. Exa is 2.2.0. Intel driver 2.3.2. GPU is 965GM, CPU is T8300 at 2.4GHz running on Debian Unstable's kernel 2.6.26-1.
The second machine is running GeForce 6600 (NV43 rev a2), NVIDIA proprietary driver version G01-173.14.09, Xorg version 7.3, kernel 2.6.25.11, CPU is Q6600 @ 2.40GHz (thanks to Kevin Ottens for those numbers, as I don't have NVIDIA machine at the moment).
The results for each test are as follows:
| I965 | NVIDIA | |
|---|---|---|
| Xrender | 35.37 | 44.743 |
| Raster | 63.41 | 41.999 |
| OpenGL | 131.41 | 156.250 |
| I965 | NVIDIA | |
|---|---|---|
| Xrender | 13.389 | 40.683 |
| Raster | (incorrect results) | (incorrect results) |
| OpenGL | 36.496 | 202.840 |
| I965 | NVIDIA | |
|---|---|---|
| Xrender | 67.751 | 66.313 |
| Raster | 81.833 | 70.472 |
| OpenGL | 411.523 | 436.681 |
COMPO test isn't really fair because as I mentioned Qt doesn't use server side picture transformations with Xrender but it shows that OpenGL is certainly not slow at it.
So what these results show is that GL backend, which hasn't been optimized at all, is between 2 to 6 times faster than anything out there and that pure CPU based Raster engine is faster than the Xrender engine.
So if you're on an Intel GPU, or NVIDIA GPU rendering using GL will immediately make your application a number times faster. If you're running on a system with no capable GPU then using raster engine will make your application faster as well.
Switching Qt to use GL backend by default would result in all applications running a magnitude times faster. The quality would suffer though (unless HighQualityAntialiasing mode would be used in Qt in which case it would be the same). This certainly would fix our graphics performance woes and as a side-effect allow using GL shaders right on the widgets for some nifty effects.
On systems with no GPU raster engine is a great choice, on everything else GL is clearly the best option.
23 comments:
hm qt 4.5 with ogl-rendering by default? awesome! :)
It is the social mission of the Xserver that Linux exclusively use 2D graphics until it is certified that every child in the third world has 3D hardware. Otherwise apps might get written than depend on fast graphics which would then deny this group use of those applications.
Your performance observations have been true for over five years.
My motto is to avoid OpenGL whenever possible if your target is Linux. There are still way too many cards that have either no concept of OpenGL support, or pretend to support it but crash hard when you actually try.
@Anonymous: "The performance observations have been true for over five years" is pushing it a bit, partially due to Qt not being able to render with GL back then at all...
@leo_s: I appreciate the fact that you haven't posted as anonymous. Unfortunately that doesn't change the fact that your motto is outright ridicules. What are the many cards that have no concept of OpenGL? It's not Intel, NVIDIA, AMD or VIA, so unless you're developing for Atari then that's wrong. And the whole "crash hard" argument is obviously bogus because it's not you who's gonna be writing/testing the code but guys at Trolltech and they'll make sure it works.
Oh, and on top of that if you have problems with our OpenGL support the solution is to fix it not avoid it.
Well, sorry for not being polite, but xrender really sucks doesn't it?
Xrender wasn't supposed to be at least better than Raster?
what do one have to do to switch his system to opengl rendering?
what prevents distributions from picking this up? (at least as non-default option)
i really hate how qt4 performs on linux comparing to windows
I have an ATI card (xpress 200m), which is the only brand you didn't test here, and enabling opengl in kde's system settings gets a totally-corrupted-non-usable screen, even though drivers are correctly installend and configured (and I'm not the only one having those issues).
fgl_glxgears shows good performance and opengl games run fine most of the time.
Do you think this situation is going to change soon?
Thanks.
ps: i tested it on both kde 4.1 and recent svn revisions.
@anonymous: Eventually every third-world country IS going to have 3D graphics.
@Zack: I used to use a Trident card w/o GL...
@nick shaforostoff: http://labs.trolltech.com/blogs/2008/06/27/accelerate-your-widgets-with-opengl/ The only thing I worry about is that QtOpenGL is currently a separate Qt module.
I'm very disgusted that XRENDER is slower than CPU rendering. Would it be possible to develop a GL-based XRENDER implementation?
R300 got RENDER acceleration recently. I believe a lot of the EXA acceleration for those cards and later makes use of DRI from the X server. If DRI is disabled, you get a noticeable slowdown in 2d performance. A recent bug I found with moving translucent windows above a certain size shows the reality quite clearly: the CPU usage never goes above 50%, but it is almost all in the kernel -- with the DRM.
We're can i buy llamas ?
@Massimiliano Torromeo: I have an ATI card (radeon x1600 series) I used to have the issues you have before.
But now with catalyst 8.5 everything runs smoothly I dont have any problem at all. 8.6 or 8.7 dont work well.
I just noticed that 8.8 is released yesterday, probably I will test it tonight.
This may be nonsense, but would it be possible to add on option for kde (or just plasma), to enable this opengl llama backend ?
Maybe this is already done when kwin is accelerated, I don't know.
It sounds nice, but it's probably a bad idea for laptops and other devices for which power consumption is important, isn't it ?
It's probably best for Qt to not use the xrender server-side transformations since most drivers don't support them. If a transformation is not supported then because of the way xrender is designed, it will be much slower than doing the transformation in software and then doing just the final composite/blend in hardware.
Hi Zack, nice app. I was trying to solve some 2D performance issues with my nvidia card that were affecting QEdje and used QGears2 to track my progress. Just to add one more entry to your results base.
2.4GHz Core 2 Duo / 2gb / nVidiaGeForce 8600M 256mb MacBook Pro
Xorg-server 1.4.2
Xorg 7.3
nvidia-drivers 177.67 (beta)
Running FANCYGEARS test
image –> 67 fps
render –> 41 fps
gl –> 476 fps
More on this post:
http://blog.eduardofleury.com/archives/2008/08/34/
Cheers,
Fleury
I'd like to point that the simplest case (from xrender pov), the COMPO case, is being software rendered. And it's not even trying to do acceleration (i profiled it and compared it with composite fallback data). So you're just comparing two different software renderers. Why this happens i do not know.
All the other things use some form of rasterisation and stuff like that, but again, the blending stage is not hw accelerated. So it's again a comparison of two software renderers (mostly qt functions).
I just wanted to point out that you shouldn't blame xrender completely here, because qt seems to be bypassing it.
@Maarten Maathuis: "COMPO test isn't really fair because as I mentioned Qt doesn't use server side picture transformations with Xrender but it shows that OpenGL is certainly not slow at it."
It's almost as if you'd read the post, it would be there? Neat, eh?
Zack, I was reading about the glucose work that was supposed to accelerate X (to speedup XRender???), but politics seems to prevail. I know it is not directly related to this post, but do please post on whatever happened to that nice idea!
why opengl, why not directx or opengl|es?
thanks to your benchmark I finally see the reason for qt4+nvidia8800 being a pain in the ass
the TEXT benchmark with render option gives me about 3fps
now I installed the beta driver 177.70 and after enabling glyph cache option I got ~70fps
now all my beloved qt4 applications are finally usable!
> why opengl, why not directx or opengl|es?
Why not DirectX? It doesn't work on all, or even the majority of, the platforms Qt supports. OpenGL works on most, or all, of them.
Oh, and on top of that if you have problems with our OpenGL support the solution is to fix it not avoid it.
I have rewritten fancy gears in Java2D: http://trac-hg.assembla.com/jgears/wiki
Results of comparison: Java2D 6.10 with direct3d pipeline is slower then Qt pure software rendering!
Post a Comment