What are the alternatives?Originally Posted by Korval
1. Listen to 8 months of protracted ballyhoo and brouhaha
2. Listen to 8 months of accumulated ballyhoo and brouhaha
I'd choose the latter too. Besides, suffering community criticism during the development phase would likely have been a pointless distraction.
If you look at a fair amount of the 'ballyhoo and brouhaha' going on it's about the fact that things were changed back in Jan and no one said anything thus pissing off everyone because of the lack of feedback and community involvement, something they had previously prasied themselves for.
If, back in Jan, someone had said "look guys we can't do this because of x,y,z so the plan going forward is...", then sure you would have got some annoyance due to the lack of new API but at the same time there wouldn't be quite this feeling of 'oh, the ARB have done it AGAIN'. Indeed, from that point going forward they could have again engaged the community with regards to the new direction and what priorities we would have had.
It's the 10 months of silence, with 8 months of a new plan, which has caused the bigger problem; everything else just steams from there.
And what's happening now is that every time an ARB member comes here to discuss or explain some technical issues, the discussion immediately turns to ballyhoo and brouhaha again. "Ouch, the silence still hurts. ARB, I don't love you anymore. What did you say?"
Cut this out and paste it somewhere, so that people will read it when they try to use it! It's just like that old nVidia VBO white paper from 2003. There was written how you should do it. The API provides several ways to do things, which is fine sometimes, but it doesn't assess them. There's always one best way, and describing this best way should be part of the documentation.
It's not that this valuable information isn't there. But it's scattered around the whole web, in forums, IHV papers, tutorials... it totally depends on coincidence, if you find it.
*edit* Oh, and maybe you like to comment on the wide lines issue?
CatDog
Sorry, I didn't realize my desire to be properly informed so I can make good business decisions was such a burden. I think I will use DX the next time around, since they don't seem to mind giving out information for developers.
GL3 failed to instantly remove legacy features, but all is not lost. Bear in mind that no vendor was likely to drop support for 2.1 anytime soon, so that burden wouldn't have suddenly disappeared the moment Longs Peak shipped.
Here's how I believe the deprecation model can simplify a vendor's task over time. Deprecation is a clear warning to developers to stop using features which may be removed in the near future. As legacy features become less important to modern applications, vendors can provide backward compatibility through layering (or a separate driver) without as much concern for performance. Meanwhile new development efforts can be focused on the current feature set.
Considering that GL3+ shares a basic framework with GL2, this is actually *less* work for vendors than Longs Peak would have been.
My vision for LP was to remove the "wrong choices" from the API so such documentation would be unnecessary. While deprecation addresses some of this (e.g. don't use feature X because its going away), mutable objects remain part of the spec. Some ARB members consider this a "feature" rather than a "bug", so documentation / performance hints remain important. But they also may be implementation-specific. Not all hardware supports the same basic constructs, which is why vendors often disagree on guidance.
Well, my best suggestion is to firmly (but politely) lobby your favorite IHVs to retain support for any deprecated feature which you consider critical. No firm decisions have been made at this time regarding which of the deprecated features will actually be removed in any particular version of the GL, although its likely many/most will be removed in whatever comes next. And bear in mind that the ARB is a committee - majority rules - so make sure you lobby all the vendors, since we don't always agree. (See above comment about hardware differences.)*edit* Oh, and maybe you like to comment on the wide lines issue?
For what its worth I will offer an apology for the silence. As you might imagine the decision to change directions was not without contention, and the ARB didn't want to say anything publically until the dust had settled, lest the message become even more confused. That said, something probably should have been said sooner. I'll throw the marketing folks under the bus here.
Please believe me when I say that the ARB is well aware of the community's displeasure about the news blackout. Continuing to pound the point home in every other post isn't going to change anything, but if it makes you feel better, carry on.
Yes, but it does nothing to change the fact that the drivers will still be just as unreliable as before. At least LP drivers would have been closer to the metal, thus removing a lot of chances for implementations to screw things up.Considering that GL3+ shares a basic framework with GL2, this is actually *less* work for vendors than Longs Peak would have been.
Disregarding the question of how useful that is in practice, the fundamental problem is that this help was not what was asked for or promised. Or at least, not within the timeframe. See below.Here's how I believe the deprecation model can simplify a vendor's task over time.
Which is the single most disconcerting thing about the whole "GL 3.0" process.No firm decisions have been made at this time regarding which of the deprecated features will actually be removed in any particular version of the GL
The ARB said they were rewriting the API a year ago. That didn't turn out. Now the ARB says that they'll be removing deprecated features. Eventually. Is there any reason to believe them now? Especially when they're being so equivocating about whether deprecated functionality will actually be removed?
The simple fact of the matter is this: implementations will continue to be unreliable until OpenGL is a reasonably implementable specification. When will that be? GL 3.1? GL 3.5? GL 4.0? How many years do we have to wait before reasonable people can trust their products to the vagaries of ATi's OpenGL implementation?
Michael, the fundamental question around all of this is this simple. If you're not Id or Blizzard (IHV's always test their drivers on their games), which would you bet the life and continued success of your company on: the quality of D3D implementations or OpenGL implementations? Can you honestly and truthfully say that you're willing to bet millions of dollars and the possibility of your company going bankrupt on the functionality of OpenGL implementations over D3D ones?
The fact that the answer to this question is "no" is why the only people who use OpenGL are those who have to, not those who want to. Carmack has this love affair with Linux, just as Blizzard does with MacOS. Until the answer to that question is yes, OpenGL will continue to suffer. LP had the potential to make that answer yes, but it didn't come to pass.
Thank you.For what its worth I will offer an apology for the silence.
Korval,
There are plenty of commercial applications which depend on OpenGL. If this wasn't the case, no vendor would continue to support it, not even my employer. As imperfect as OpenGL may be, it solves problems that paying customers want solved.
If I personally had the ability to dictate the direction of the ARB, we'd be having a much different conversation right now. But I don't - I'm just one individual associated with one vendor. I share a lot of the frustration being expressed on this forum, but some of the comments being made here are so ridiculous, so over the top, that I feel compelled to defend a decision which I personally did not support.
Is GL3 what we wanted? Opinions vary, but its clearly not what many of us wanted, at least the most vocal among us. Was it handled well? Probably not - the ARB telegraphed one direction and then shifted in another without informing the community. Is it the end of the world? Again, opinions will vary. I would say no - there are some nice additions to the core, and there is still a path forward which could lead to something resembling LP in design.
Even if I could predict with 99% certainty which direction the ARB will go, I see the folly in making promises when I cannot control the outcome. If you feel that OpenGL is not for you, you need to do what's right for you. But I'm not interested in a protracted debate. I'm going to continue to write drivers and attempt to influence the ARB in a positive direction. What you choose to do is your own business.
My goal here is to lend some sanity to the discussion. I suppose its inevitable that I will become a lightning rod for criticism.
Posting Permissions
