OpenGL 3.0 Released, Developers Furious

ikol writes "After over a year of delays, the OpenGL ARB (part of the Khronos industry group) today released the long-awaited spec for OpenGL 3.0 as part of the SIGGRAPH 2008 proceedings. Unfortunately it turns out not to be the major rewrite that was promised to developers. The developer community is generally furious, with many game developers intending to jump ship to DX10. Is this the end of cross-platform 3d on the cutting edge?"

Comments

KDE?

[PacketShaper]

Everyone knows x.0 releases are Beta anyway.

OpenGL 3.1 will rock

/ducks

Re:KDE?

[Malevolyn]

I'd be careful what you say if I were you. With a name like PacketShaper you won't have it easy here on Slashdot.

Re:KDE?

[larpon]

No no no no dude...

OpenGL 3.5.9 will rock

/ducks even lower

Re:KDE?

[sharkey]

Personally, I'm waiting for OpenGL 3.11 for Workgroups.

Re:KDE?

[Adriax]

Unfortunatly once it hits version 3.14.159 it comes full circle, starting back at the beginning.

Question

[Narpak]

Is this the end of cross-platform 3d on the cutting edge?"

Probably not. As long as DX remains solely in the hands of MicroSoft; there will be use for other forms of cross-platform 3D. More so as the "none-MS" OSes continue to grow in numbers.

Re:Question

[Narpak]

Indeed. But preferably games should be possible to play without Wine. Hopefully as Linux, and other OSes, continue to get better and become more "newbie" friendly; it will become interesting for more companies to invest in Linux versions of their games.

Re:Question

[Anonymous Coward]

WINE's Direct3D sits on top of native linux OpenGL.

I don't think most developers are "furious". When OpenGL 3.0 was described as a backward-incompatible rewrite, they were a bit closer to furious. They spoke, and said they wanted backward compatibility retained a while longer. And lo, Khronos delivered, while providing a mechanism for migration to the new architectural constructs (buffer objects, shaders, moar buffer objects, moar shaders), and a way to build your code so that deprecated constructs fail.

