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?

Comments

Linux must beat Windows...

[Scriven]

into the ground, before this'll make a splash.

As someone else stated, this proves why he stays with Windows. Even though it is very close, it's not there yet.

Now, this isn't a flame of the driver writers, because (as was also previously stated), the windows people have had years to fine-tune their drivers for games under Windows. But with Linux being such a superior OS (we all know it), it should CRUSH Windows. IMHO, only then will it make a difference, not even being equal will match, because then people will still stick with Windows, because that's what they know.

There has to be a reason for the switch, to the hard-core gaming crowd, that slightly higher FPS could be the reason. The next question is, what about for the rest of the world? Do we want everyone and their grandmother to use Linux?


This is my .sig. It isn't very big.

Re:How do apparent limitations of X-Windows impact

[nathanh]

Reading articles that have floated through Slashdot recently, it is apparent that X-Windows has some limitations to it's abilities.

This makes the assumption that the X bashers know what they're talking about.

Do these impact on 3D performance? And if they do is X-Windows always going to limit 3D performance?

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.

Optimize

[Jage]

Someone go out, profile, find the critical path in x86 Mesa code and optimize it by handwritten assembly (using MMX, 3DNow! and SSE). See if you can decrease branching factor, make better use of modern L1 and L2 caches or reduce memory loads altogether and preload data from memory before actually using it.

Granted, portability is gone after that, but it's performance that matters, eh?

Hey, don't look at me! :)

How Linux can get into the game market

[sterno]

One thing to keep in mind about Linux's future in the game market is that there is a great deal of overlap between the people who are already using Linux and people who are into gaming. The kind of people who will find ways to cool their overclocked chips to absolute zero are the same kind who like an O/S they can get into the guts of. Personally I've been considering the possibility of a Linux gaming machine. The major problem right now is the availability of games. On the bright side there is a rapidly growing supply of pretty decent free games.

---

Re:My conclusion

[captaineo]

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.

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.

Re:These Stats are Not Up to Date!

[wowbagger]

Sorry, but wrong. I follow the XF4 devel list, and have built XF4 from scratch. The Voodoo support under XF3.3x is also a Direct Rendering system: DR simply means that the 3D routines go directly to the hardware, not through the X system. In XF3.3x, running Mesa with the 3DFX drivers, as soon as you go full screen, the Mesa system goes directly to the hardware, bypassing X completely. Just like DRI under XF4.0

The differences between XF3.3x+Mesa+Glide and XF4.0+DRI are:

1. XF3.3 can only do hardware accelerated 3D in full screen, XF4 can do it in a window
2. XF3.3 can only support 1 client accessing the 3D hardware at a time, XF4 can allow multiple programs to access the hardware "at the same time" (actually, they switch the contexts, just like Linux switches contexts on the processor).

Re:How do apparent limitations of X-Windows impact

[nathanh]

Reading A New Rendering Model For X it appears, that without bashing X the feature set could be improved.

This I entirely agree with. The font handling in X11 is an absolute joke; a relic of ideas and limitations of the 80s which certainly shouldn't be holding us back these days.

It's a great thing Keith is working on making fonts better for XFree86. He is a very smart guy and if there's anyone that can fix the font mess in X, he's the one to do it.

But keep in mind that limitations in X are in almost all cases fixed through extensions. Good examples are XInput, or DGA, or GLX, or DPS. Not a single one of these features was planned for when X was written, but now you can seamlessly support all these features in your programs.

I'm particularly impressed with DPS which now gives XFree86 users the equivalent of Macintosh's QuickDraw. Print quality rendering on the desktop and at amazingly high speed too.

Or GLX which gives us an OpenGL implementation that is simultaneously a direct renderer (when it is possible), an indirect renderer (if you don't have permissions to directly access the hardware) and a network renderer (providing X's extremely useful network transparency), all automatically sorted out at runtime.

Or DGA which gives you direct access straight to the framebuffer, but with the benefit of still being able to use XAA for hardware accelerated blits and fills and the like. This makes DGA much better than SVGALIB for 2D graphics.

Keith may eventually produce something like an XFree86-Font extension, or XFree86-AntiAlias. It is an exciting time to be using XFree86. It's all getting better, and faster, and wonderful things are being done. It's always sad to see people who harp on the few bad things in X rather than look at all the great improvements that are being made and developed.

