24 February 2009

Comparison of KDE4 Graphics Performance on nVidia 8600GT and ATI HD3450

Five months ago I wrote a post about inadequate graphics performance of KDE4 and Qt4 applications on nVidia cards using the proprietary nVidia driver.

I was unhappy with the nVidia 8600GT performance and bought el cheapo ATI HD3450 card and was happy with how well it worked with KDE. But after I posted my KDE4 review I got several comments from people saying that nVidia fixed their driver. So I became curious and took my old 8600GT and tried it.

In short, the performance was indeed improved. But... I felt something is still wrong. In particular, text rendering was not fast enough. Konsole suffered from this the most. The problem was also visible in Kate (see my bugreport with callgrind profile if you're curious).

I decided to isolate the problematic code and try it with different drivers and cards to see what's going on. I wrote a simple program which renders one long line (16000 chars) on the screen several times and compared the rendering time (see the code).


I ran it on my desktop with ATI and nVidia cards and also on my EeePC. I have Qt 4.5 on the desktop and was able to try the new "Raster" graphics system in Qt which basically does all the drawing bypassing X11. Rumors are the "raster" system is faster.

Here are the numbers I got (smaller is better):
DriverX11Raster
ATI Radeon HD3450
fglrx 9.1 (proprieraty)918117
radeonhd768112
nVidia GeForce 8600GT
nvidia 180.29 (proprietary)1571113
nv895114
nouveau1699111
Integrated Intel GMA 950 on Asus EeePC
intel1029N/A


Immediate conclusions from that comparison are:
  • New raster graphics system from Qt 4.5 is 10x faster then usual Qt rendering code
  • Proprietary nVidia driver is still 1.5x slower than opensource 'nv' driver or any ATI driver
  • EeePC is so cool because Qt4/KDE4 renders text on it as fast as it does on more powerful graphics cards


Looking at these tests you might conclude that opensource nv and radeonhd drivers are the best. Yes, but only at rendering text. On my home computer I also want video and I wasn't able to use XV with any of the opensource drivers. With older cards XV may work, with mine it did not. Playing video through X11 was simply too slow so at this moment I'm forced to use proprietary driver. And exactly as five months ago, I choose ATI just because it's still faster.

I'm really looking forward distributions compiling Qt itself or Qt-based programs with Raster graphics system by default. Yes, it will make Qt/KDE applications slower on remote X sessions, but I'm ready to pay that penalty for the impressive 10x speedup in regular usage. For people who often use remove X, distributions may provide replacement Qt binaries compiled with X11 graphics system or provide a system-wide configuration.



ATI fglrx driver warnings and hints: Remember that video and 3d won't work with Composite. Also, X11 may freeze on shutdown. To avoid freezes, try these solutions one by one:
  • do not use 'evdev' driver for keyboard and mouse, use 'kbd' and 'mouse' drivers instead
  • stop atieventsd daemon
  • add 'Option "Composite" "off"' to xorg.conf to turn off Composite completely

18 comments:

Anonymous said...

does the raster qt version not run on intel gfx

Zack said...

Eh, why do people insist on doing this to me? You are NOT testing any graphics.

I have no clue what you're testing in this example.

That's assuming that it would actually compile. I'm guessing that the draw(&p, QPoint(0, 0)) was supposed to be m_layout->draw(...)...

Raster that a lot of its work, including the actual DISPLAY of the buffer in the ending of the painter. You output the results before the painter has ended...

And guess what, X is asynchronous, so there's no guarantee it will even start rendering before you call your t.elapsed.

The whole benchmark is WRONG and I find it irritating that is the X-th time that someone on planetkde with no idea how this stuff works posted another bogus benchmark.
The conclusion might even be correct (not the 10x one, that's bogus) but you're basing it on a completely wrong test.

At least pretend like you're trying to be objective and add
p.end(); and QApplication::syncX(); before the call to t.elapsed().

deabru said...

KDE slow in remote X sessions?

I think slow too with SPICE, nomad... and this is the way that redhad/novell choose for corporative desktop.

Anonymous said...

I fell for the siren call of ATI graphics and made the jump back in December. I picked up a nice radeon HD 46xx series card, which was great.

Except it wasn't. Sure, it was faster than my old NVidia based card. And when it worked, everything was fine. Except, more often than not, it didn't work. Hang on shutdown, X would occasionally not start, etc.

And since I want working 3D graphics, I had to use the fglrx drivers. And each month the newest Catalyst package would bring new fixes, and new breakages, culminating in a Catalyst 9.2 release which basically broke things to the point where X wouldn't start.

So, I ripped the card out in frustration and I spent 40 bucks on a NVidia 9400. It isn't as fast, but it works. And that's the difference with NVidia drivers. They just work.

To anyone else who's thinking of following the siren's call and picking up a ATI card, don't. It's nothing but unfulfilled potential at this point.

Anonymous said...

The open source ATI driver (radeonhd in my case) works fine for me, except without 3D. But at least it is extremely reliable and allows switching to text mode and back, unlike the proprietary nVidia driver.

Pau Garcia i Quiles said...

My experience is the exact opposite: the NVidia proprietary driver is faster than anything else ('nv', 'ati' and 'fglrx'). And let's not forget that neither ATI driver (open source or proprietary) support rotation of the second monitor, something that the NVidia driver was able to do even with my ancient GeForce 7300. That's what I miss the most in my ATI Radeon HD 2600 :-(

André Somers said...

Darn... If I read all this jabbering about videocards and KDE, maybe I need to stick with my old Matrox G400 after all! At least that one just works, even if it is about a zillion times slower than anything you'd be able to get in stores today...

Anonymous said...

typo: 10x faster then usual Qt rendering code

should be than

please just delete this comment after changing.

Alexey Sergeev said...

I run it few times on NVIDIA 9500 GT with 180.22 driver and Qt5 without raster and I got:
93
112
85
238
118
148
145
108

I think those 1.5 times faster is somewhere in +/- for this test.

SHAME FOR YOU!

Alexander Dymo said...

Anonymous: I have Qt4.4 on EeePC, therefore no raster engine test there

Zack: I agree that the benchmark is wrong, but only to a certain extent. When application calls draw(), it waits for the call to finish. I don't care how fast results appear on the screen and I don't care whether X actually rendered anything or not. I care that my application is stuck.

For example, Kate is slow on long dynamically wrapped lines exactly because draw() takes too much time.

I wouldn't post this 10x number if I couldn't feel it's true. You need to see how bad Konsole is on my computer with nvidia. And when I run konsole -graphicssystem raster, it becomes really fast. I'm sure I have 10x. I see that.

I'll try p.end() and syncX().


Alexei Sergeyev: I don't have this kind of deviation here. My Qt4.5/X11 numbers with nvidia are: 1654, 1550, 1516, 1557, 1635, etc... With raster numbers are: 118 107 108 108 108 108, etc...

Btw, Alexey, so you say you get 100-200 with nvidia driver without any raster graphics system? Do you perceive any slowdown in Konsole? How does Kate work with long wrapped lines for you?

I always suspected that the slowdown I get is specific to my card. At least the most woes on the internet go from 8600 owners. Therefore I always point its model in my blogs ;)

Alexander Dymo said...

Zack: p.end() didn't really make a difference. QApplication::syncX() adds more time for the test, but I start getting large deviation in results (from 1000 to 1300 on fglrx). I suspect this is because of asynchronous nature of X, right?

Anyway, I'm not testing here how fast the text appears on the screen, I'm testing how slow QTextLayout::draw function may be with different graphics cards and drivers.

Anonymous said...

would be better that you test NEW Nvidia 180.35 Driver:

http://www.phoronix.com/scan.php?page=news_item&px=NzA5MQ

Zack said...

"I'm testing how slow QTextLayout::draw function may be with different graphics cards and drivers."

Then this has nothing to do with graphics. Not even mentioning that both Qt's Raster engine and X11 use FreeType to draw glyphs. The difference is that X11 allows sharing of those glyphs with different apps. If you use Qt raster engine then that's not the case and every single app needs to cache them.
So again, whatever you're testing is a mystery. It's possible you see some bug in Qt, but because you only run the test once it's impossible to tell whether Qt is caching something on that run, whether it queries font metrics from the server on the first run or whatever the hell is doing. Either way it's a completely wrong test.

hdhoang said...

Using unreleased radeonhd and drm, you can have Xv: http://www.botchco.com/agd5f/?p=40

Alexander Dymo said...

Zack: Unfortunately, the problem is real (at least for me here). My test merely takes the code that Kate and Konsole uses and isolates it. So I don't think the test is mystery.

Maybe it's a bug somewhere in Qt, but why then rendering with ATI drivers is faster? Anyway, I'll have to do more profiling to know for sure where the bug is. Currently I tend to blame drivers.

Alexander Dymo said...

hdg: thanks for the hint, I'll try the new radeonhd!

Unknown said...

Thanks a lot for this kind of benchmark testing. Even though sometimes controversial, it surely brings the attention to certain weak points.

Alexey Sergeev said...

to Alexander Dymo:
I, actually, can't recall if it my Qt4.5 was build with raster or without, I will give you answer if you will tell me how to check it.

I should mention that either Qt works bad with XServer or X is slow, because raster gives such a boost.

More than that I could suppose that Qt have some "buggy"code in terms of preformance if it works slow.

Could you make this test on windows? It would be nice to see how faster/slower Qt on Windows is.