Slashdot Mirror
3D Benchmarks Under Linux
Clump writes, "Linuxgames has an interesting article that benchmarks 3D cards under Linux. This is significant because most hardware is only reviewed in Windows. Had I read this before, I may not have spent $150 on a TNT2 card. ;). "
What I'm wondering is where the Diamond Viper cards are. These cards are quite common in the market, and I should expect to see them compared. Especially since in the Windows benchmarking schemes, they ranked quite high, right up there with the Matroxand Voodoo3 cards.
-Ben
And the funny part about SDL is that allows you to write for one API, SDL+OpenGL, that allows you to write for Linux AND reasonably expect to merely recompile for Windows or vice versa. SDL encompasses 2D and 3D support along with sound, MJPEG, and MPEG playback. Sounds like a winner to me.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
It'd have worked well under both Windows and Linux. While the framerates are lower for the G400, the visual quality is much higher than with the NVidia TNT2 cards.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
it's exactly the same thing under BeOS... 3D accelerated openGL works well with voodoo2/3/banshee, but for Nvidia, there's even no GeForce 2D driver for the moment!
even if in windows i prefer a TNT2, i think i'll buy a voodoo3 just for BeOS and others OS.
--
BeDevId 15453 - Download BeOS R5 Lite free!
"Science will win because it works." - Stephen Hawking
You point out the one edge that DirectX so far has over OpenGL, which is the ability to detect which features are implemented in hardware. There are, however, 3rd party libraries available for OpenGL that do the same thing--but really it should be part of the API.
I've done DirectX programming, and I don't really see how the various components (DirectDraw, DirectSound, DirectInput, etc.) are integrated in any way, besides the fact that they all use COM, require Windows, and have "Direct" in their names.
Anyway when comparing 3D graphics API's it's only fair to compare Direct3D Immediate mode with OpenGL. Sound and input libraries are important, and I wish Linux got up to speed in that department, but they don't really have anything to do with 3D graphics API's.
As for DirectX being faster for emulating features in software, this is not entirely true-- it is implementation-specific. It is up to the vendors like NVidia or Matrox to optimize their software fallback paths in OpenGL, whereas you are stuck with Microsoft code (which is reasonably fast anyway) for DirectX.
________________________________
I can't tell if this is a troll or just an uninformed opinion.
Please explain in detail what it is about OpenGL that makes it unsuitable for games.
Please explain in detail what it is about DirectX that makes it superior in ANY way to OpenGL for gaming purposes. Remember, we are comparing API's, not implementations.
________________________________
Right. DirectPlay is for networking, and DirectInput is for input devices (joysticks, etc).
For graphics, the times of requiring direct framebuffer access are over, which basically makes DirectDraw useful only as a memory manager for offscreen and agp memory.
Direct3D Retained mode is useful for simple modeling apps and not much more.
Direct3D Immediate mode is basically a (poor) mirror of functionality already in OpenGL. The only reason for D3D IM is MS politics of embrace and extend.
For networking, we have and always have had sockets. The sockets API is low-level enough for games, cross-platform, and easy to program in. DirectPlay, again, is an API created for purely embrace-and-extend reasons.
For input devices and sound, MS has Linux beat fair and square. Although they are twisted and contorted APIs, DirectInput and DirectSound fill holes that haven't yet been filled on Linux.
________________________________
How about a mini-distribution of Linux with:
a) kernel compiled for maximum optimization for games
b) services that make any impact on performance (even if ever so slight) removed
c) networking part of kernel tweaked for the typical size/types of game packets
Hrm. 1-2 fps faster than "non-optimised"?
Has anyone ever tried this?
I tried the other day..XFree 4.0 doesn't support it, supposedly 4.01 is supposed to (from the matrox website). With kernels above 2.3.48 (or something) you can do multihead with frame buffers on the console. Any time I tried to get X to start on hte second monitor Linux would crash. Plus the second monitor is not accelerated, so even catting a file is _really_ slow.
Having said all that, 2.3.48 was the first kernel to ever have support for G400 dual heads..I'm sure they have worked out a lot of bugs since, and will continue to do so..
I just wanted to say that while it sounds real cool and all, the G400 isn't all that great.
The basic sleazeware produced in a drunken fury by a bunch of UCBerkeley grad students was still the core of BIND. --PV
You don't pay much attention to what LokiSoft does, I take it.
:)
Sam Latinga, lead programmer for LokiSoft, has written the Simple Directmedia Layer (SDL), which is a *cross-platform* gaming library, which handles input, (2d) graphics, 3d graphics thru OGL, sound, etc. It supports (if i'm not mistaken) *n*x (obviously), BeOS, Mac, and Windows.
If you take a look at the news from the last week or so on http://www.linuxgames.com/, you'll notice that about 60% of the new games use the SDL - and there's a very good reason - it's got GREAT APIs. I'm no game programmer, but I'd guess I could code up something simple very quickly if I decided to.
Unreal Tournament for Linux also uses the SDL - works great. (aside for the fact that the renderer needs work
>>NVIDIA's cards - They've been making quite a stir with reports of fast, quality drivers that aren't open source. When they arrive, I'll be doing my best to compare their performance with all the other cards available<<
So, apparently they didn't review this because the drivers still aren't ready. I guess it's a good thing I don't expect any sort of performance out of my tnt card.
Lowmag.net
NVidia, at least on some level, realize that they don't make money on the drivers. Otherwise they would charge you for every upgrade, every additional OS, and so on. However, they haven't made the cognitive leap that says that not only will bad drivers cut your sales (albeit not by much) but that good drivers will help your sales (by even less). But the good part is that if you publish your top level specs (without going into detail of how the card works), people will write good drivers for you for free.
You made the parallel with Intel. Intel gets it. You don't see Intel bragging about the latest opcodes in their new processor, but not telling you how to use it unless you sign an NDA. The more software that uses Intel-specific chip functionality, the less market share AMD gets.
--
E_NOSIG
If you read the press releases or had followed the whole NVidia thing at all, you would know that NVidia is co-developing it's OpenGL support with SGI and VA Linux, two big companies with acknowledged Linux technical know-how. But there have not been any new announcements for at least the past month or two, which is especially annoying to TNT2 owners such as myself, who upgraded to XFree86 4.0 in anticipation of an imminent release. Giving an ETA would at least give me something to look forward to, while as it is I can't seen an end in sight :(
I have been forced to do all my OpenGL programming under windows, simply because getting decent framerates under Linux for the stuff I'm doing is impossible. To give you an idea of how bad NVidia's current drivers are, I find software rendering with Mesa under XF4 seems occasionally faster. When the initial driver announcement was made, I wrote a grateful e-mail to NVidia and forked out >$250US for a brand new TNT2 card, more than I've ever spent on a single computer component in my life. One year later I'm kicking myself for doing so. Even if their implementation is faster, I have been stuck with a substandard OpenGL implementation for a year. If I'd bought a cheaper card with equivalent OpenGL muscle (such as, say, a Voodoo3 2000) I'd have more money to spend on the next generation cards.
My next card's gonna be a Voodoo baby! NVidia, you suck.
Daniel.
Probably because one of two reasons:
1) They think nVidia is evil for not releasing specs and not being very Open Source friendly.
2) Because nVidia's developer's drivers suck. (But will hopefully be replaced by high quality drivers soon).
Adam
PS. Then again, it could be for both reasons.
Now, what we must have is an update of this benchmark with evolution of drivers implementation. Why ?
Because Linux (or other Unix OS like FreeBSD) is not Windows and the code haven't reached is best. But the author understand it: read "Future Work" at the end of the article.
I think it would be a good idea to have a site for benckmarking. People will do benchmark and send results to the site with full desription of their configuration. So, we can have good informations on well programming 3D games and knowing the graphic cards with good drivers (3D AND 2D). The site of course will have to precise how to do the benchmark in order to use data.
GOOD WORK LINUXGAMES and GLX-UTAH ! SHAME ON YOU NVIDIA !
First things First. The nVidia cards are hands down the best performing and best looking Game-class video cards for x86. Multiple people _left_ SGI to work at nVidia. SGI _sold_ graphics chipsets to nVidia. nVidia boards are made to be high quality 3d accelerators; this should be evident from how they exhibit very little performance degredation as resolutions/color depths are cranked up to the cards limits. Unlike Voodoo Cars, which tend to run well at low resolutions, and with low colordepths, the nVidia cards have always been rock solid 2d cards, and stellar performing 3d cards, at any resolution and any color depth.
nVidia employees have admitted that the current linux drivers suck, and obviously there is a great deal of performance work that can be done. I don't know that i'd hold my breath for open source drivers, but drivers that simply work and work well for a reference x86 and XFree86 platform would suffice to fill the largest hole. I would speculate that part of nVidia's reluctance to release drivers is because theres's frankly too much they'd have to released to get a respectable solution delivered. The "way to do 3d on linux" is still developing, and there are multiple parties taking multiple approaches to the problem. Which does nVidia support ?
At any rate, the point is, the nVidia cards have amazing performance and do not sacrifice visual quality or standards compliance to acheive this. Furthermore, nVidia has the cream of the crop working for them. Mark Kilegard (sp?), author of GLUT and previous SGI legend even works for them now.
On to OpenGL vs. Direct-X. Frankly, it's a apples vs oranges sort of thing. OpenGL is basically a way to make a uniform API for putting lines and triangles into a rendering context. It is _very_ low level. To get more useful functionality, you're typically going to be using GLU routines, as well as something like GLUT, libaux, or Open Inventor. It's good that openGL is _there_ for people that need to get that low occasionally, but run of the mill apps usually target GLUT or Inventor, as opposed to GL directly.
Direct-X, on the other hand, is a general purpose set of libraries to make doing interesting things fast(er) and uniform. Direct-X is much more tied to windows, and Windows hardware than GL is. Direct-X is also much more all-encompassing. GL doesn't even interoperate iwth the X protocol; thats what GLX is for. There's no intrinsic way to make an app take over the full screen with GL; every Direct-X program does this, as well as changing the resolution on the fly. Direct-X provides a uniform way to talk to all the sorts of hardware you'd like to talk to. There isn't a uniform sound API in Linux, (case in point: competeing sound libraries), much less a cross platform UNIX sound API. There are _no_ good API's for input handling in Linux, much less a cross platform UNIX method. While UNIX of course has nice networking features, there's nothing provided at a higher level than connect()/bind(). while thats enough to establish a socket, thats _not_ enough to make a good LAN-game subsystem. Any UNIX games need to build from the ground up.
Finally, lets get to the real apples-apples comparison here. Direct-3D vs OpenGL. Basically, OpenGL wins hands down for quality, standards compliance, ease of programming, and _performance_. It was once said (and i forgot by who), that the D3D system was so poorly written that it couldn't push enough triangles at the video card to make a difference; D3D itself was the limiting factor.
One area where D3D might do better than as-accepted GL is making performance tradeoffs. GL is marvelously inflexible when it comes to using/not using hardware acceleration. The most wonderful example of this is the SGI Indy R5000, with XZ graphics. Basically, the Indy's main CPU can do a much better job doing geometry calcs than the older XZ video board can. However, the GL subsystem sees a Geometry accelerated card in the system and immediatly dumps all the work to the gfx board. Downgrading video cards in this situation _increases_ performance. A similar situation exists when you define more lights in a scene than the hardware can efficiently support; suddenly everything sucks and you are left wishing there were a way to say "just do 95% of the stuff in hardware, leave the lighting to me!". Allegedly, Direct-X has ways to specify what does what job. That'd be handy.
Performance feedback is _possible_ with GL, but its not standard. SGI has many SGI-specific X-server and GLX extensions to do this. For instnace, theres an SGI extension for guaranteed framerates. If it thinks it wont be able to draw the current frame fast enough, it scraps it, draws it at a much lower resolution, then pixel-multiplies the rendered frame to fill the view-window size. Thus you get a constant framerate, but variable image quality. This is a great feature (assuming it works right), but again, its not a GL thing, its an SGI thing. It's something that games could greatly benefit from, but theres no standard way of doing it.
In summary, GL is great at what it does. I don't think anyone can argue against that. Likewise, D3D is awful at what it does, but Direct-X is a much needed layer for developers, for which there is nothing _close_ to a counterpart in the Linux, or UNIX world.
My opinions are my own, and do not necessarily represent those of my employer.
I got about 50 FPS on Win98, and 26 on Linux/GNU/XFree awhile ago.
Mind you, with nvidia releasing 'leaked' drivers like the 5.13 (www.reactorcritical.com) which Push my GeForce with all goodies enabled (slowest possible) to over 60 FPS in 800x600x32bit.
I'm hoping the latest Linux 2.4 kernel in combination with the Xfree 4.0 will be stable soon... I'm getting tired of seeing blue...
-grin-
Another big thing that will put the benchmarking of Linux 3D GL on a lower tier than it's Windows counterparts, is the fact that not all the GL extensions are supported under linux, and as NVidia has decided to go 'the bad route' when it comes to releasing source/specs for the cards, we may not see the propper integration into Linux that we are all hoping for.
And now the threat is looming that S3TC may be scrapped (with it only being available on Windows 5.13 drivers) before Linux userd can reap the benifit from it.
That's also another thing that impacts the performance of 3D cards : Memory. S3 Texture Compression helps with this (quite a lot), but mostly it's impossible to do propper benchmarking on low memory systems, as there is a Texture throughput bottleneck. (It's practically impossible to play Quake 3 under Win98 using only 32MB, whereas Linux may handle that better AFAIK).
Just my Opinions.
Don't shoot.
:)
50-75 fps with my tnt2 under Win98/Quake3
4 fps with my tnt2 under X/Quake3
We're almost there guys!
blech.
People seems forgetting that excellent performance is not just high FPS but also high picture quality The author of the article seems somewhat clueless on this issue, and although he mentions that V3 can't do all the things that should be done in high quality setting, yet he finally skips the issue Indeed, it is quite unfair to compare the speed of the v3 and f.e. G400 in HQ as V3 just skips most of the things that would make the setting HQ. [ Go, get a G400 ;) it will have DRI support in Xfree86 4.01 ]
Real life is overrated.
At this point, it's worth noting, since nobody else has, that some term definition is needed.
DirectX is a collection of interfaces, primarily designed for gaming. The true purpose of DirectX was to kill DOS by making it possible to get decent access to hardware functions in Windows.
Direct3D - is a 3D graphical API, somewhat analogous to OpenGL. It has been through a tortorous evolution, because up until V3 it was pretty much unusable. Beginning with V3 it started looking very much like OpenGL. Later releases have started piling the features on and on, to where some say it has gone past OpenGL. Others say that it's merely piled on features, not well thought through.
DirectDraw - More of a 2D package, but more than that, a fundamental API for gaining access to the framebuffer and video mode. To use Direct3D or OpenGL in Windows, you need to go through DirectDraw, first. The 2D part of this is rather similar to SDL.
DirectSound - What else, an audio library.
DirectPlay - I'm not sure if this is input device access, or network play access. One or the other, and whichever it isn't, is DirectSomethingElse.
The real key to DirectX is that it is the ONE way to do game programming in Windows. Though at the moment, it appears that the suite is getting well covered in Linux, between Mesa/OpenGL, SDL, and that audio library that Loki is backing. We're still missing a DirectPlay analog, whether that's input devices or netplay, we're missing both packaged library sets.
The living have better things to do than to continue hating the dead.
One of the main reasons why games are easily written on Windows is the DirectX API, which provides support especially optimised for every area of gaming.
I think that directX is one of the main problems with Windows. As I understand it, it allows applications to directly access the hardware without having to go through the OS. This is not an Engineeringly sound idea. It increases performance, but it makes the system itself less stable.
--The Mighty Willtor
"The knee is the elbow of the leg." -- My wife
But does Linux have similar libraries like DirectX? Not that I'm aware of, if someone knows differently, I'm interested. Keep in mind, DirectX is NOT just video - DirectDraw covers video, there's a lot more to DirectX. You still need sound libraries, input libraries (for joystick/mouse/keyboard), networking libraries - wait, that Linux does have these and they're better than DirectPlay - moving along, other things which are required for the gaming experience.
And these libraries would need to be FAST - and I have a feeling that they probably shouldn't be going through an X server at all. I don't know, what is the overhead of using X as opposed to using a direct-to-hardware library? Or is X used on a local machine direct-to-hardware? Like I said, I'm not sure. And again, this brings up control issues - I'm not sure exactly how keyboard and mouse control can be used through X, I've never really looked into it.
The final point is that such a library would need vendor drivers (either written by the vendor or open specs to be written by others). And this could be the real stumbling block.
You are in a maze of twisty little relative jumps, all alike.
As a long-term user and fan of the Linux platform I can appreciate that it's annoying that things like this are always done in the Windows world, but in this case it does make sense - Linux is just not ready for gaming yet.
Sure, companies like Loki are trying their best, but the games they are porting are older ones which have lost that "cutting edge" feel which new games have. And there aren't many of them either, and they are only puchased by a small "hardcore" of Linux gamers. Unfortunately, Windows is still the platform for playing games on, whether we like it or not.
The situation won't really improve until Linux is made more friendly as a gaming platform. One of the main reasons why games are easily written on Windows is the DirectX API, which provides support especially optimised for every area of gaming. What Linux needs is something like this, but obviously open source so that it can be improved easily.
Until Linux gets this support I think it will always languish behind Windows as a platform. As a consequence, hardware manufacturers will be more wary about writing drivers for Linux, and they will have a lower quality than Windows ones. This will lead to the benchmarks (which will only be done on Windows to save money) not reflecting performance under Linux, as we see here.
Some of the links in the middle of the article are broken - they're suffixed with ".html" instead of ".shtml".
The "next" links on the bottom of each page seem to work though - or you can just add the "s" manually.
Want to learn about race cars? Read my Book
It's COM (and therefore ActiveX) based. Calls within calls to interfaces. There's a very good reason why John Carmack uses OpenGL, etc. for his games- it's because DirectX isn't easy to use. Games are written to Windows only because it's the dominant computer platform.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Note that these benchmarks are on XFree86 3.3.x that ships w/ RH 6.2 - XFree86 4.0 should change the playing field quite a bit. It's nice that these guys benchmarked with a "standard" configuration, but IIRC, RH 6.2 is compiled and optimized for a i386, not the i686 class processor that they benchmarked on. With the boost that the G400 gets from CPU, an optimized set of binaries should improve the performance on this card quite a bit.
XenoWolf The Original - Since 1993
Redhat should be doing something about the atrocious situtation for 3D video card support in Linux. If the problem is NDAs, then I can't see a better third party to trust with releasing binary drivers - a bad situation to be in, but we live in a world that just isn't going to see Nvidia (or anyone else) give up ANYTHING that might help their competition. Waiting 3 years for a card to become obsolete and then getting register info (maybe) isn't my idea of what will make Linux the operating system of the future.
Somebody needs to step forward, someone with money and reputation to help fix this situtation. Linux isn't going to make it to the mainstream unless we can either get third party hardware manufacturers releasing register level information - again, I've got some heat-resistant snowballs for THAT day, or get someone the community trusts working to support binary drivers - hopefully on all platforms (Alpha, PPC, x86, 68k, whatever).
NVidia has been taking a lot of flak from the community, some of it deserved, but I don't think a lot of people apprecate the kind of research and development dollars it takes to make a cutting edge 3D chip. Would you expect intel to release it's manufacturing processes and schematics for the Pentium III core (or AMD's athlon) under the GPL? of course not. While we're not asking for how to make a Nvidia GeForce, I think that's what NVidia is worried about.
But, to avoid rambling, some Linux player with some power and money needs to work with us here. SGI would be another canadate, Debian is GNU/Linux, so don't hold your breath, but Redhat is in a great position to show some goodwill and long-term thinking.
Kudos (still waiting for TNT/GeForce 3D so I can nuke windows)
..don't panic
Unless Nvidia comes out with better drivers soon, I'm going to put in an old Vodoo2 just so I can have something that works in Linux. The only reason I'm not getting a new 3d card is I spent a lot of money on my TNT2, and I allready had more urgent upgrades planned for over the summer, like a bigger hd. If Nvidia dosen't get their act together soon though, I'm definitly going to get my next video card from someone else
I always prefer to start the year off with a bang - or, to be more precise, a series of loud hums, a crackle or two, and
Okay, so I'm a matrox bigot. I'll preface this post by saying that. I have a Matrox G400Max in my home system and a Voodoo 3 3000 (I think) in my work system. Overall I'm more impressed with the visual quality of the Matrox. There are just some things voodoos can't do. I belive 32 bits is one of them. But the real reason I bought the G400 was because of two factors - OpenGL in a window in X and Dual Monitor Support. Most programmers will agree that openGL in a window is much better for development as you can see debugging information while running the program. Do that with a V3 in linux. Although dual head support on one AGP isn't here yet, it will be soon in XF4. When only displaying on one display the matrox is usuing only one of the two separate ramdacs on it. It's akin to only using a single processor on a dual processor system. It's rather a shame. The only downside to the G400 is that I can't play soulblighter accelerated as its glide for linux. But I suppose that's why I keep the monster 3d around.
My Slashdot account is old enough to drink...
Although the common Joe or Jane user doesn't really care about WinMark, WinBench, 3DBench, etc. scores, these are very important to OEM's and companies who purchase large volumes of PC's and peripherals.
If the community's goal is to get Linux adopted by more mainstream companies (note I said _IF_) a standardized performance testing suite is definitely going to have to be put together.
As far as video cards go, comparing Quake 3 scores is a start, but it's not the final word in 3D performance. There are very comprehensive test suites out there for 3D implementations that need to be ported or replaced on Linux.
We already have Viewperf (sorry, I can't find the link) which is an excellent cross-platform 3D benchmark. I believe its results much more accurately reflect the quality of a 3D implementation than, for instance Quake, which is heavily biased towards fast texture-mapped triangles (yes there is a 3D world out there besides texture-mapped triangles!)
A test similar to the OpenGL conformance test would also be nice, to make sure that 3D implementations out there for Linux are not "cheating".
________________________________
The author will redo the tests with correctly clocked G400 when he gets back from a business trip. See this forwarded post at Utah-GLX mailing list
Also, as the G400 is quite much CPU bound in the tests, I would believe that compiling the GLX with better gcc parameters should also have had an effect to the scores.
DirectX includes DirectDraw, DirectSound, Direct3D, DirectInput. All of these are designed to work together.
OpenGL has glut.
One point to DX for flexibility.
OpenGL has had implicit support for accelerated hardware Transform and lighting since Beta versions.
DirectX has only had support for this since version 7. Applications have to be specifically coded to support it.
Score is 1-1 so far.
Claims that DirectX is faster due to lower function call overhead are not strictly speaking true. Use of Display lists will speed up OpenGL.
I think I'll call this one a draw.
OpenGL has a very easy to understand API.
DirectX is cryptic, and still requires some Windows coding to set up the display.
Another point to OpenGL.
Direct3D allows you to test whether operations are hardware accelerated and turn them off if the quality improvement isn't worth the speed loss.
OpenGL will always emulate this in software
Since this is about fast games, I think DirectX deserves a point here.
DirectX has better software emulation speed.
DirectX has better Windows hardware support
OpenGL has better non Windows support. This includes Macs. This reduces the cost of porting games.
This points to a general benefit to using DirectX, but does not make it "Far superior". What OpenGL really needs is a set of other API's that are suitable for games, and are compatible (and similar in structure).
If you're wondering why nVIDIA cards weren't reviewed, I've put up a couple of pages with information about the company and the saga of their "Linux support". The current rumor is that they have binary only drivers for XFree86 4.0 using their own straight-to-hardware pipeline (instead of DRI), and they're not really concerned about Linux users in general.
Link is here.
--
how to invest, a novice's guide