XFree86 problems can be solved, but not if you sit on your laurels and complain.

There's more to 3D than just games.

[plagiarist]

It would be nice to see more discussion of 3D performance under Linux in terms of 3D modeling/animation, rather than just games. The article mentioned the debate over whether gamers should bother to use Linux when Windows might serve them better; i.e. whether Linux is best left for servers. But, Linux is becoming a critical concern in the 3D animation field. Animators and animation houses have been moving away from SGI for the past few years, due to the expense of the SGI hardware as compared to Intel-based systems. But, that has so far meant, using Windows NT. All of the major packages (Maya, Softimage, 3D Studio, etc.) now have NT as their primary platform. (Though Maya, Soft, and others are still released for IRIX as well... SGI's aren't obsolete yet!)

However, people are becoming frustrated with NT, and longing for the stability/flexibility they had with their IRIX based systems. Major animation houses are now moving to Linux, at least for rendering. Maya has its renderer ported to Linux already, and houses that write their own software are porting to Linux also. (I've spoken to people from two major houses who said, "we're giving up on NT.") But, on the actual interactive end, where 3D performance counts, the major packages have not yet been ported, (though the houses may be porting their in-house packages.) So... much of the discussion of Linux for 3D animation users is, "Will, or when will, enough packages port to Linux so that we can use it instead of NT?" Also, "Will we have the level of OpenGL performance we need for these applications?" It's good to see the gaming article, because, attention to 3D that helps the gamers winds up helping the animators too, but I would like to see more articles addressing these aspects of 3D Linux performance.

Re:Which version?

[Chris Johnson]

People have been saying that since Windows 95. Why should we start believing you now? o_O

These Stats are Not Up to Date!

[MasteroftheVoxel]

Here's the deal...
XFree 4.0 which _has_ been released, supports DRI (Direct Rendering Infrastructure) which lets you have direct access to the graphics hardware giving a _big_ improvement over XFree 3.X's older archecture.

Now, it is still a bit of a pain to set up, and you can't run Quake or Quake II (only Quake III) under it, but it gives _awesome_ performance. Have they bothered to try this, they would have found Linux KICKS WINDOWS ASS.

Check 3dfx's linux website, source forge, and XFree for more info...

Windows is not even involved here.

[be-fan]

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.

Re:Windows is not even involved here.

[Raven667]

While I love the GUS as much as the next guy (I have two!) I am not aware of there being this level of support for Linux. Maybe in the ALSA drivers? Linux only has support for one program to have the sound device opened at a time, making those 32 channels go to waste, and I am not aware of an app that can take advantage of the onboard RAM for samples (except for XMP), even MIDI doesn't work (AFAIK you have to use TiMidity which is a software GUS emulator!!). The GUS has the most support with old DOS games and MOD players (the Windows driver was abandoned before DirectSound support could be added). Many moons ago I asked Gravis to opensource their drivers but they refused, probably some third party code or something.

You just haven't played Doom or System Shock if you haven't heard the crystal clear, hardware accelerated audio from a GUS. I keep an old (mid '80s) NEC 386-16 w/1.5MB RAM around to play MODs. It can play 8 channels of 44khz 16bit audio with waveform displays for each channel, crystal clear. Only now do mainstream cards offer multiple, hardware buffered, channels and downloadable samples that the GUS had 10 years ago.

Re:Windows is not even involved here.

[Temporal]

Linux's default sound driver allows direct access. mmap("dev/dsp"). There is no need for DirectX.

OK, imagine Windows is a thick forest. You are a programmer, and somewhere in this thick forest is your destination. There are several winding dirt pathways that you could take to get there, but you obviously can't go very fast on such pathways. So, the government of this forest (Microsoft) realizes that they need to improve the trasportation around here. So, they build a bunch of multi-lane super-highways that are perfectly stait and had no speed limit (DirectX). Now you can get where you need to go fast and efficiently. Everyone is happy.

What about Linux? Well, with Linux, there is no forest, and you don't have to go anywhere. You are already there.

Disclaimer: This basically applies to everything except for X. To fix the X problem, we have the new direct-rendering stuff. As you can see, nVidia's beta Linux drivers were able to almost match their Windows' couterparts' performance, so it is clearly quite possible for Linux to match Windows' speed. For everything non-graphical, Linux does not need a "DirectX" because it already gives you direct access to the hardware.

------

Re:Windows is not even involved here.

[be-fan]

DirectSound accelerators can push upwords of 96 channels to the hardware. It doesn't matter if the game will use all of it, what matters is that DirectSound does it BETTER than the equivilant under Linux.

Re:Windows is not even involved here.

[be-fan]

I knew about DGA, but it doesn't hold a candle to DDraw in terms of features. The big problem is that it is a bunch of disparate APIs, so extending it to include this nifty features is difficult. Take for example, the cool trick of rendering directly into a texture surface, drawing on it through a pointer to memory, than mapping it to a 3D object. Without a lot of reworking between DRI, DGA, and OpenGL, this will be impossible under Linux.

Re:Windows is not even involved here.

[be-fan]

Linux allows you to open /dev/dsp, but that precludes using advanced features present in saw ALSA or OpenAL or whatever.

Re:Windows is not even involved here.

[be-fan]

Quake 3 uses direct X for everything except 3D. Thus, Quake never actually makes very many Windows calls, most of its calls are to DirecX. Thus the game is actually running on DirectX, rather than Windows, which merely provides some window and process management code. This specific test may have sound turned off, but the battle between Linux and Windows definatly won't. (You play your games with sound off?) They talk of Linux becoming as good of a gaming experiance as Windows. Unless it gets something like DirectX, it won't.
PS: Repeat after me, SDL is not a full-fledged media system. It is merely a wrapper API for native high-performance APIs. Also, DirectX does not preclude OpenGL. It merely keeps you from using DirectDraw. In addition, SDL graphics functions don't work with OpenGL either. This is a big difference compared to D3D where you can render into a hardware buffer, directly write in it with DirectDraw, and use the whole thing as a source texture for some 3D object.

Re:Windows is not even involved here.

[be-fan]

I wasn't talking about the actual test. I was talking about the line where they say there will be a battle between Linux and windows over which is the best gaming experiance.

Re:Windows is not even involved here.

[be-fan]

Excuse me? Full easier than 3D video? Maybe in Linux, where the extent of 3D sound is multiple channels, but in windows you have cards that do occulsion, reflections, reverb, etc. For some parts of A3D 2.0, you even have to feed it your vertex data so it can calculate oculsions and what-not.

Re:Windows is not even involved here.

[be-fan]

You haven't used DirectX have you. It is direct access to hardware in a HARDWARE INDEPENDANT WAY. You can write perfectly portable software (between hardware, OSs, CPUs, and what-not) using an API that allows direct access to hardware.

Re:Windows is not even involved here.

[Frank T. Lofaro Jr.]

I disagree strongly that Linux needs to allow more direct access to hardware. Especially for sound, where there just isn't that much bandwidth needed. Let's face it, the human ear is only 2 channels 20 KHz resolution, maybe 80 db usable dynamic range (for the purposes of computer gems, etc. Don't want or need 100 db sound effects!). Even with multichannel sound though, it isn't a lot of data.

Most importantly, breaking the abstraction layer provided by the OS makes games and other applications dependant on actual hardware details. This is bad, this is going back to the bad old DOS days.

Secondly Linux is well written. Using its abstractions exacts at worst a near negligable speed penalty (unless your app is coded in a brain-dead manner, such as calling write() with one byte every time). Doing thing the right time is not going to slow things down enough to take away from the enjoyment of a game. Unless you really can tell the difference between 100 FPS and 99 FPS.

Re:Windows is not even involved here.

[drivers]

Quake 3 Arena doesn't used DirectX for graphics, it uses OpenGL. The article is basically testing the speed of drivers available for the the different 3D cards. Also, I didn't notice in the article any mention that they were using DRI which is available in Xfree86 4.0. They were using a standard Red Hat 6.2 setup.

Re:Windows is not even involved here.

[Menthos]

Game, however, will eventually evolve, in particular using more sound. Some games (thief in particular) already do this.

I think OpenAL might be the 3D sound device API/subsystem were waiting for.

Re:Windows is not even involved here.

[Anonymous Coward]

Er, this has nothing to do with DirectX.
Quake3 uses OpenGL for 3D video, so it's not a matter of Linux vs. DirectX.
As for sound, they turned that off.

Aureal is dead, btw.

There's SDL for Linux, which offers the same services (sans 3D) than DirectX does. Luckily it allows the use of OpenGL with it.

As for the operating system effecting the game, this is a matter of drivers, stacks, etc.
This is what they were comparing; the performance between drivers for these 3D cards.

The performance of 3D graphics has little to do with Linux's technical merit, given that it's not in the business of 3D graphics. As for the X servers, they're limited by technical information, and time. Given the time scale, the Utah GLX people have done an amazing job.

Wrong

[roystgnr]

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.

Re:Wrong

[(void*)]

Hey, I don't write video drivers, and I was just guessing. I can't control who mods me and who doesn't, and anyway, the moderation system is screwed. Thanks for your informative post though. I wish I had moderation points to distribute.

Re:Wrong

[slycer]

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?


I believe this answers your question.
Basically, no.

Re:Measure of Support not Performance - Excuses

[Duxup]

"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."

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- 6.html

Re:This benchmark was VERY poorly done..

[teraflop user]

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.

Defending my Honor.

[ca1v1n]

I would like to point out to the vindictive moderators and flamers that the article specifically talks about how it uses WINDOWS 98. Not NT. Not Win2k.

Many thanks to those who noticed this, and pointed out the details of the way windows works with DOS.

Thanks also to those who actually READ THE ARTICLE.

Just use both

[Fervent]

For those of us who aren't politically-minded, I say use both. What harm can it do?

I use Windows when I want to play games or do any real work (despite StarOffice's attempts, it's nowhere near Word). When I need to program in C++ or just browse the internet, I use Linux.

In addition, I'd love to know what version of Windows you guys are running. I've been running Windows 98 SE solidly for over 4 weeks, with no need to reboot. I like the concept of having a crashless operating system, but is it really required for the average user? I don't mind a crash here and there, if it affords me extra affordiability and solid support (MS's Technet section of their website is the most comprehensive I've seen by any software developer).

And to those who say "Well, Windows 98 SE rarely crashes because it's Windows 98 Second Edition, the latest in a long string of upgrades", all I have to say is: "What about Linux?" Doesn't anyone remember the almost hourly crashes of the first few point releases (it took 2 years to get anything close to stable).

Re:Multitasking methods...

[remande]

That all depends on your Windows. Windows 95/98 runs on DOS 7, though Microsoft doesn't want to let you know that. Effectively, DOS is the kernel. NT, and thus W2K, is a different OS with its own kernel, built to run most of the same software.

If you have a dual NT workstation, I'll bet it beats the pants off Win98. 95/98 is usually faster than NT on equivalent hardware (though I can't vouch for Win2K speed), but it takes NT to take advantage of a second CPU. Running Win98 on a dual workstation will leave half your clocks playing pinochle.

Re:Which version?

[Ex Machina]

I was impressed with win2k on my pal's Dell lappy. Litestep made it fun to use even.
Until the suspend mode started to give BSODs... :) It runs debian booted off a CD fine though...

Re:could somebody explain to me

[Graymalkin]

Here's a quick test, drop your monitor's refresh rate from whatever it is down to 60Hz then switch it back up. Big difference huh? Games running at a full 60fps have a huge visual distance. You see alot less blurring which I particularly don't enjoy (the blurring of low framerates). The problem I have with the 33fps is that the same exact hardware with a different OS has such a drastic difference in hardware performance. Linux ought to be doing better than Windows, not worse.

Re:Win2k out performing win98 (WHATEVER!)

[Graymalkin]

Play Q3 in Win98, pull up a console and type /r_smp 1 and see what happens. Ohhhh yeah, Win98 can't use multiple processors. Sheesh silly me. Tomshardware was restricted in its test because they needed to stick to a single processor. Linux, Be and MacOS all support SMP also and benefit from it.

Re:Doesn't really say much except...

[Emil Brink]

He. I like (and share) that attitude, but you do realize that RMS (who developed the license) does not agree, right? In fact, the official GNU party line is that the Lesser GPL should only be used for non-exclusive functionality, since it doesn't coerce other developers to use free licenses. It's interesting to note that people seem to use the license for quite different kinds of libraries -- SDL, for example, provides a rather "unique capability", but is still LGPL... Well, just food for thought, or something.

Re:open source directx..

[Graymalkin]

If DirectX were made open source it would be an enormous boon to just about everyone. The folks over at XFree could incorporate it into XFree, PC game folks could much more easily port their games to multiple OSes and in doing so gain market share. Sigh, I can wish.

open "sores" in defense of Linux

[MobyDisk]

I'm amazed at how quickly people jump to the defense of Linux by saying it has more overhead, and doesn't let the game have total system control. I thought Windows was huge and bloated! I thought it could never be as efficient as Linux, in terms of CPU time given to an application -vs- OS overhead. I read that distributed.net clients ran faster in Linux than Windows! This reminds me of the Mindcraft scenario, where noone could live up to Linux having a flaw. (In that case, the IP stack)

That having been said, the lesson we need to fess up to is that if Linux is to compete on the desktop, development in these areas needs to progress. Microsoft is behind in servers, and reliability. Linux is behind on the desktop. Both are working toward improving in the strengths of the other.

Business can prioritize, attack, and resolve. Open source must do the same. If we continue to cop-out the problem will not be solved, and open source will get a scar for being unwilling(not unable) to see the big picture.

Re:Inherent performance limitations for 3D?

[amccall]

In a very definiate way....

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...)

