Slashdot Mirror
ATI & Nvidia Duke It Out In New Gaming War
geek_on_a_stick writes "I found this PC World article about ATI and Nvidia battling it out over paper specs on their graphics cards. Apparently ATI's next board will support pixel shader 1.4, while Nvidia's GeForce3 will only go up to ps 1.3. The bigger issue is that developers will have to choose which board they want to develop games for, or, write the code twice--one set for each board. Does this mean that future games will be hardware specific?"
Every time I get a game, there's a short list of graphics devices supported on the box. I always hear about the development of this or that game, in terms of specific card features.
Heck, I even remember Carmack talking on Slashdot about things like "Nvidia's OpenGL extensions" and other features of specific cards that he was having to take advantage of.
Yeah, the new wiz-bang game will probably be able to limp-along on whatever you've got, but likely will only be optimized for a few special cards.
The video-card industry has gotten really awful. I hope that someone pulls it back in line and we get back on a standards track where card manufacturers contribute to the standards efforts and then work hard to make the standard interface efficient.
But what's with all of these doom & gloom posts about fragmenting games for specific hardware? There's already a ton of features that may or may not be available in Direct3D or OpenGL depending upon your underlying hardware and driver. In Direct3D these are known as 'capabilities', in OpenGL they are 'extentions', in either API you can easily check for their existence.
Game developers are already doing this for features such as dot3 bumpmaping. Some boards support this feature in hardware, some don't, so your code is free to check to see if its available and use it if it is or ignore it (or fallback to some other method) if its not.
These shaders aren't really any different from that.. you write code to look at the shader version supported and either use 'new improved' shaders or 'older style shaders' depending upon the platform.
Yes, its more work for the programmer/artists to support a fallback mode, but that's the price of targetting cutting edge gaming hardware while still supporting users of older systems. It always has been and always will be.
As to the dramatic question of ATI vs NVidia, I'd say that NVidia has the early advantage due to the XBox. Considering how similar the XBOX graphics system is to the PC GeForce 3, its pretty much guaranteed that all of the major gaming engines being used to create most 'big' games these days will target GeForce3/XBOX features specifically, and features of 'other boards' (such as ATI) only as a bonus if there's enough time, or ATI lays down enough cash on a crossmarketing deal.
Of course, if Microsoft manages to flub the XBOX release to a staggering degree, all bets as to the future are off.
The differences in hardware are not that big of a problem for next generation graphics engines. The amount of features and flexibility available now necessitate using a higher level shader language as opposed to hardware specific api features. A well designed shader language can be compiled to take advantage of whatever driver features you have available, and emulate or ignore the rest.
We are currently able to target both pixel shader versions in DirectX, and hopefully soon in OpenGL. We are currently ignoring features not supported by the hardware that shader code tries to use. So rendering the shader surface on a GeForce1 will look much worse than on a full featured card, but we don't waste time emulating it.
For reference on similiar techniques check otu Proudfoot et al. 'A Real-Time Procedural Shading System for Programmable Graphics Hardware'. (Thought thats based on NVIDIA hardware, it extendable to new features as well)
"Does this mean that future games will be hardware specific?"
Well, yes actually. Haven't they always been? We've had 3Dfx versus PowerVR, Glide versus OpenGL, Direct3D versus OpenGL...
It goes all the way back to floppy versus CD, Win3.1 versus Win32s, 16 colours versus 256...
Every game has system requirements (even if your only talking about a scale like processing power), and always has done. I still remember the shock when I realised I'd need to get a tape drive to complement the disk drive in my CPC664, just to play some of the games!
I think you're thinking of OpenGL.
> This is good for software because developers
> will have more choice in the hardware that they
> develop for.
Bullshit. That path leads straight to the darn old days where every game was board-specific.
> ATI doesn't support super-duper-
> gooified blob rendering? Ah, NVidia does in
> their new Geforce5. No worries, ATI will have to
> support it in their next generation boards.
Wrong, this should be "ATI doesn't support super-duper-gooified blob rendering? Idiot, why did you buy that board in the first place? But no worries, NVidia has the new Geforce5, just spend 300+ bucks an get one. Unfortunatley, this will break application Y as only ATI has the new M.O.R.O.N.-rendering which is required by Y. But hey, such is life!
> A bipolar competition is ALWAYS good for the
> consumer.
This is not "bipolar competition", this is "fragmentation".
C. M. Burns
Looks like we're back to the days of yore, when you (the developer) got to choose to support a specific card (3dfx or the others that didn't survive) because there was no DirectX support... because there was no DirectX. Then you (the consumer) got the shaft if you didn't have the right card, unless the developer later came out with a binary that would support your card's features. But if it wasn't an uber-popular game, this usually didn't happen.
So why are Nvidia and ATI forcing developer to go back to the stone age of accelerated polygons? Oh that's right... Me likes pretty picture.
The Pixel Shader technology will be backwards compatable as far as the DirectX 8.0 API is concerned. Imagine that. Microsoft using an API to bring software developers together across various hardware choices.
Sadly the situation is not unified in OpenGL yet, with both Nvidia and ATI providing their own separate extensions for accessing pixel shaders. One can only hope that its not too long before we can get an ARB-approved extension that covers the capabilities of both cards.
Of course, since it will be quite a while before games publishers can rely on people having a GeForce3 or Radeon2, I expect pixel shaders will only be used for optional flash for quite some time. If people are doing bump mapping and phong shading and so on using them, they'll certainly have the option to run in a slightly less attractive mode for those with lamer hardware.
This story actually gives me a chance to bitch about OpenGL! None of these new features are a part of the standard OpenGL. "Extensions! Extensions!" you shout. However, due to the differences between hardware, you'll end up with ATI and NVIDIA versions of the same extensions, since the ARB won't touch such new/untested features. This makes sense in the pro segment, where hardware is slow to evolve, but in the consumer segment, it will make the API seem antiquated. Plus, the extension mechanism isn't even suited to such uses anyway, since it was meant to expose features, not radically different methods of rendering. And yes, these are radically different. Part of the reason that the GeForce3 has 57 million transistors is that it has to have a standard geometry engine for DirectX 7 and a new vertex shader-based geometry engine.
In the long run, this will make OpenGL unpopular with game developers. Sure guys like Carmack and afford to suck it in and develop to all the extensions, but for a small development house that wants to make an impressive game, they'll go with DirectX to save themselves the development costs. And when they do, there goes the possibility of a native Linux port.
Now there are two solutions to this. First, the ARB could get off their asses and start integrating extensions. This could be problemetic for the pro segment, which wants a stable API. On the other hand, the ARB could fork OpenGL into a pro and a consumer version, but that results in two incompatible APIs. I think Microsoft is doing the right thing by supporting the latest featuers (in essense, baiting all the hardware manufactuers to integrate these features) but it *does* make DirectX unsuitable for pro use.
A deep unwavering belief is a sure sign you're missing something...
What comes to ATI vs. NVidia. I've always resented ATI, and NVidia has always had better cards. But my opinion has started to change to favor ATI. NVidia's refusal to release any open specs to create drivers for their cards is blasphemy. At least ATI is open about their sucky hardware (Radeon is actually quite nice).
The World's Best Music!
I'm one of the developers of next version of the Genesis3D game engine. We ran into this problem of what do we support on an engine that is to push the latest cards to the limits.
The simple answer was to write the common code in the main part of the engine then write multiple drivers for the engine that would use different features on different cards. This way we could push both cards and optimize the code for each card to get the best performance. Of course this is no easy task either.
This is a pain but if you wish to push what each card can do, you have to write code for each individual card or maker of the cards (IE a nVidia driver and an ATI driver then a 3rd driver for everything else that the other 2 don't optimize and run on).
I think the answer to that question is to rate just how flexible the current API's can be. The two contenders (and please, let's try not to make MORE!) are OpenGL and DirectX. Nvidia has ressurected the venerable Amiga's idea for a fully programmable graphics processor, and I presume that ATI's post-Raedon chip will be similar.
So, which API allows one to most easily get at the GPU's coding power? How many hooks does the high level api have into the gpu's engine, and can the gpu get data from the api on the fly?
If anyone out there has worked with them, I'd be curious to hear what's present or lacking from the standards, and if it's feasable to try and write GPU level code abstractly.