OSNews

What exactly does OpenGL lack when it comes to hardware support? When ATI or nVidia release a new piece of silicon, why is it that the demos showcasing the new features are always written in OpenGL? Ever hear of OpenGL extensions? 6 months later, and Direct X may get the feature if ATI/nVidia loby Microsoft enough for it.

So tell me again why you believe that OpenGL doesn't support the latest features implemented in silicon?

What exactly does OpenGL lack when it comes to hardware support? When ATI or nVidia release a new piece of silicon, why is it that the demos showcasing the new features are always written in OpenGL? Ever hear of OpenGL extensions? 6 months later, and Direct X may get the feature if ATI/nVidia loby Microsoft enough for it.

Vendor-specific extensions is not the same thing as having something supported by the OpenGL spec itself. Vendor-specific is exactly that, vendor-specific. I am not aware of what specifically is lacking but I also have heard OpenGL is lagging _slightly_ behind. However, they also seem to be trying to catch up, they are starting to deprecate old features and are planning to release a new version shortly (~6 months, according to them). They'll probably try to catch up with the few lagging features after that.

Btw..doesn't DX also support vendor-specific extensions..?

Wrong. Just go to the ATI and NVidia developer portals and look for the amount of DirectX and OpenGL provided samples. You will see that DirectX wins.

Many NVidia products for developers still lack support for GLSL, just to give an example.

"Plenty of games still use it too, for example doom 3 (i'm sure there are more recent examples but i'm not much of a gamer)."

Grand Theft Auto 4, Bioshock, Call of Duty 4, Far Cry 2, Gran Turismo 5, etc etc. For more brevity: basically any game running on the Playstation 3.

Games using it on the OC are becoming a little sparse, unfortunately. But the Playstation 3 shows that Opengl need not lack too badly in the looks department.

Also wrong.

When PS3 came out. The available graphics API was OpenGL ES with CG as shading language.

Currently there is the possibility to use a lower level access to the graphics system, and on top of that, Sony released a new middleware API for PS3.

Game developers always use the best API for the target system. Portability comes on 2nd place.

Sorry, wrong. Basically no PS3 game uses vanilla OpenGL|ES as provided by Sony in the SDK. Some titles have used it for non-intensive rendering (things like HUD overlays, GUIs and menu screens), but most everyone prefers the thinner API Sony provides for intense rendering, as it provides the best performance and is more flexible in mapping to their own high-level engines. When you have your own high-level construct in place, you have access to low-level internals of the hardware, and the payoff is increased performance over several years company-wide (plus licensees), then it makes no sense having a middle-man API in between which doesn't map as well as you'd like to either the high-level construct or the low-level hardware details.

All that said, for those few games that don't push the envelope and don't have to be so diligent about performance (by design, rather than lazy programming) OpenGL|ES makes plenty of sense. I only wish Sony would finally provide an ES 2.0 implimentation.

For those who have said OpenGL does not lag Direct3D, I ask you this: How long did it take GL itself (not extensions) to adopt proper vertex buffers after DirectX had done so? The problem with extensions is that for some period of time, you must have separate rendering paths for each extension you support and for some combinations of extensions, and you must maintain this for some time even after, if ever, the extension is adopted into the mainline.

Direct3D doesn't have this problem because Microsoft takes a more-active role in defining the standard. The process of defining the next Direct3D API is akin to binding arbitration -- the stake-holders are all brought in, experts are consulted, and Microsoft has the final say about what's in and what's out. With OpenGL its a little more akin to a group discussion where no one has any real power to lay down the law. Its a benevolent dictatorship vs a (largely bickering) republic. Merits of a more self-directed society aside, the former is certainly more effective at getting things done.

Direct3D simply dominates consumer 3D software and is becoming increasingly preferred in professional software where modern features outweigh "Don't touch it! Its worked fine for 20 years!" syndrome.

In fact, the "Don't touch it!" crowd is what has been holding the OpenGL API back in terms of features the average-consumer would benefit from for many years (games, realistic modeling, and computation). Great, drastic changes were planned for both OpenGL 2.0 and 3.0, and both times those great plans were castrated by those not wanting drastic change to the API (read that as CAD/CAM developers with large, long-standing products) -- I don't blame them for not wanting to undertake such an endeavor, but the effect of their influence is that OpenGL is loosing mind-share and new products in favor of making the lives of a few rich old men easier.

OpenGL 3.0, at least, has taken some important steps to eliminate cruft and separate market concerns in the future. Firstly, there is a mechanism in place to deprecate portions of the API now -- of course, we'll see how diligent they are about enforcing deprecation and removal in conforming implementations... They've also indicated that they realize there are separate market concerns and that in the future there will exist several "profiles" grouping different capabilities, for gaming, CAD/CAM, computation -- Similar to the profiles in OpenSL or the Safety Critical subset of ES 1.1 for medical, avionics and other potentially life-or-death applications.

Frankly, I wouldn't mind seeing traditional desktop openGL being relegated to the land of academia, legacy and CAD/CAM software, and a "new" consumer-focused API born of OpenGL ES to take its place. Simply taking ES 2.0 as a base, making fixed-point support a "profile" and creating a new profile to bring its features up to date with desktop hardware wouldn't be a bad start at all.