Re:Multitasking methods...

[delmoi]

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?

Performance of Linux vs Windows

[Performer Guy]

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.

Re:Kind of a pointless test

[drix]

5-10% speed improvement? Wha? I have talked to at least twenty people who have done this and have not seen that result. All had a drop in performance. I'd like to know where you got your numbers. Gamecenter shows 98 beating 2000 by 13fps and 10fps on identical machines. That roughly matches my own tests. The only game I've heard of even posting an increase was UT, and it was by 3fps - negligable.


--

Kind of a pointless test

[drix]

This shouldn't be surprising. Windows 98 simply does not have the amount of overhead that Linux or any multiuser OS with a good security model has. Things like that just take more CPU cycles, period. Windows will always have a bit of a performance edge for anything, but at the same time it will be a lot easier to crash it, write to memory that you're not supposed to, etc. Hardcore gamers will almost always stick with Win 98/ME. For the rest of us, it seems like Linux really is coming along. Again, it's just a measure of driver support, this test. Obviously Nvidia has more of it right now. Given two mature drivers for Linux and Windows, though, and Windows ought to win.

--

Re:Kind of a pointless test

[vectro]

This shouldn't be surprising. DOS simply does not have the amount of overhead that Windows or any multitasking OS with good hardware support has. Things like that just take more CPU cycles, period. DOS will always have a bit of a performance edge for anything, but at the same time it will be a lot easier to crash it, write to memory that you're not supposed to, etc. Hardcore gamers will almost always stick with DOS. For the rest of us, it seems like Windows really is coming along. Again, it's just a measure of driver support, this test. Obviously Nvidia has more of it right now. Given two mature drivers for DOS and Windows, though, and DOS ought to win.

