Weekly Edition
Return to the Development page
| |||||||||||||
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter)
Fedora QA team member Will Woods looks at recent changes to add kernel modesetting to Fedora in a post on his blog. People were noticing a sizeable decrease in the frame rate of glxgears, believing that it was a good general measure of 3D performance. "[...] glxgears is rendering an insanely simple scene - so simple that the actual 3D rendering time is basically zero. So the only thing glxgears really tests is the performance of glXSwapBuffers() - basically, how fast we can push render buffers into the card. This operation is slower with DRI2, but - roughly speaking - unless it was an order of magnitude slower (e.g. glxgears drops from 1000FPS to under 100FPS) it wouldn't make any real difference." One of the tests he recommends for 3D performance is the always amusing Extreme TuxRacer.
(Log in to post comments)
glxgears needs updating Posted Mar 16, 2009 15:45 UTC (Mon) by epa (subscriber, #39769) [Link]
Clearly an update to glxgears is needed. 'glxgears --extreme' should render some kind of fractal Antikythera Mechanism in elaborate detail, so it remains a good bechmark.
glxgears needs updating Posted Mar 16, 2009 15:57 UTC (Mon) by Tomasu (subscriber, #39889) [Link]
Remains? It was never a good benchmark.
glxgears needs updating Posted Mar 16, 2009 16:00 UTC (Mon) by truggieri (guest, #11847) [Link]
True, but I'd be all in favor of an Antikythera benchmark.
glxgears needs updating Posted Mar 16, 2009 16:24 UTC (Mon) by nye (guest, #51576) [Link]
Not a good benchmark, but a useful diagnostic tool.
For example, the FPS in glxgears is increased by a factor of around 100, IIRC (some large and obvious difference anyway) when switching video drivers from nv to nvidia, so if that doesn't happen then there's something wrong.
Similarly, using kwin4's compositing causes a drastic performance hit (even for fullscreen applications, despite the claim that redirection is disabled for fullscreen applications), so glxgears provides a handy sanity check.
Whatever numbers are shown is unimportant, but the fact that certain configurations have a dramatic effect makes glxgears a useful tool, so I hope that will still be the case.
glxgears needs updating Posted Mar 16, 2009 16:55 UTC (Mon) by jordanb (guest, #45668) [Link]
I think the best way to verify that you're using nvidia drivers is to install ext4 and check if you're losing data.
glxgears needs updating Posted Mar 16, 2009 19:04 UTC (Mon) by larryr (guest, #4030) [Link]
mounted without using nodelalloc
glxgears needs updating Posted Mar 16, 2009 21:27 UTC (Mon) by man_ls (subscriber, #15091) [Link] Brilliant! The new LWN record in the category "lapse between bewilderment and mockery" is now 9 front page entries.
glxgears needs updating Posted Mar 17, 2009 6:47 UTC (Tue) by muwlgr (guest, #35359) [Link]
Moreover, now we have an article about ext4 with more than 205 comments (former record, http://lwn.net/Articles/252073/ , with a great gender&transgender flame).
glxgears needs updating Posted Mar 16, 2009 17:26 UTC (Mon) by rsidd (subscriber, #2582) [Link]
If "glxinfo" shows "direct rendering: Yes" then the 3D driver was enabled, otherwise it wasn't. glxgears will tell you nothing more than this. As for kwin4, I'm using it right now and have been using it for a while, with a recent nvidia driver; I see no performance hit (the older nvidia drivers did have some issues, though). If you do see a performance hit, I don't see how glxgears would help as a "diagnostic tool".
glxgears needs updating Posted Mar 16, 2009 20:11 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
New Mesa can do direct rendering in software.
glxgears needs updating Posted Mar 17, 2009 1:02 UTC (Tue) by drag (subscriber, #31333) [Link]
Ya and you can get acceleration through indirect rendering via AIGLX. :)
So I guess now you can have non-accelerated direct rendering and then accelerated indirect rendering. Its funny when old truisms are not true no more.
glxgears needs updating Posted Mar 17, 2009 11:21 UTC (Tue) by nye (guest, #51576) [Link]
I think you're rather missing the point by nitpicking the specific examples (and of course the nitpicks got their own nitpicks :P), but I'm curious about your compositing performance. Are you saying that you can run, say tuxracer or WoW with compositing enabled, and have the same performance as with it disabled? For me, enabling compositing takes things from reasonable to largely unplayable, in WoW at least (I don't use anything else which pushes the machine's graphics capabilities).
glxgears needs updating Posted Mar 16, 2009 19:16 UTC (Mon) by tzafrir (subscriber, #11501) [Link]
As already pointed out in the original post, 'extremetuxracer' is both more extreme and more fun.
extremetuxracer needs updating Posted Mar 18, 2009 15:23 UTC (Wed) by DeletedUser32991 ((unknown), #32991) [Link]
to extremetuzracer.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 16:39 UTC (Mon) by jwb (guest, #15467) [Link]
The fact that Fedora had an Intel graphics stack test day makes me want to burn and install it right now. Ubuntu just throws in whatever is the current Intel driver software at the beginning of the release cycle, without even the bare minimum of testing, and then stubbornly refuses to update or revert it, regardless of the performance regression. It looks to me like the Fedora folks are really doing it the right way.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 17:22 UTC (Mon) by drag (subscriber, #31333) [Link]
That sort of thing is why my choices in distros on my personal systems are either Fedora or Debian. Might as well has a real distinction between my choices.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 13:06 UTC (Tue) by tajyrink (subscriber, #2750) [Link]
FUD. Several updates are done during the development cycle (for example currently the latest stable release branch is used, which was released only some time ago), bugs are browsed through, patches are integrated from both Intel upstream by cherry-picking and system vendors for specific quirks which are then forwarded to upstream.
The only thing that is not done is blindly believing a newer driver would be better, ie. it needs proving and testing if the upcoming 2.7.0 intel driver would be a better choice for Xserver 1.6 + kernel 2.6.28 combination than the current 2.6 branch.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 18:17 UTC (Tue) by jwb (guest, #15467) [Link]
Right, the upgrade to a later revision is not done blindly after the development cycle is underway, but in the beginning the latest code is tossed in on faith. That asymmetry leads to a locking in of regressions if the upstream is behaving badly.
I test the very latest Ubuntu as a matter of principle, since testing and bug reporting is the main way I can contribute to Ubuntu, and I've suffered through some serious indignities with respect to the Intel graphics driver during the Jaunty cycle. The Intel 2.6.99.999999 driver that was uploaded when Jaunty started was a huge regression from 2.6.0 in Intrepid, in performance, stability, and features. The latest 2.7.1 is less bad, but it's still a regression from Intrepid. And, notably, the driver in Intrepid was a regression from the one in Hardy.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 18, 2009 0:39 UTC (Wed) by dbnichol (subscriber, #39622) [Link]
The massive advantage that Fedora has is that they employ at least three of the most important graphics developers. Having Dave Airlie, Kristian Høgsberg and Adam Jackson working on things is a lot different than installing a new version and pinging upstream when things go wrong.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 18:16 UTC (Mon) by jengelh (subscriber, #33263) [Link]
>unless it was an order of magnitude slower (e.g. glxgears drops from 1000FPS to under 100FPS) it wouldn't make any real difference
Even dropping just in half is a serious concern. What changed in DRI2 so that glxswapbuffers got slow?
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 20:55 UTC (Mon) by oak (subscriber, #2786) [Link]
> Even dropping just in half is a serious concern. What changed in DRI2 so
that glxswapbuffers got slow?
Maybe it started to vsync to avoid tearing?
(I.e. does things right instead of fast)
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 21:41 UTC (Mon) by dhess (guest, #7827) [Link]
Then wouldn't people be seeing 60fps (or whatever their display's refresh rate is) instead of 440fps?
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 1:06 UTC (Tue) by drag (subscriber, #31333) [Link]
Maybe it can be a multiple of 60, or even just so that it divides evenly at 60. I suppose there is no need to show every frame just as long as when you draw the image to the screen it's one full frame, but even then I would expect a slow down vs not having to give a darn at all.
It would be interesting to know why it's that much slower.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 4:03 UTC (Tue) by dhess (guest, #7827) [Link]
My question was rhetorical. vsync means the buffer swaps happen on refresh, so unless these testers have 440Hz monitors, the slowdown reported in the article isn't due to vsync being enabled.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 23:00 UTC (Mon) by njs (guest, #40338) [Link]
> Even dropping just in half is a serious concern
Why?
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 0:35 UTC (Tue) by russell (subscriber, #10458) [Link]
exactly!
Why did swapping become so much slower and when does swapping become the bottle neck taking time away from actual rendering.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 1:10 UTC (Tue) by drag (subscriber, #31333) [Link]
With GLXGears the rendering time is so f-ng quick that the only bottle neck is the swapping.
Hence it's a very lousy benchmark (except for swapping). No useful 3D application is going to be bumping up against the same limits as glxgears does.
Personally I have had better performance sometimes better with lower glxgears performance, but that is not usual (so hence why people still get misled by it).
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 3:40 UTC (Tue) by russell (subscriber, #10458) [Link]
so maybe you should re-read my previous comment.
Why is swapping taking such a hit. I'm curious, aren't you?
As for the bottleneck part, let's say the frame rate is all about swapping:
1000 fps = 1 millisecond allocated to swapping
If I was writing a 3D app and wanted 60 fps I would have to budget 2.3 msec out of 16.7 msec to swapping instead of 1.0 msec. That means less time to devote to the "useful 3D application" as you put it, about 8% less !!!
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 4:38 UTC (Tue) by drag (subscriber, #31333) [Link]
I said in a previous post that it would be interesting.
Personally I suspect that it has more to do with DRI2/UXA being activated then KMS , and the GEM memory management (unified scheme) is doing more work then the previous (3D specific) memory management scheme and/or the newer code paths are not as well optimized.
If the users updated the Intel and Mesa drivers to enable stable KMS support then they could of switched over to newer Intel drivers that use UXA by default; which requires DRI2; which requires GEM, etc.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 13:13 UTC (Tue) by nhippi (subscriber, #34640) [Link]
perhaps it's not that swapping takes longer than before, but the new infrastructure allows swapping to happen less often than before. As long as it still allows swapping more often than the screen refreshes, it's no problem.
Now I'm guilty of the pure anecdotal guessing forums are full of, but I'm too lazy to get KMS kernel and start oprofiling to get some systematic evidence...
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 20:06 UTC (Tue) by dfsmith (guest, #20302) [Link] Okay, so glxgears is not a useful machine to machine benchmark. But it's a very handy diagnostic. Run glxgears, and if it...
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 19:17 UTC (Mon) by ncm (subscriber, #165) [Link]
I don't seem to run anything that needs GL. If I had it, though, I might run Stellarium.
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 16, 2009 23:00 UTC (Mon) by ikm (subscriber, #493) [Link]
Oh my. Anyone benchmarked glxgears with KMS on ext4?
Why glxgears is slower with Kernel Modesetting (and why it doesn't matter) Posted Mar 17, 2009 14:37 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]
Since Fedora rawhide is already using Ext4 by default, you are already seeing it.
|
|||||||||||||