Seriously, most people in the OpenGL community are fairly happy (though there's some grumbling over the still-wide OpenGL / OpenGL ES split).

Re:Question

[hr.wien]

That certainly isn't my experience. Most people on the OGL discussion boards were very much looking forward to the changes to the API. The previews Khronos posted in the Pipeline newsletter looked bloody amazing.

But when those previews are followed by almost a year of complete silence and then finally an API which is nothing at all like the one they promised, but rather some more spit and polish on the mess that is OGL 2.1 (much like OGL 2.0 was really just 1.6 with a new name), people got pissed off. And rightfully so.

The only ones pleased with this change as far as I've been able to gather are the CAD people wanting to continue to run their old, stale OpenGL bases code until the end of time. For new development, using OpenGL is a pain in the back side, which is why I just began bringing my renderer up in D3D10.

Re:Question

[JohnyDog]

This has however everything to with ATI and nothing really with OpenGL, as it is the hardware manufacturer who ultimately decides which capabilities will they expose in the drivers. ATI's OpenGL drivers was *always* bad, buggy, and badly performing (go on, search for some old benchmarks, you will see that ATI cards that easily outperform their NVidia counterparts in DirectX falls heavily behind when it comes to OpenGL apps and games).

The developers' expectations here was that if OpenGL 3.0 will include all the newest stuff in core spec, ATI (and Intel and others) will be forced to support them (so they can pass the certification and be able to call their products compliant), however the same expectation for improved OpenGL drivers was there when ATI was bought by AMD, and that too never really materialized. ATI simply doesn't care enough about OpenGL, their main focus was always DirectX, and i don't see that changing in nearby future.

As for OpenGL 3.0, the rage is that Khronos group promised us moisty delicious cake (whole new API, yay!), but after long long wait delivered only small biscuit. I didn't expect much so i'm not disappointed and overall the spec is good step (deprecation model for lots of old stuff, FBO finally promoted to core, direct access extension), but just like KDE 4.0, it is only first step, and it *really* depends on where it will go from now.

Re:Question

[Anonymous Coward]

That's most of the problem though... they did rewrite OpenGL, then they scrapped it. So in the process, we got a few years of the new version not existing. And a year of communication (from ARB/Khronos) not existing, particularly frustrating after they'd spent the previous year saying they were going to work on communications and transparency.

Even better, GL2 was supposed to be a cleaned up API, so this was the second time they promised a rewrite and scrapped it.

So either they were completely wrong about the justification for the rewrite both times (which doesn't bode well for the group in charge of the API) or we are missing out on the benefits the rewritten API would have provided.

Probably the biggest problem was the communications though, if they'd admitted the problems as they happened, there probably would have been less backlash. As it is, everyone was still pretty much expecting the original 3.0 design, so not getting that, on top of a year's worth of promised status updated, on top of the previous poor communication the promised status updates were supposed to fix, on top of the promised-then-scrapped 2.0 update, etc. leads to unhappy community.

(For those not following the situation, advertised benefits included:

simpler api = simpler drivers = better conformance + fewer driver bugs

new object model = less need for consistency checking in drivers = faster drivers with fewer bugs

getting rid of outdated code paths = easier to understand the api, easier to tell what will be fast

probably some more I forgot)

Re:Question

[DGolden]

the legacy crud that plagues OpenGL.

Did you read "the deprecation model" (appendix e) of the OpenGL 3.0 spec? OpenGL 3.0 apparently provides for a mode (a "forward compatible context") that helpfully excludes deprecated "legacy crud".

This sounds very handy for people trying to update codebases - they can presumably switch to a forward-compatible context, do a build, see what breaks.

Re:Question

[ameline]

Imagine you were the owner of a CAD or Animation software company. I suppose that when you have multiple OpenGL apps each with 10s of millions of lines of code, it's pretty hard to justify a rewrite from a business standpoint. Those "old stale" code bases each generate 100s of millions of dollars each year, and they're orders of magnitude larger and more complex than games. It would take millions of $$ to port one of the major OpenGl apps to another API, and from a business standpoint, those $$ would be wasted -- they wouldn't be doing anything other than chasing someone else's aims and objectives -- not doing anything that would generate a decent return on the investment.

Your customers don't care what the underlying API is that you use -- what they care is that you solve their problems in a cost effective way. If OpenGL3.x was a complete and incompatible break -- these companies would think "well if those a$$h0les are going to make us rewrite the software, we might as well jump to DX instead and be done with it" (At least if you don't have to support mac and linux).

It's not too hard for people to figure out who I work for so let me add that these are my opinions only -- my employer may share them, or they may not -- I certainly make no representations in this -- but these opinions are mine.

Re:Question

[DGolden]

most likely for a very long time to come as well

Seems rather FUDy... Why introduce a deprecation model if not to encourage people to the more OpenGL ES like nondeprecated bits? Yeah, you still can call glBegin/End, but it'll presumably hiss nastily at you.

I just don't see it as "layered on top", particularly - you do things the new way if you want your code to run in forward-compat mode. It's "beside" rather than "on top".

(certainly unlikely to be "layered on top" at the driver sources level, would be inverted if anything - any old fixed pipeline functionality emulated with programmable hardware.)

Bit of a book-scam though. Whole 'nother round of red/orange book purchases...

Re:Question

[hr.wien]

The problem here isn't the actual implementation of the old fixed function pipeline. That has been emulated with shaders for yonks already.

The problem lies in the state machine at the core of OpenGL. This will have to be there no matter what "deprecation level" you're running at and I can't imagine the IHVs will implement a standalone version of that for each of these levels. The result is that every feature will impact others since they interact with the same core system, enabled or not. IHVs will have to hack up their currently stable code to add OGL "3" support, and they will break things in the process.

What really breaks my heart is that OGL2 could "easily" be layered on top of the original GL3 they proposed. That way they could take care of backwards compatibility while still providing lean and mean drivers for the rest of us. The other way around isn't nearly as easy though (if at all possible), and will do jack squat for driver simplicity.

Re:Question

[binarylarry]

What's that?
Wine Isn't aN Emulator?
No way!

Re:Question

[Anonymous Coward]

It's not too hard for people to figure out who I work for so let me add that these are my opinions only -- my employer may share them, or they may not -- I certainly make no representations in this -- but these opinions are mine.

Jesus Christ, why don't you just change your last name to match your company's and be done with it? Do they own you? Do you feel the need to make a similar disclaimer every time you take a dump?

Excuse me, folks! I just wanted to let everyone else in the bathroom know that this stink is not the fault of my employer! My employer does not necessarily have as much gas as I do!

Are you worried that your masters will punish you? If so, I suggest that you reconsider your loyalties.

Re:Question

[Skrapion]

That's right, WINE is not an emulator. It just, uh, "approximates" the Win32 libs.

"Approximates?" No, that's not right. Simulates? Imitates? Hmm... if only there was a word for something that attempts to perform a task in an identical way to something else.

This can't be good.

[SanityInAnarchy]

Jumping ship to DX10 would be nice, if it were cross-platform. (No, Xbox + PC does not count as "cross-platform".)

Unfortunately for those of us on Linux/Mac, a lot of Windows developers don't care.

Unfortunately for those of you who think you don't care about this, consider that porting an app generally improves it, and can shake out bugs which aren't as apparent on the other platform -- which means potentially less reliable games, even if you're only on Windows.

And unfortunately for those of us who hate Vista, that's kind of a requirement for DirectX 10. At least with OpenGL, those in charge have no agenda to push Vista -- so an OpenGL 3.0 game should run on XP, if it runs on anything.

Re:This can't be good.

[commrade]

Gallium3d will enable just that. The Wikipedia page even mentions DirectX and wine.

That said, I don't think the uproar over OpenGL 3.0 is as widespread as the summary would have you believe. OpenGL's grave will likely be right next to Unix, X, vi and C (ie. no time soon).

Is this the end?

[Anonymous Coward]

jump ship to DX10

And when they do they wander into Direct/Input/Sound/Video/Play/etc. OpenGL does 3D rendering. The rest? Cobble it together from whatever other obsolete scraps are available.

The non-Microsoft "stacks" suck. Bottom line.

The concept of a 2D "layer" still hasn't impinged on the basic SDL API. Couldn't believe it when I learned that.

I guess professional game developers don't care that Microsoft owns the machinery of their livelihoods. They sure aren't contributing to their own independence in any noticeable way.

Re:Is this the end?

[Anonymous Coward]

Sorry my anonymous brethren, but you're exaggerating a bit. First off, DirectDraw (DirectX 2d API), DirectInput, and DirectPlay are all deprecated for other APIs. Granted, the other APIs are Microsoft but even they aren't always consistent across MS platforms. For example, DirectInput is replaced by one API on the 360 and a different one for the PC.

SDL handles cross-platform input and some basic platform functionality on the open side. Not that you could expect it to run on a console, but it should run on a Mac, Linux, or Windows.

The open equivalent of DirectSound is OpenAL, which looks a lot like OpenGL in usage. Of course, that's more of a negative, since they both need an overhaul. It *is* cross-platform and supports 3d sound though.

The other APIs aren't nearly as important for game development.

Err, yeah.

[Penguinisto]

Heh - Games developers may have that luxury, but 3D/GC vendors certainly don't. So unless someone decides to port DX10 to OSX (*snort*) or Linux (sing it with me now: "render farms!"), OpenGL will continue to have a decently-sized userbase for a very long time.

IMHO, anyone making the claim that they're going to suddenly jump to DX10 is only making noise; nobody is dumb enough to cut off the fastest-growing consumer market sectors.

(...besides, doesn't the PS3 use OGL, or do they use some other home-brewed library set? Not sure there...)

/P

No it doesn't

[Sycraft-fu]

Part of the reason for DX's success is that nobody else seems interested in developing anything to compete with it. OpenGL is the only cross platform 3D API I'm aware of and it and DX are all that there is these days. GLs problem is that it isn't keeping up with the hardware. The "just use vendor specific extensions" isn't a realistic solution in most cases. Thus GL is suffering and DX is winning by default.

If someone like Apple did develop a good 3D API, it might do well. However nobody seems interested.

No.

[unity100]

Is this the end of cross-platform 3d on the cutting edge?

it isnt. because OpenGL ARB is gonna play it nice, and revise their specs, therefore pleasing developers and therefore GAMERS as much as they can, and fix the matter, wont you now ? dont make us wait.

Re:OpenGL falling down a pit

[Ynot_82]

"The library needs to be able to interoperate with current and future video hardware, so that all hardware acceleration features will be available to applications using the 3D library..."

Now, I know next to nothing about the nitty-gritty details of OpenGL or DirectX,
but I really thought they were pretty much equal (in terms of being able to fully utilise the hardware)

I was under the impression that MS wrote the DirectX API, and graphics hardware was expected to provide in interface to GPU operations as per MS's API spec

On the flip side, OpenGL being less centrally controlled,
instead graphics hardware provide their own API calls for new GPU operations, and provide this new API call to OpenGL via it's "extension" interface
and every so often, the OpenGL spec would be updated, with new GPU functions (currently using seperate, per-vendor extensions) would be standardised into a single implementation

Are developers really saying that OpenGL cannot do things DirectX can?
I thought as long as (say) Nvidia kept provided drivers, and software kept querying for the hardware's capabilities, DirectX & OpenGL were pretty much on a par with each other....

Can anyone provide a semi-layman's explanation?

Re:OpenGL falling down a pit

[hr.wien]

You don't fork a spec. You create a new one and try to get it accepted by the industry (ATI, Nvidia and Intel in this case).

Good luck with that.

The Chicken and the Egg

[westlake]

Hopefully as Linux...continue to get better and become more "newbie" friendly; it will become interesting for more companies to invest in Linux versions of their games.
.

Vista is approaching 20% of the market. Top Operating System Share Trend You can't expect expect Linux ports if entry level DX9l/DX10 outperforms OGL.

Re:The Chicken and the Egg

[Anonymous Coward]

That's measured from visitors to thousands of sites, including many large mainstream websites. So that'd be computers in use, not licenses sold. Yep, Vista adoption is going even better than XP's did back in 2001, and no, not everyone gets rid of Vista for XP (I'm very happy with upgrading from XP to Vista myself -- no plans on ever downgrading to XP). Not that anyone here would admit to that...

GL is doomed in the short-to-medium term...

[Hortensia Patel]

...and probably irrelevant in the longer term.

This is not the first time this has happened. GL2 was also supposed to be a cleanup, but turned out to be anything but. This latest fiasco is more significant as a failure of governance than of technology. All the right ideas were there; they were published in some detail over a year ago in the Pipeline newsletters. But the ARB very obviously a) can't agree to get anything meaningful done, and b) now has subzero credibility with developers. It's not coming back from that.