Tux the Stud

[draggy]

Is it me or is the picture of Tux with the Joystick on that website makes it looks like he's got a raging hardon?

--
Let's not all suck at the same time please

There is no single Windows

[harmonica]

There is Win95/98 and there is NT/2000. They differ a lot.

As for Linux being such a superior OS -- that must be compared on an issue-to-issue basis. It's true for some, not true for others (usability).

A little bit less generalization, please.

If all's good, there won't be any Windows twenty years from now and nothing left to argue. And yes, I want everyone to use Linux because then my family will use it and I will be able keep everyone from deleting important system files.

This benchmark was VERY poorly done..

[samr7]

Somebody really didn't do their homework on 3Dfx drivers here.. The author seems to shrug off the XFree86 4.0 drivers for 3Dfx as being unstable or otherwise unready for public consumption, and instead chose to use the older, indirect XFree86 3.3.6 driver. If this person had built up enough courage to play with CVS, he/she might have discovered that the DRI are in fact closer to release quality than the NVidia drivers, and were even back when NVidia did their release a month ago. The bottom line is, both the NVidia and 3Dfx drivers for XFree86 4.0 are screaming fast and not yet release quality. Why this reviewer chose to use the beta driver put out by NVidia, but not the 3Dfx driver remains a mystery. It really paints an incorrect picture of the state of things. IMHO it's too bad.

