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?"
Hell, Half Life and Doom are barely distinguishable from each other if your beer-goggles are thick enough. And it doesn't matter if the frame-rate slows down thru lack of processing power - your reactions are already terrible from the booze.
Yet again, beer is the cause of, and solution to one of life's problems (thanks to Homer for the [slightly paraphrased] quote).
Now the hardware industry has moved away from that, instead giving us free drivers for windows. Which not only are crappy in their first release, but are also useless on other platforms which the vendor decides not to support.
Bring hardware standards back, and MS will lose much of the power it's able to leverage through the high degreee of hardware support their system provides. I for one would sacrifice a little technological progress for the ability to have things work together as expected out of the box.
Ñ'
There seems to be a large amount of confusion as to what this means, and some people seem to be jumping off the deep end (as usual), so here's an attempt to clear up some of the issues.
(PS = Pixel Shader in the following points)
Hope this makes things clearer.
Pixel/Vertex shaders are an attempt to provide developers with low-level access while still maintaining the abstraction needed to support multiple sets of hardware.
To be honest, compared to the issues of shader program proliferation due to the number/type of lights you have in a scene etc., this isn't that big a deal. You might as well complain that writing a PS that uses PS1.3 means that you're 'choosing' GeForce 3 over all the existing cards that don't support PS1.3. Or that when bump mapping was added to DX and you used it, you were choosing the cards that did bump mapping over those that didn't.
DirectX is supposed to let you know the capability set of the gfx card, and allow you to use those capabilities in a standard way. The pixel shader mechanism is just another example of this at work.
As ever with games development, you aim as high as you can, and scale back (within reason) when the user's hardware can't cope with whatever you're doing.
Trust me, this is not news for games developers :-)
Tim
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.
Its much like the choice to support AMD's 3DNOW or Intel's SIMD instructions. If you use DirectX 8 or OpenGL, the issue is usually dealt with by the graphics library and the card drivers. Some bleeding edge features are initially only supportible by writing specific code, but that is the exception.
END COMMUNICATION
That was insightful? Crikey.
OpenGL is written for a UNIX environment, DX is for a Windows environment
No. OpenGL is an API, with bindings on UNIX platforms, on the Mac, Win32, Linux, PSX2, XBox and so on. Pretty much all 3D hardware of note has an OpenGL driver.
OpenGL does NOT change very much, which has both good and bad sides, for example, this threads discusses pixel shading, which is a feature OpenGL does not natively supports.
OpenGL does change a lot. Hardware vendors are free to add functionality via extensions, something they cannot do with D3D without going through microsoft.
Also, it does support what DX8 calls pixelshading. It exposes it through a quite different interface to DX8 (see here and here), this much more closely represents what the hardware is actually doing.
...is that developers shouldn't HAVE to develop for specific hardware. I don't work in the game industry specifically, but I don't see how this is necessarily good for software in general, or graphics software in particular. This doesn't give developers "more choice in the hardware they develop for" It gives them less choice, because they have to decide how to allocate limited resources on a per-platform basis. When you have a common API, you're not forced to choose in the first place. That's why hardware specific features and capabilities ought to be abstracted-out into a common API. What these guys should do is come up with a dozen or so different kinds of high-level magic (e.g. water waves, flame, smoke,bullet-holes, whatever) that they can work with their pixel and vertex shaders, lobby Microsoft to get that magic incorporated into the DirectX spec, and then supply drivers that meet those specs by sending a few pre-packaged routines to the pixel/vertex shaders, rather than have game developers worry about this stuff directly. Or am I missing something?
Oh, but you forgot the fourth option:
Say screw'em both and develop for neither, just using lowest common denominator stuff, and spend the saved time on improving the other parts of the game.
If your game cant stand on its own using that... well, maybe, just maybe, it sucks?
I don't care about reducing the pass number.
The framebuffer is only 8 bits per channel at most, while pixel shader hardware has higher internal precision per channel, keeping the math in the chip as well as saving read-back from the framebuffer saves bandwidth AND improves quality.
True per-pixel phong shading looks nice, but then all they seem to do extra is allow you to vary some constants across the object via texture addresses
Pixel shaders enable arbitrary math on pixels, it isn't a fixed function phong equation with a few more variables added. Maybe an artist wants a sharp terminator, cel shading, a fresnel term, or wants a anisotropic reflection.
All these are performed using 4D SIMD math operations, just like they were in 1.1: Add, Subtract, Multiply, Multiply-Add, Dot Product, Lerp, and Read Texture. But texture reads can happen AFTER more complex math, before there was only a few set math ops possible during a texture read. It's all in the DX8 SDK, which anyone can download.
Well that's great, but texture upload bandwidth is can already be significant bottleneck
"texture upload?" This isn't a problem, with DX8.1 cards having 64mb of memory for texture, why would developers be uploading textures per-frame? If you are talking about texture reads by the pixel shader, this also isn't a bottleneck. Reading geometry from the AGP bus is the bottleneck.
Artists won't draw bump-maps.
Sure they will, (heck, I do) look at any x-box game, they are all over the place. They won't draw in vectors-encoded-as-colors, they'll draw height maps, which would be converted off-line into normal maps.
I don't think ATI have a PS 1.0 implementation, someone please correct me if I'm wrong
1.4 hardware can support any previous version, including DX7 fixed function blend ops.
P.S.
I design hardware for this stuff, I do know what I'm talking about.
First of all, a direct link to ATI's SmartShader tech introduction.
.plan of his if you want to read more.
I have a few disparate thoughts on this subject, but rather than scatter them throughout the messages I'll put 'em all in one place.
ATI are attacking what is possibly the weakest part IMHO of DirectX 8 - the pixel shaders. Pixel shaders operate on the per-fragment level, rather than on the per-vertex level vertex shaders which were actually Quite Good. The problem with Pixel Shaders 1.1 is that, to paraphrase John Carmack, "You can't just do a bunch of math and then an arbitary texture read" - the instruction set seemed to be tailored towards enabling a few (cool) effects, rather than supplying a generic framework. Again, to quote Carmack, "It's like EMBM writ large". Read a recent
If you read the ATI paper, they don't really tell you what they've done - just a lot of promises, and a couple of "more flexibles!", "more better!" kind of lip-service. I don't care about reducing the pass number. Hardware is getting faster. True per-pixel phong shading looks nice, but then all they seem to do extra is allow you to vary some constants across the object via texture addresses. Well that's great, but texture upload bandwidth is can already be significant bottleneck, so I don't know for sure that artists are gonna be able to create and leverage a separate ka, ks etc map for each material. (I did enjoy their attempts to make Phong's equation look as difficult as possible)
True bump-mapping? NVidia do a very good looking bump-map. Adding multiple bump-maps is very definitely an obvious evolutionary step, but again, producing the tools for these things is going to be key. Artists won't draw bump-maps.
Their hair model looks like crap. Sorry, but even as a simple anisotropic reflection example (which again NVidia have had papers on for ages) it looks like ass. Procedural textures, though, are cool - these will save on texture uploads if they're done right.
What does worry me is that the whole idea of getting NVidia and Microsoft together to do Pixel Shaders and Vertex Shaders is so that the instruction set would be universally adopted. Unfortunately, ATI seem to have said "Sod that, we'll wait for Pixel Shader 1.4 (or whatever) and support that." I hope that doesn't come back to bite them. DirectX 8.0 games are few and far between at the moment, so when they do come out there'll be a period when only Nvidia's cards will really cut it (I don't think ATI have a PS 1.0 implementation, someone please correct me if I'm wrong) - will skipping a generation hurt ATI, given that they're losing the OEM market share as well?
I dunno, this just seems like a lot of hype, little content.
Henry
i don't do sigs. oops.
Who would buy an ATI board? Well, I would. Not to fan the flames, but...
I've owned a few video boards over the years, and have been constantly looking for a board that does both good 2D and 3D, and up until now, I haven't really found it. My Matrox Millenium (from about four years ago) did excellent 2D, no 3D. My Voodoo Rush had decent 3D for it's time, but the 2D sucked (blurry image, and this was without a passthrough cable). That got replaced (after switching back to the Matrox) with an nVidia TNT Ultra. The 3D was pretty good, but the 2D was a bit blurry (I dumped the TNT when I spoke with nVidia and confirmed that they were not producing Open Source Linux drivers - I don't like liars too much). So, the TNT got replaced by a Matrox G400Max Dualhead - excellent 2D, the 3D was lacking somewhat.
Just this weekend I purchased an ATI Radeon All-In-Wonder for $250. An excellent deal, since the 2D is nice and crisp, and the 3D rocks (for my purposes anyway). And, in 32-bit mode, it almost equals the GeForce 2 in performance.
Plus, this board has excellent multimedia. I love the TV tuner, it's so much better than the Hauppauge I used it to replace, plus I can hook up all sorts of video input devices and record from them. Excellent on the fly MPEG compression. And of course, we can't forget the hardware DVD playback, which is outstanding.
Also, like other people have said, let's not forget that the GeForce cards are still quite expensive.
A friend of mine was telling me three years ago that ATI made great cards, and I scoffed at him. Looks like I owe him an apology.
So, in conclusion, who would buy an ATI? How about somebody who wants a full-featured card that gives outstanding image quality. If you want pure frames per second, then buy your GeForce with it's blurry, dim images, since they screw around with the palettes and overclock the chips to get those numbers that hardcore gamers seem to like so much.
-- Joe
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. Now only if they could get Win32 cleaned up and a decent kernel, then I'd THINK about purchasing that OS. Although I'm not saying that there won't be card specific code, but as far as Pixel shader tech goes, as long as the drivers are DX 8 compatable, there's no problem with code for one card not working on the other. Besides, most systems sold in the last year have 810/810e/815E chipsets and stuck with those old i740 Starfighter chips.
Non impediti ratione cogitationus.
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...
You mean like when Netscape and IE were competing? In case you haven't noticed, HTML rendering between the two browsers haven't exactly meshed.
Where are we going and why am I in this handbasket?
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).
The standard lighting model in DOOM, with all features enabled, but no custom shaders, takes five passes on a GF1/2 or Radeon, either two or three passes on a GF3, and should be possible in a clear + single pass on ATI's new part.
It is still unclear how the total performance picture will look.
Lots of pixels are still rendered with no textures at all (stencil shadows), or only a single texture (blended effects), so the pass advantage will only show up on some subset of all the drawing.
If ATI doesn't do as good of a job with the memory interface, or doesn't get the clock rate up as high as NVidia, they will still lose.
The pixel operations are a step more flexible than Nvidia's current options, but it is still clearly not where things are going to be going soon in terms of generality.
Developers are just going to need to sweat out the diversity or go for a least common denominator for the next couple years.
I fully expect the next generation engine after the current DOOM engine will be targeted at the properly general purpose graphics processors that I have been pushing towards over the last several years.
Hardware vendors are sort of reticent to give up being able to "out feature" the opposition, but the arguments for the final flexibility steps are too strong to ignore.
John Carmack
If so, it won't be the first time; remember the days of 3dfx? Original Unreal would only run on Glide hardware acceleration; if you didn't have a 3dfx card, you were forced to run it in software. Of course, this didn't sit well with the growing NVidia user base who consistently pointed out that Quake 2 and Half-Life both rendered on anything running OpenGL (including 3dfx cards; remember those mini-driver days?), and OpenGL and Direct3D renderers were finally introduced in a patch. That's about when 3dfx started to go down the toilet; delaying product releases and missing features (32-bit color and large texture support being two of the most blatant omissions) eventually tainted the 3dfx brand to the point of extinction.
Since then, 3D gaming has been a less lopsided world. Linux gaming was taken seriously. Standardised APIs that could run on almost anything were the rule; if it wasn't OpenGL, it would at least be Direct3D. Then the GL extensions war heated up, with NVidia developing proprietary extensions that would work only on their cards. But this wasn't a problem; you could still run OpenGL games on anything that could run OpenGL; you'd just be missing out on a few features that would only slightly enhance the scenery.
Leave it to Microsoft to screw it all up with DirectX 8. They suddenly started talking about pixel shaders and other new ideas. John Carmack has already described the shortfalls and antics of DX8. And now 3D programmers will have to program for multiple rendering platforms, but at least you can still run it with anything.
Sure, this entire disagreement between ATI and NVidia is bad for the 3D industry, but things could be worse. A LOT worse.
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
This is good for hardware because ATI and NVidia will continue to push the envelope, developing more and more advanced graphics boards. Features will creep from one end to the other, just staggered a generation.
This is good for software because developers will have more choice in the hardware that they develop for. 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.
A bipolar competition is ALWAYS good for the consumer.
Execute? [Y/N] _