So yes, I think cutting-edge cross-platform 3D is dead for the next 2-3 years. Let's face it, it was never exactly healthy. It's not the end of the world. Linux share is currently growing mostly at the low end, netbooks etc, while the Mac seems to be thriving despite the fact that Apple doesn't give a flying fsck about gaming and never has.

Fast forward a couple of years, though, and things like Larrabee will be hitting the market; embarrassingly parallel hardware that can be programmed with standard languages and tools. The API's role as gatekeeper of functionality will be gone. And suddenly, 3D rendering libs can be written by anyone with the time and expertise, without having to go through Microsoft or the ARB or NV or AMD/ATi or Intel or anyone. Experimentation, competition, cross-fertilization, evolution. Remember Outcast's voxel engine? Seen things like Anti-Grain? This will happen.

(Or, yes, people could just reimplement the DXwhatever API directly, but that would be a little disappointing.)

Today was not a good day, by any stretch of the imagination. But it's not the end.

OpenGL is NOT only games

[janoc]

Folks, I do wonder when someone realizes that OpenGL is not only games. The only people really "furious" are some game developers in few posts on an OpenGL forum. However, please, do realize that games are typically sold for 6 months and supported for 1 year and 99% on a single platform (Win/XBox). Very few things are developed as cross-platform - and it is NOT because of OpenGL, more like commercial realities (cross-platform development is hard and doesn't make a lot of sense for ~2-3% of the market, especially for an app that will be sold for one season).

Professional apps (CAD/simulators/visualizations...) make up the majority of the OpenGL market and they have to be supported for decades (no, military or airlines do not buy a new training system every two years ...)

So breaking compatibility is deal breaker. This is exactly what OpenGL 3.0 is about. I am developing OpenGL applications for a decade now and all are still running and being used. How many 10 year old games can you actually get working today? God forbid - on Vista? That is the difference.

Also, the "newest features not supported by OpenGL" - how many "newest features" are your typical games actually using? Perhaps one or two and they are optional, because the game must run even on not bleeding-edge hardware (how many games are DX10-only? - commercial suicide ...)

So to wrap this up - the title is EXTREMELY misleading and making up a storm where one doesn't exist.

Re:people still make opengl games?

[HappySmileMan]

From an interview LESS THAN A MONTH AGO:

MPC: So, you said Rage is a 60Hz game. Is it an OpenGL or DirectX game?

JC: Itâ(TM)s still OpenGL, although we obviously use a D3D-ish API [on the Xbox 360], and CG on the PS3. Itâ(TM)s interesting how little of the technology cares what API youâ(TM)re using and what generation of the technology youâ(TM)re on. Youâ(TM)ve got a small handful of files that care about what API theyâ(TM)re on, and millions of lines of code that are agnostic to the platform that theyâ(TM)re on.

MPC: Are you using DirectX 9 equivalent? For Doom 4 as well?

JC: Yes to both. Itâ(TM)s one of those things I get asked a lot. Whatâ(TM)s big and exciting for DirectX 10 or DirectX 11? Thereâ(TM)s not a whole lot of⦠really not a whole lot. The big touted geometry shaders were in many ways, a mistaken belief that people desperately wanted to create stencil shadow volume.

So less than a month ago John said that he's still developing with OpenGL and that DX10 isn't really a worthwhile improvement.

And congratulations on referring me to something he said ages ago, when you find something more recent feel free to reply

Oh and source of interview: http://www.maximumpc.com/article/features/e3_2008_the_john_carmack_interview_rage_id_tech_6_doom_4_details_and_more?page=0%2C0

Re:Um, DUH!!! Who own OpenGL now?

[49152]

Please stop modding up this troll.

That article is 6 years old.

Most of those patents are hardware patents totally irrelevant for OpenGL (or Direct3D for that matter).

Also, Microsoft is not a member of the group that actually writes the OpenGL specification. They have no vote on what gets in OpenGL or don't.

Of course this might give them leverage on some of the hardware vendors (like Nvidia) that will have to implement the new OpenGL standard in the future. But history does not show them trying to use this in any way against OpenGL.

But claiming they "own OpenGL" is nonsense.

Explanation from OpenGL ARB Working Group Chair

[kmike]

Basically they've got tangled in the implementation details and decided to play it safe with OpenGL 3.0 instead of starting from scratch.

========
What happened to Longs Peak?

In January 2008 the ARB decided to change directions. At that point it had become clear that doing Longs Peak, although a great effort, wasn't going to happen. We ran into details that we couldn't resolve cleanly in a timely manner. For example, state objects. The idea there is that of all state is immutable. But when we were deciding where to put some of the sample ops state, we ran into issues. If the alpha test is immutable, is the alpha ref value also? If we do so, what does this mean to a developer? How many (100s?) of objects does a developer need to manage? Should we split sample ops state into more than one object? Those kind of issues were taking a lot of time to decide.

Furthermore, the "opt in" method in Longs Peak to move an existing application forward has its pros and cons. The model of creating another context to write Longs Peak code in is very clean. It'll work great for anyone who doesn't have a large code base that they want to move forward incrementally. I suspect that that is most of the developers that are active in this forum. However, there are a class of developers for which this would have been a, potentially very large, burden. This clearly is a controversial topic, and has its share of proponents and opponents.

While we were discussing this, the clock didn't stop ticking. The OpenGL API *has to* provide access to the latest graphics hardware features. OpenGL wasn't doing that anymore in a timely manner. OpenGL was behind in features. All graphics hardware vendors have been shipping hardware with many more features available than OpenGL was exposing. Yes, vendor specific extensions were and are available to fill the gap, but that is not the same as having a core API including those new features. An API that does not expose hardware capabilities is a dead API.

Thus, prioritization was needed, and we made several decisons.

1) We set a goal of exposing hardware functionality of the latest generations of hardware by this Siggraph. Hence, the OpenGL 3.0 and GLSL 1.30 API you guys all seem to love ;\)