Inherent performance limitations for 3D?

[VonKruel]

Are there reasons why one would expect slightly better 3D performance under Windows than Linux, given drivers that are about equally optimized on each system? I'm interested to know if we should expect to match or even beat Windows 3D performance, or if 95% is about the best that can be done. If 95% is the best we can do, that's quite alright so long as we have good reasons (e.g. solid design, stability). I've always believed it's good to sacrifice a bit of performance to keep things manageable for software people, and stable for end-users.

Re:Linux sucks on Games...

[mindstrm]

Why does linux have to 'decide'? Linux just does it's own thing. The fact that one camp wants it on the desktop, and another on the server doesn't mean it can't do both. Sheesh.
linux wasn't invented to take on windows. Linux was invented Just Because.

90% isn't "poorly"...

[Eric Green]

If Linux had 30% of the performance of Windows for 3d gaming, it would be performing "poorly". 90% to 98% of Windows performance isn't anything to write home about, but it's credible.

There is a type of FUD called "exaggerating differences", where a small % advantage for one platform or another is turned into a big deal. Let's not engage in FUD here.

-E

Re:Measure of Support not Performance

[Anonymous Coward]

If you compared just about anything and the Mac for 3D video you would find the Mac losing comprehensively, simply because the third-party video hardware just isn't there. You are right in saying the developer attention is firmly focused on the vanilla Windows PC, with a bias towards early adopters and buyers for the big OEM accounts. Yeah, Mac fans can bleat about the great high end stuff that can do desktop video, but we're comparing game-specific hardware right now, so just relax before flaming. Nvidia GeForce, even TNT2 is years ahead of comparably priced Mac hardware. And it will remain so - right now, GeForce 2 beats anything 3dfx can offer hands down. Maybe ATI have something in the pipeline - but Nvidia look unbeatable to me, politically correct drivers or not.

