Slashdot Mirror
Windows vs. Linux On 3D Performance
Linux Games have posted this article about Windows VS Linux on 3D performace. They tested Quake III with Matrox G400, NVidia GeForce 256 DDR, and 3DFX Voodoo 3 3000 -- all with their latest drivers (both Linux drivers and Windows drivers). There are some interesting results, and even a few surprises. What do you think about the results?
This makes the assumption that the X bashers know what they're talking about.
With DRI the 3d pipeline bypasses X. There is some resource usage by X for font/pixmap caches but it is negligible and wouldn't have caused the slowdowns seen here.
People just want a scapegoat and X happens to be the handiest thing to point a finger at. The real problem is that very few people understand X and even fewer people contribute to the XFree86 team.
There are people in XFree86 who are concerned with speed, and experiments done in the past have proven that XFree86 drives the cards as fast as they can possibly go. Performance problems are in most cases caused by lack of documentation about the cards acceleration features, not because X is getting in the way.
Remember, at it's heart XFree86 is an async-io synchronisation mechanism. Any windowing system needs a similar mechanism, be it locks or mutexes or message passing. Changing from one mechanism to another will not change performance, it simply moves the "bottleneck" somewhere else.
Not really - all the tested X drivers use direct-to-hardware rendering, same as Windows. If the apps were run through the X socket, you'd see linux at more like 5% of windows performance instead of 90% =).
That said, X is really showing its age. IMHO network transparency is neat but not necessary at all for 99.9% of users. I'm sick and tired of crappy, jittery 2D on linux - perhaps the solution is pure client-only rendering. Those that need apps over the net can use VNC.
I am surprised that this became a Linux vs Windows kind of thing. Windows is not even involved in this story. When a game developer writes on Windows, he would be stupid to use any more of Win32 than needed to create the window and delete the window. Most Windows games today are programmed in DirectX, which offers almost all the services needed by a game. Once one learns how to set up a windows and do some threads, almost everything else a game needs is done through calls to DirectX instead of OS calls. In addition to that, most games spend most of their time inside their own code anyway, so the OS has a negligible effect on performance, (assuming of course that the app has direct or near direct access to hardware). Som in reality the competition is Linux vs. DirectX. Quite an impressive showing on Linux's part, at least for now. DirectX (true to its name) has much less overhead that any OS ever could. I wonder, however, if this success is short-lived. Quake isn't exactly a service intensive game. Sound is pretty basic, as is input. They only thing that really matters in this case is the speed of 3D subsystem. Game, however, will eventually evolve, in particular using more sound. Some games (thief in particular) already do this. I really wonder if Linux can handle yet another subsystem that needs direct access to hardware. As 3D sound controllers become more complex (like Aureal's controllers) the OS will need a good way to get huge amounts of data and commands to the sound cards. In these types of games, Windows will keep trumping Linux. The main problem is that Linux doesn't have DirectX. In absense of that, it has no consistant API that pushes the OS out of the way and allows the game to take over the system. Take a look at the rest of the APIs. DirectSound, DirectInput, DirectDraw, and to some extent DirectPlay (for its flexibility) whoops anything availible on Linux. (Any Linux driver-hardware combo that allows 32 HW accelerated 3D sound streams in addition to 96 normal streams? Windows had that in the A3D 2.0 days.) What Linux really needs at this point is a DRI for the rest of the sub systems. Only then, will Linux become better than Windows for games. Some will say the current situation is enough. Linux is almost as good as windows, it performs almost as well. Almost will not cause anybody to switch, however. If Linux really is a technically superior system, it should be able to trounce windows, not merely equal it.
A deep unwavering belief is a sure sign you're missing something...
It's all X's fault. That said, having a networked client/server GUI beats the shit out of a single-user, single desktop GUI anytime.
It's a shame you can't mod and post in the same story; I'd like to be able to both negate the "insightful" rating and explain why it's BS.
Take a look at the drivers they used. Not a one of them sends data over the X pipe. The X server basically is there to say, "yeah, you can bang directly on the hardware" and then get out of the way.
If they were sending data over the X pipe, you'd definitely know it. 3D hardware acceleration is often bandwidth limited; you could get up to a 50% drop in framerate without direct rendering. Smart design would reduce this problem, but I still suspect you'd see 70% optimal framerate, max... and in the LinuxGames tests, 70% was the worst case, not the best.
What was the best case? 99% framerate. This suggests to me that it's not idle processes or the kernel hogging CPU, it's not any weirdness from X or kswapd... it's just that some drivers are better than others. And right now, it looks like Windows drivers are 5% to 40% better than Linux drivers. Frankly, since Windows sales are 500% to 40000% better than Linux sales, I'm not complaining about driver quality.
I am surprised to see the 3Dfx drivers do so poorly, though. Isn't anyone helping out Daryll Strauss now that we've got source code available?
But of course, just how much can you trust the benchmarks? They ran it on one game, using a particular configuration, for a specific kernel.
Well, aside from the usual difficulties, there was one special case; the Matrox testing was done using full OpenGL drivers under Linux and a specific Quake 3 "TurboGL" driver under Windows; TurboGL drivers are Matrox's OpenGL subsets designed to run one game per DLL. In fact, the TurboGL driver postdates the Linux Mesa drivers; at one time (and probably still) the Linux implementation was significantly faster than the full Matrox OpenGL.
"As Linux grows because of its capabilities in other areas and its openness, it will gain market share, and the disparity between the two will decrease."
- 6.html
So if things were different they wouldn't be the same. Go figure. & Linux will improve over time. Oh my gosh, what a revelation.
You're saying that this isn't a comparison of the OS. I think the article was pretty straight forward in saying that it was just comparing Windows vs. Linux 3D Performance in Q3A. Do we really need to give Linux a hug and say "Don't worry that doesn't really matter because it will get better in the future." and make excuses every time someone points out a short coming?
Linux comes up short when comparing Windows vs. Linux 3D Performance in Q3A. Accept it and help provide suggestions in improving things or move on. Excuses doesn't make Linux any better.
I don't mean to be hyper critical here. I hear allot of "Well windows has lots of developers." or "Well windows has X or Y." and such statements when Linux comes up short in certain areas. In the end that doesn't help anything, in fact Linux does do poorly in these tests. I refer to the last line in the Linux Advocacy how to.
http://howto.tucows.com/LDP/HOWTO/mini/Advocacy
The Xfree-v4 DRI driver from 3dfx still goes through Glide. Check out this page at 3dfx. You need the new Glide installed before you can install the DRI X-server.
The IIRC the 3.3.6 X-driver used DGA (and so was full screen only). As a result it is entirely possible that it should be as fast as the DRI solution, or faster if the DRI implementation is not yet as well optimised.
So I am quite prepared to believe that the DRI implementation could be *slower* than the older version at the moment.
Under Windows you're drivers can talk near directly to the hardware, and their are less layers of protection slowing things down. Under Linux, their are more layers of protection between the hardware and the drivers, not to mention things have to talk more directly to a windowing system like X.
This means that in general linux games, etc.. will be more stable than their Windows equivalents, and if they crash, again in general, your system should be able to survive. (Even if you have to telnet in and reboot.)
Here's where DRI and XFree 4.0 come in. With DRI a driver can talk much more directly to the hardware, and generally speed things up, and provide more features.
So in Windows you get a slight speed increase in drivers at the sacrifice of stability. Of course, anything dealing with hardware/drivers can cause complete system lockups, its just less likely in Windows than in Linux.
A better comparison would be either Linux to NT 4.0, or Linux with XFree 4.0 to Windows 2000.
As it stands, you can get a nice idea of the slowdown by the GeForce drivers, which are ownly slightly faster in Windows than in linux. Of other note, is that the drivers in Linux are not optimized for games, as the article brought out several times. It would be VERY interesting to see some Linux vs. NT/2000 benchmarks in workstation operations(cad/design/etc...)
------ 24.5% slashdot pure
Windows is still somewhat based on DOS, which never was too big on multitasking. Games completely take over your system,
This is so completely wrong, how the hell did it get modded up? Windows isn't based on dos any more then Linux is because of Dosemu and lodlin.com. The only reason the system boots in dos mode (in win9x) is for compatibility sake. In fact, this no longer happens in WinME.
And as far as taking over your system, it simply doesn't happen. The game can take over your screen with directX, and use a Realtime priority thread if it wants to hog the CPU, but it probably doesn't. This is no different then what happens in Linux. Win32 programs don't use DOS at all, that's why they run on NT and 2000, witch don't use DOS code at all.
Is it so hard for people to know what they're talking about before doing so?
ReadThe ReflectionEngine, a cyberpunk style n
Unfortunately this study didn't really reflect the real and significant performance differences between OS 3D support.
An ostensibly fill limited benchmark will not reveal any disparity beyond state issues in the hardware. The geometry performance is not going to be significantly different in a software implementation of T&L provided there is at least a moderate effort by the vendor to support instruction sets like SSE or 3DNow on Linux.
What will be really telling in future is the difference between dispatch mechanisms & kernel level support for graphics when we get some heavy duty T&L support and a benchmark which exercises it. This will become significant for many games and is already significant for 'serious' 3D applications.
You are simply not going to get anything near parity unless we can persuade Cox & Torvalds that 3D is important enough to distribute the kinds of kernel hacks needed for efficient 3D support. Right now they are intransigent and have even lambasted 3D experts like Jon Leech in public over kernel support issues. In addition we'll need to remain flexible about driver implementation frameworks we want to support. Something like the DRI is OK now but when you need to send 15 million triangles a second to the graphics card it's not going to cut it.
Unfortunately Linux currently does not give anything near parity with hardware T&L. Even with an excellent driver implementation and the best will in the world it cannot and it may not for some time to come.
--
Let's not all suck at the same time please
Let's not all suck at the same time please
As Linux grows because of its capabilities in other areas and its openness, it will gain market share, and the disparity between the two will decrease. Just give it time
---
This sig has been temporarily disconnected or is no longer in service