Slashdot Mirror
3D Labs Proposes OpenGL 2.0 To Kick DirectX
furiousgreencloud writes "3Dlabs is trying to drive the graphics interface away from hardware specific extentions, as seen in DirectX. Instead, they are proposing an open (no NDA) dialog on OpenGL 2.0. The guidelines mention good-ol-fashioned platform independence (linux included) and emphasis on programmability, time control and memory managemenmt. They've got a PDF availible for consumption."
This is completely untrue.
A standard for pixel and vertex shaders that is not specific to any one card is a very big deal, and people are reconizing that it is the future. Many people are scared of games being released for only one card, and/or having to write a game for only one card. I don't think anyone wants that to happen. Standards mean more competition, more competition means higher quality and lower price at a faster rate. Defining a standard for procedural, hardware implemented functions will be key in advancing realtime 3D further. Image based textures are eventually going to be phased out for most purposes (as seen with trends relating to high-end 3D and the trickle down effect into realtime) and a standard makes it infinitly easier. There are many other applications, such as acceleration of non-realtime rendering, which is also a very big deal, and vastly accelerated and much more realistic previews in 3D applications. 3D Studio has already started to do this a little bit and it looks great.
This Wiki Feeds You TV and Anime - vidwiki.org
While it might be true that DX8.0 added a lot of features that only worked on the Geforce3 back then, the new Radeon 8500 supports all those features just fine as well.
DX8.1 adds new features only available on the Radeon 8500, but a new NVidia card will be able to run all that just fine as well.
The plan is for this to continue in this fashion, so the next NVidia card will probably support PS1.4 again (the R8500) stuff, and so forth.
This is a very different situation from OpenGL where the way to do pixelshaders is completely different on ATI or NVidia hardware, and anything you do for an NVidia card will never work on an ATI card, and not the other way around either. As far as I know the same applies to vertexshaders, and ATI still doesn't have their own version of NV_VertexArrayRange. (And they certainly need it).
On OpenGL2.0, it seems like an interesting plan at first (I'm always open for API innovation), but atleast for gaming it doesn't seem to be a very interesting API, and not very forward thinking either. For example keeping the framebuffer blend out of the programmable pipe goes directly against what game programmers have been asking for.
In addition it seems the API would have a lot of problems running on current hardware (not to mention how long it would take for drivers to even get close to stability). OpenGL2.0 would expose model for vertex and pixelshader programming that would be completely unsupported by current hardware. This means you will have a lot of rules to follow to achieve hardware acceleration on specific hardware. When using more features you'd drop back to mostly unacceptably slow software emulation. This would either be hidden (and you could only find out by browsing PDFs hidden somewhere on some IHV site), or it would have to be exposed through some sort of caps system. (Exactly what the OpenGL crowd so seems to dislike.)
Anyway, I don't see this working yet, not for the games market, maybe for others. Best of luck to them anyway.
Jeez. Major trolling.
Or do you actually believe everything you just said?
The Structure of Array link is actually fairly interesting, but if you think about it it has no meaning to this argument. OpenGL has allows allowed you to specify seperate streams, but X/Y/Z are still bound together. That's not SOA, and not what Intel likes. When you get down to it the whole SOA thing was basically just Intel making up excuses and workarounds for poor CPU design.
In fact most modern hardware (Radeon, Geforce) will prefer it if you pack all your vertex components together, as DirectX has always worked. This all to make more efficient use of memory bandwidth.
Ofcouse that link to Paul Hsieh's site is ancient, and reflects a persons opinion of a battle that raged years ago, based on years old facts. Not all that interesting really.
Sure, that's why Linux runs so poorly on a dozen different platforms, right? :-P
Life's a bitch but somebody's gotta do it.
Once you have platform independence, you can run games on the latest, greatest hardware with less or even no rewriting. Don't think of the cards supported at one time slice, think of the hardware coming out in the next half year. Using history as an example, wouldn't it have been nice to be able to run all those old (Voodoo days) Glide-based games on your NVidia TNT(2)(ULTRA) or GeForce[23][MX|ULTRA|GTS] or ATI Radeon?
So you might lose 5% performance by targeting multiple platforms now, but you gain 200% performance when new hardware comes out.
At one time, 3DFX was threatening or suing people that wrote Glide-like wrappers around DirectX. These wrappers allowed NVidia cards to run Glide-based games. That was when NVidia was starting to threaten 3DFX's revenues, but 3DFX was still the leader in the 3D gaming market.
NVidia has already badmouthed the Kyro, telling computer salespeople that selling the Kyro is begging for irate customers -- what with all the incompatibilities that it might have, and the fact that it is an "unproven" platform. Through extensions to DirectX, it will be easier for NVidia to generate deliberate "incompatibilities", and NVidia has the money to push game makers into utilizing the features, and the marketing force to change the market into believing these features are important.
That scenario plays out much differently if we reduce or disallow vendor extensions. I think it is worth the 5% performance penalty. As usual, peace and harmony are in our interests, but not in the interest of any business that wants to control the market.
(all percentages above are made-up; any similarity to real percentages is strictly coincidental, not to mention lucky)
-Paul Komarek
In my opinion, if you're comparing DirectX and OpenGL then you're really talking about group multimedia projects, and I really think that sticking it out in C isn't the way to go for that.
I love C, but there are huge design benefits in going OO with C++. Eventually you'll get to the point where there'll be a large body of accepted base classes that should handle all the standard 3D objects you might need for a game, and then you won't have to (eg) search all over the internet to find obscure libraries in beta form just to get your program to load a model from a 3D cad program.
--------
Bleah! Heh heh heh... BLEAH BLEAH!!! Ha ha ha ha...
No, I don't. The culture at NVIDIA comes mainly from an SGI background, so OpenGL is something of a religion there. Further, unlike some companies, NVIDIA seems to understand the positive feedback effect of open APIs (just not Open Source, yet).
So, NVIDIA will have to be content with the current situation: "It runs at 30 FPS on the Radeon, but at 80 FPS on a Geforce 3!". ;-)
--- Example: ... "It's the hottest game of the year and they don't take ATI." (Sung to the toon of a Visa comercial. It's in Nvidias best intrest to make this happen. Tho maybe not in the markets best interest.
The current (OpenGL) situation is one where vendor-specific extensions are used to expose advanced functionality (shaders primarily). This means diffent paths through large portions of OpenGL based rendering engines. This is actually closer to 'NVIDIA specific' games, but NVIDIA knows that ISVs will just migrate to Direct3D where those features are properly abstracted. DirectX 8.0 has incorporated these features into the base API (and NVIDIA is just another player there, although it had a hand in defining the spec - just as it will with OpenGL 2.0).
OpenGL faces losing many ISVs unless there are standard ways to access these features. THAT is the motivation behind OpenGL 2.0. If you want strong, cross-platform 3D capabilities, do whatever you can to support OpenGL. OpenGL 2.0 looks like a great evolutionary improvement, and should continue to spank Direct3D in most respects. It certainly will in the area of Linux support. ;-)
If you're interested in OpenGL programming, there are many great resources on the web, including the The Official OpenGL Site and The OpenGL GameDev Mailing List.
299,792,458 m/s...not just a good idea, its the law!
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait