The ARB announced OpenGL 3.0 and GLSL 1.30 today

OpenGL
61

To be fair, LP was “opt-in” so no existing code would break.

62

[censored] [censored] [censored] [censored] [censored].

63

[censored] [censored] [censored] [censored] [censored].

Don’t hold it back, Foo bar, tell us how you really feel :wink:

64

So how is this going to affect OpenCL?

Perhaps I am missing something but isn’t CL going to now have to be interfaced to a pretty old API, instead of a bright new shiny one - which could then be integrated at inception, rather than patched to an old system?

Or is the buzz over OpenCL, and it stealing GPU cycles for other stuff, now also causing Khronos to dilute it’s attention to the point it breaks both?

Or is CL and 3.0 going to be the next big milestone?

65

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 :wink:

  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.0. The disagreements happened because of different market needs. For some markets a feature is essential, and removing it will cause issues, whereas for another market it is not. We discovered we couldn’t do one API to serve all. A profile encapsulates functionality needed to meet the needs of a particular market. Conformant OpenGL products may implement one or more profiles. A profile is by definition a subset of the whole core specification. The core OpenGL specification will contain all functionality, including what is in a profile, in a coherently designed whole. Profiles simply enable products for certain markets to not ship functionality that is not relevant to those markets in a well defined way. Only the ARB may define profiles, individual vendors may not (this in contrast to extensions).

  5. We will keep working on object model issues. Yes, this work has been put on the back burner to get OpenGL 3.0 done, but we have picked that work up again. One of the early results of this is that we will work on folding object model improvements into the core in a more incremental manner.

  6. We decided to provide functionality, where possible, as extensions to OpenGL 2.1. Any OpenGL 3.0 feature that does not require OpenGL 3.0 hardware is also available in extension form to OpenGL 2.1. The idea here is that new functionality on older hardware enables software vendors to provide upgrades to their existing users.

  7. We decided that OpenGL is not going to evolve into a general GPU compute API. In the last two years or so compute using a GPU and a CPU has taken off, in fact is exploding. Khronos has recognized this and is on a fast track to define and release OpenCL, the open standard for compute programming. OpenGL and OpenCL will be able to share data, like buffer objects, in an efficient manner.

There are many good ideas in Longs Peak. They are not lost. We would be stupid to ignore it. We spent almost two years on it, and a lot of good stuff was designed. There is a desire to work on object model issues in the ARB, and we recently started doing that again. Did you know that you have no guarantee that if you change properties of a texture or render buffer attached to a framebuffer object that the framebuffer object will actually notice? It has to notice it, otherwise your next rendering command will not work. Each vendor’s implementation deals with this case a bit differently. If you throw in multiple contexts in the mix, this becomes an even more interesting issue. The ARB wants to do object model improvements right the first time. We can’t afford to do it wrong. At the same time, the ARB will work on exposing new hardware functionality in a timely manner.

I want to ask you to take a deep breath, let this all sink in a bit, and then open up the OpenGL 3.0 and GLSL 1.30 specifications we just posted that have all new stuff clearly marked. Hopefully you’ll agree with me that there’s quite a lot of new stuff to be excited about.

http://www.opengl.org/registry/doc/glspec30.20080811.withchanges.pdf
http://www.opengl.org/registry/doc/GLSLangSpec.Full.1.30.08.withchanges.pdf

This is certainly not the end of the OpenGL API. OpenGL will evolve and will become better with every new revision. I welcome constructive feedback.

Regards,
Barthold Lichtenbelt
OpenGL ARB Working Group chair

66

ive quickly put together a little ditty
http://www.zedzeek.com/MUSIC/ogl.mp3

I quite like the 2nd part, 1:30-> does it remind anyone of anything (dont wanna be accused of plagarism) I may use it in a song

67

I prefer to look at things from the bright side: hey, now OpenGL2.1 doesn’t look so bad :).
/ducks

I can’t comprehend why the CAD community would need OpenGL3 in this crippled state, when deprecated API will be butchered soon. I’ve had my share of porting/upgrading to a newer/another API, and drastic changes were more welcome than subtle unreliable ones. The 2.1 will continue to be maintained, so stay there. Or is it marketing reasoning?

The spec seems to make GL3 look worse than it is. An OpenGL3-only spec is due. Plus info which features really are available in SM2/3 cards - like the varying interpolation type (wasn’t it introduced in SM4? ).

Semantics in the shader code, and being able to mix+match are important things that should have been there. Compiler API, too.

Oh well, 2.1 stays, cgc.exe is there with Radeon support, ATi fix things quickly, nVidia don’t break too much code with every new driver, we have 5 years of proven working code, users aren’t crazy about new gpus - so it’s not that bad that ATi don’t provide geometry-shaders, Intel’s current stuff is unusable for games (thus isn’t a target), larawasp will be late and expensive and as common as a physics-card, raytracing takes weeks to prepare the kd-trees of scenes and will be even less common than larabee. And we don’t need to hope/wait for improvements in GL anymore!
Those that jump ship for DX10… good luck with the market, guys. Hope the userbase is ready when you ship a title.

68

Yes, it does now.

In Table N.1, the specification lists a couple of name changes:

MAX_CLIP_PLANES to MAX_CLIP_DISTANCES
CLIP_PLANEi to CLIP_DISTANCEi

However, these haven’t been changed in the document, and surely these are separate things anyway, and need updated documentation?

They are reusing the same piece of state for a different purpose when running GLSL 1.30 shaders, thus the aliased names. Once the fixed-function pipeline is fully deprecated the old names will go away, until then both names exist.

Also, Appendix O: ARB Extensions doesn’t include the new extensions listed in registry.

Yes, it’s somewhat out of date. Not on the top of my priority queue TBH, but I’ll get to it.

69

I have to say I am disappointed. I was all psyched up to do a GLIntercept2.0 - but it seems that will be the sole domain of gDebugger now. I also had lots of ideas for other tools I wanted to write.

I think I will take a break - learn some more of the competing API - and possibly come back when the dust settles.

As other people have said - I fail to see why CAD developers need a new API - could they not have kept it separate like OpenGL-ES 1.1 vs 2.0?

70

LOL zed.
Do you do requests? :wink:

Barthold, thanks for the response.
It still is depressing though.
Most all of us just expected allot more. :frowning:

71

Re: http://www.opengl.org/registry/specs/EXT/direct_state_access.txt

funniest thing i’ve seen all day.

OpenGL extension specifications aren’t generally contenders for the designation “funniest thing I’ve seen all day.”

I’m clearly going to have to re-read it again; I must have missed the funny part.

every function that relies on a client selector gets a new entry point.

That’s certainly the gist of the extension.

Saying “client selector” isn’t quite right however. Just one selector is client state (glClientActiveTexture); all the others are technically considered OpenGL server state.

And while most of the functions introduced are new, when a suitable indexed version of a function existed, such as using glEnableIndexedEXT for glEnable(GL_TEXTURE_2D), the existing indexed function was used instead of introducing a new one.

I hope this helps.

  • Mark
72

I should also add that one of the things I think I will miss is this community - I don’t know of any other technical forum that has the character and the relevancy as this one.

73

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

I didn’t see a number associated with your decision to keep all decisions from the public. We would still complain but it definitely would have staved off this bomb.

I even see a tiny bit of hope: It only took you one day to “prepare” the purple colored spec which already gives more insight into at least the real changes from 2.1. But we’re still missing the back story on a lot of the decision making processes. “Profiles” seem nice in a fun world of incompatibility but relying on the ARB for them? Funny!

74

I’d have given GL3 a chance if these 3 features (which do exist in hardware) weren’t butchered:

  • alpha-test. Ok, can be put in the shader. Fork the shader in two. SM4 and SM5 cards will need to generate a second shader for this?
  • GL_CLAMP on texture-wrapping. Again can be put in the shader, and may be caused again by SM4 and SM5 cards’ limits.
  • wide lines. Uhoh. So-long, green grass, explosion/fast-particles gfx, perfectly-antialiased edges, and future creativity.

Wide lines can’t be created optimally, especially when there’s no geometry shader. And afaik, CAD apps do need them.

75

OpenGL extension specifications aren’t generally contenders for the designation “funniest thing I’ve seen all day.”

I found issue #27 quite amusing: What feedback has Id Software given on this extension?

Carmack: “This should have happened a long time ago.”
Cass: “It’s a lot of entry points. Can this be put into numerical terms?”

That summed up the extension for me. Korval nailed it: It doesn’t really matter until it’s core because ATI/Intel won’t support it. But hey, go get 'em nvidia.

76

This situation is a bit of a tragedy. If anyone here thinks that the big players can’t wait to throw out the legacy cruft in the spec then they’re sorely mistaken. Read the deprecation model section in the spec. They’re itching to get rid of this crap.

Look at how clean OpenGL ES 2.0 and the associated glslang is.

It suspect it was excessive caution over how developers might react that stopped this happening and it looks like it backfired big time.

Apply the deprecation to this and it’s pared to the bone & very like OpenGL ES 2.

As for the driver rewrite, drivers have already been rewritten many times over, the biggest part of your driver is geared towards cached index array rendering and shader compilers, and the compilers are on their 5th generation or so.

You don’t need a rewrite to throw the cruft out. For almost all implementations the fixed function state driven engine sits there as a code stitcher that you can throw away, hardware forced this a LONG time ago. The legacy data wrangling is software.

Oh and Larabee? I think we have a Godwin’s law for graphics now, relating to the time it’ll take some bullshitter to bring up Larabee in any discussion on graphics as the solution to the problem.

The perception here is the reality, I hope someone stands up at the BOF and says we’re going to have 3.1 in a month and it’ll excise every deprecated feature in this spec, and make objects core, naming your own handles is deprecated anyway.

Clean 3.1 drivers could probably be pushed out inside a month from a 3.0 driver, they should just do it ASAP and make today look like a bad memory, if it’s not too late.

77

The very point of the forward compatible context mechanism in 3.0 is to allow the developer to operate their app in a mode where deprecated functions are disabled (for use as a porting tool).

So at a point in time where GL 3.0 drivers are available, if you are thinking of updating your app for the anticipated post-3.0 release where deprecated functions are actually removed - you can start that work using 3.0 and see it run.

Some implementations may actually realize performance benefits in that mode since elimination of legacy functions can also lead to elimination of state tracking for those functions.

78

Yes, but from the spec you have to discern the intent before you know what the hell is going on. Which has led to this political disaster. You need to put a stake through the heart of that 2.x cruft by releasing a 3.1 spec ASAP that makes it clear this stuff is gone. Not might be gone in some future release, but end of life, pining for the fjords. Start potring or die. GONE in the next revision.

From aesthetic and educational purposes alone it’s justified.

79

Will there be a GL3-without-the-deprecated-stuff spec?
Will there be a GLX_ARB_create_context? If yes, when?

Philipp

80

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

Well that failed pretty miserably, didn’t it.

D3D 10 had one major defining feature: geometry shaders. Oh, it had other stuff to be sure. But that was the “big deal” of D3D 10; it was the main thing that differentiated it from D3D 9.

So, where are they in OpenGL “3.0”? Oh, an extension? How is that different from yesterday?!

If GL “3.0” doesn’t even have the most widely mentioned (if not entirely useful) feature of D3D 10, how can you possibly say that you met the goal of “exposing hardware functionality of the latest generations of hardware?” Or do you expect partial credit for half-finished work?

GL “3.0” fails on two levels. It fails to do what Longs Peak was supposed to. And it fails to do what a regular core revision was supposed to (add support for new hardware).

Second, a future revision of the core spec will actually remove the deprecated functionality.

Longs Peak was the second effort to remove functionality from OpenGL, to modernize the API. It failed. I would make an entire list of the failures that the ARB has perpetrated on OpenGL, but I don’t think this web page is long enough.

I would love to hear one reason, just one good reason, why we should trust anything the ARB has to say about removing functionality from OpenGL. Or anything for that matter.

There is no trust relationship between OpenGL users and the ARB anymore. The only thing we can trust the ARB to succeed at is spectacular failure.

An API that does not expose hardware capabilities is a dead API.

An API that doesn’t provide a proper hardware abstraction isn’t exactly lively either.

In January 2008 the ARB decided to change directions.

So, when was it decided that you would tell us nothing about it? I’m guessing that it was at the same meeting, but it’d be nice to have confirmation on that.

Those kind of issues were taking a lot of time to decide.

Oh, I imagine they were. I considered the options myself, just from the scraps of info that the ARB released. They’re tough.