2) We decided on a formal mechanism to remove functionality from the API. We fully realize that the existing API has been around for a long time, has cruft and is inconsistent with its treatment of objects (how many object models are in the OpenGL 3.0 spec? You count). In its shortest form, removing functionality is a two-step process. First, functionality will be marked "deprecated" in the specification. A long list of functionality is already marked deprecated in the OpenGL 3.0 spec. Second, a future revision of the core spec will actually remove the deprecated functionality. After that, the ARB has options. It can decide to do a third step, and fold some of the removed functionality into a profile. Profiles are optional to implement (more below) and its functionality might still be very important to a sub-set of the OpenGL market. Note that we also decided that new functionality does not have to, and will likely not work with, deprecated functionality. That will make the spec easier to write, read and understand, and drivers easier to implement.

3) We decided to provide a way to create a forward-compatible context. That is an OpenGL 3.0 context with all deprecated features removed. Giving you, as a developer, a preview of what a next version of OpenGL might look like. Drivers can take advantage of this, and might be able to optimize certain code paths in the forward-compatible context only. This is described in the WGL_ARB_create_context extension spec.

4) We decided to have a formal way of defining profiles. During the Longs Peak design phase, we ran into disagreement over what features to remove from the API. Longs Peak removed quite a lot of features as you might remember. Not coincidentally, most of those features are marked deprecated in OpenGL 3