The conclusion of this article was that performance under Linux is "comparable" - not good enough. When people are prepared to overclock systems or spend hundreds on a video card alone to get the most out of their gaming, 88-99% as fast as windows just isn't an option. Linux has to get BETTER than windows or forget it - the gamer market needs a compelling reason to switch, and for those guys the only compelling reason is MORE FPS. In fact Linux has a disadvantage to overcome - most games are not even available. Can't wait for Terminus!

"Does Windows performance really blow away Linux performance?" So far.

Win2k out performing win98 (WHATEVER!)

[Shane]

For all those win2k bigots out there who claims 'win2k is so much faster then win98' please go do some research at http://www.tomshardware.com. You will find that Win2k lags behind win98 by about 10%. Thank you, drive through.

Re:Define real work

[tealover]

obviously you've never had the displeasure of using the Active Desktop. the bastards at Microsoft who forced that on us should be shot in their fucking heads.

Not the latest drivers

[Temporal]

In the article, they complained about the nVidia drivers being unstable, and they suggested that this bug would be fixed if the drivers were open. But then they said that they were not using the latest drivers due to "issues" with Q3A.

I am using the latest drivers. There are no "issues". They work perfectly. What's more, the instability they mentioned WAS FIXED (mostly) in the newer drivers. Supposedly, there is still an occasional crash, but I have tried to make it happen with no success.

------

Measure of Support not Performance

[sterno]

Really this demonstration indicates the disparity between Windows and Linux for support by vendors, not the actual power of the O/S. If you ran a similar comparison of Mac vs. Windows you would probably see similar results. It's not because Windows is superior its because 90% of the market earns you 90% of the developer time.

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 :)

---

Re:Needed: SMP support.

[Malc]

"almost makes me want to boot back into NT to play quake. Unlike some of the differences in those tests, the difference from 50-70 fps is a pretty big one"

It's not just a 40% boost in the framerate that makes Q3 under NT better. When the action gets really heavy, the framerate does not drop anywhere near as drastically as it does in uni-processor mode. So here's a request for more SMP support in games that can benefit, and more stable drivers from nVidia (original drivers for my GeForce caused NT to lock up a lot, newer drivers - 3.72 - just cause Q3 to crash a lot).

My conclusion

[(void*)]

That the Linux drivers were all (marginally) slower then the Windows counterparts was no surprise at all. 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. This small sacrifice is worth it, to gain this extra flexibility.

The more interesting question, IMHO, is the reason behind the good performace of the Matrox G400 and Nvidia, compared to 3dfx. The Nvidia card's performance is due to vendor tweaking, hence the close performance measurements. The Matrox G400, I think, is due to the wide popularity of the card, detailed vendor specs, and - dar I say - the wide use by the XFree86 team. 3dfx had a greater discrepancy becuase it is an older card and developers have lost interest, perhaps?

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. How can one generalize the results? I just have to wonder ...