However, there’s one very important thing that you guys failed to get: we don’t care that much. You had the big things covered. If the little details were taking a lot of time, then you simply get both sides to deliver a position paper on the subject, take a vote, and have both sides agree to accept the results.

People weren’t going to abandon GL 3.0 if it caused some minor inconvenience, like a proliferation of state objects. And because the API was object-based, if you made some poor decisions, you could always fix them by introducing a new object (of the same “type”) that fixed the problem.

Basically, you’re saying that the ARB would rather fail spectacularly than largely succeed and possibly have some small failures.

Take the C++0x Working Group as a proper example of how these things get done. There was a proposal about “uniform initialization”. It was proceeding well, getting input from contributers, and so forth. Then, someone realized that it effectively made “explicit” meaningless. There was a big argument, because part of the intent of having uniform initialization is that it works the same all the time, and explicit gets in the way of that. One side wrote a big paper supporting his side. The other side wrote a paper supporting their side. A vote was taken. One side won, the other lost. Everyone accepted the outcome and moved on towards a C++0x specification.

If they were the ARB, by the way you describe the “process”, then the two sides would have kept arguing for months until there was no time to get the proposal in any form into the spec, and thus it would be cut. That’s not acceptable.

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.

Yes, but the overriding concerns outweigh any of those arguments: OpenGL is too complicated a spec for someone to reasonably implement and maintain without excessive effort. That is, more effort than it is really worth. That was the #1 reason that Longs Peak was started to begin with. To make an OpenGL that would be much more implementable and maintainable.

Since that was design goal #1, it automatically trumped all other concerns. In a disciplined design setting, suggestions that would go against the primary design goal of the whole thing would be thrown out a priori, because such concerns would have already been listened to back when it was decided to embark on the process.

That will make the spec easier to write, read and understand, and drivers easier to implement.

Wow, hey, I remember the ARB talking about something that would make the spec simpler and make drivers easier to implement. What happened to that? Oh yeah, you decided not to. Twice! :mad:

Is the whole “lack of trust” thing starting to sink in? Fool me once, same on you; fool me twice, shame on me.

Hopefully you’ll agree with me that there’s quite a lot of new stuff to be excited about.

See, it’s funny. We had access to all of that yesterday, through extensions and whatnot. Others of us had D3D10 that we could have used to access those same features.

OpenGL 3.0 wasn’t supposed to be about functionality; it was about form. We were supposed to have an API that could run on R300/NV30 hardware, that was simple enough to implement to actually trust that Intel would do so, and so on. That was what got people excited about GL 3.0, and it’s gone now.

Is GL “3.0” going to help OpenGL users get better drivers? No; in fact, with all the added complexity of profiles and so forth, drivers will be worse than ever. Will it remove needless overhead? No; you still have to use object names (which requires a mapping table and other overhead to use), and you still have to bind them to change them (experimental extensions not withstanding).

In short, nothing that was ever promised with OpenGL 3.0 came to pass.

We can’t afford to do it wrong.

If you can afford to do nothing, then you can afford to do it wrong.

This is certainly not the end of the OpenGL API. OpenGL will evolve and will become better with every new revision.

OpenGL as an API is dead, not because of lack of functionality, but because nobody who uses it does so because they want to use it. The only rational reason to use OpenGL over D3D now is because you have to. If you’re developing a Linux or MacOS product. Or if you have need of some esoteric feature that other APIs don’t support. Or if you’ve got a poorly written codebase with GL commands everywhere that you can’t afford to rewrite. Anyone else who uses OpenGL over D3D is making a statement against Microsoft (and thus not preferring GL), completely ignorant of the alternatives, or simply a fool.

Nobody uses OpenGL because they like it, outside of a very small number of hobbyists. And that’s something that the ARB should have been paying more attention to.

I welcome constructive feedback.

A quote comes to mind: “You know, in certain older civilized cultures, when men failed as entirely as you have, they would throw themselves on their swords.” That’s about as constructive as I can get.

Eventually, it’s time to stop the CPR. It’s time to accept the inevitable. Time to type “GG” and accept your shame. Stop trying to breath life into that which is clearly dead. OpenGL was once a proud beast, full of life and vigor. But now it’s rabid and has to be put down. Better for it to happen quickly and by those who loved it than to watch it waste away.

“It’s dead, Jim.”