Toward Version 4.3

Rewrite the specification so that the extensions that are used to patch deficiencies in the current API become needless. How? Rewrite some parts of the spec. Which parts? The shader API in particular, get rid of the program pipeline hack, and borrow some good ideas from D3D shader attribute and uniform specification…

Thanks ARB.

And thank you for trotting out the same tired old ideas that always get trotted out on this forum. Your contribution to the noise in this forum is appreciated.

I may be repeating the same ideas…but let me guess something, this forum is for…feature suggestions right? And suggesting something once does not really help much. We need a way to keep the idea active. But it seems that regardless of whatever feature is suggested here, we always get the same noise and panic from someone, negative criticism!

What do you mean by Program Pipeline hack?

http://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt

A problem that could have been easily corrected by rewriting a little part of the specification instead.

You see the problem is that extensions are being abused, so they are now for patching a problem with the core specification instead of only adding features. Some add more complexities to the API pipeline instead of enriching it.

Yes, I am perfectly aware of this extension. What do you mean by “rewriting a little part of the specification”? What about backward compatibility? It is not so simple as you may think.

What about backward compatibility?

So sacrifice the proper development of OpenGL for the sake of backward compatibility? I thought backward compatibility is already solved by the compatibility profiles?

It is not so simple as you may think.

I don’t think it’s simple, but it’s pretty possible. :slight_smile:

No, it’s not. What you’ve suggested would have broken compatibility between OpenGL 4.0 core profile and OpenGL 4.1 core profile which is undesired.

No, at least not how you imagine.

I don’t say program pipeline objects are the best invention ever but seriously, what makes you think that they are evil?

No, it’s not. What you’ve suggested would have broken compatibility between OpenGL 4.0 core profile and OpenGL 4.1 core profile which is undesired.

How undesired? There may be some optimization/performance benefit and therefore there’s a need to keep the option available, but if it’s not really the case, then correcting a bad design decision should be more desirable over minor compatibility issues.

I don’t say program pipeline objects are the best invention ever but seriously, what makes you think that they are evil?

Evil? Who said that? They are awesome! :smiley: But they are a hack :slight_smile:

And suggesting something once does not really help much.

Suggesting it 30 times is also not going to help. It’s negatively helpful because it drowns out other, legitimate suggestions.

Don’t you get it? The ARB doesn’t listen to anything that happens in this forum. Why? Because of people who constantly suggest the same thing 30 times. Because of people who like to keep their pet ideas “active”. This means that the only thing that happens here is people dropping random pie-in-the-sky drivel that has zero chance of ever being implemented.

Continuing to make these unrealistic demands will only make the ARB continue to ignore anything that gets said here.

http://www.opengl.org/registry/specs/ARB/separate_shader_objects.txt

A problem that could have been easily corrected by rewriting a little part of the specification instead.

I have no particular love for the ARB_separate_shader_objects specification. But here’s a reality check for you.

ARB_shader_objects, version 1.00 of GLSL, was finalized June 11, 2003. Almost 10 years ago. This is what defined the compilation model that GLSL has.

When did we get ARB_separate_shader_objects? June 9, 2010: almost 7 years to the day that GLSL 1.00 came out.

Do you think the GL community was silent about the compilation model? Do you think that ARB_shader_objects came out and everyone was like, “Hurray, we have to link our vertex and fragment shaders together, thus massively increasing compile times as well as the number of programs we need! Yay!”?

No, the community was against it from day 1. Users were against it from day 1. But ATI had no real power and NVIDIA was to busy trying to shove CG down the ARB’s throat, which left 3D Labs to basically get whatever they wanted. It took us SEVEN YEARS to get that undone.

That was 7 years of complaints. Of OpenGL falling by the wayside. Of various other bad things. Etc. It took that long just to get a minimally functional version of what we should have had from the beginning.

Here’s another reality check for you:

10 years ago, 3D Labs attempted to get the OpenGL API rewritten, with non-backwards compatible changes. That attempt failed. 5 years ago, NVIDIA and ATI tried to do the same thing. That attempt failed, and it failed at a critical time that OpenGL needed to be succeeding (ie: Windows Vista hurting DX10 adoption).

Now given these facts, do you honestly believe that your personal request is going to make the ARB say, “You know what? We tried to rewrite this API twice and both failed. But that glfreak fellow makes a good point. So let’s stop all work on the API to try to make another rewrite.” Or will they simply continue ignoring everything that gets posted in this forum?

Your suggestion is not going to be acted upon. Ever. No matter how many threads you make, no matter how many times you suggest it.

OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.

You see the problem is that extensions are being abused

How are extensions “being abused”? It’s a core extension; you support it the way you would any core feature, except that you can also use it on hardware that can’t support GL 4.x.

Under what logic is this considered “abuse”?

I thought backward compatibility is already solved by the compatibility profiles?

Um, no. Compatibility profiles are for functionality that was removed from OpenGL. You can’t just rip stuff out or replace it with new stuff. The point of backwards compatibility is that people can invest time and effort into code and know that it will work with later GL versions. That they can use new features with their older code. If I want to use shader_image_load_store, I shouldn’t have to also upgrade all of my texture creation to use glTexStorage, for example.

Even D3D doesn’t haphazardly ransack its API the way you’re talking. They only make major API changes at a major version number. And even those are not nearly as radical as they used to be.

if it’s not really the case, then correcting a bad design decision should be more desirable over minor compatibility issues.

Minor? You’re talking about radically altering the GLSL language. That’s not a “minor compatibility issue.” That’s “my shaders don’t work with GL X.Y.”

[QUOTE=Alfonse Reinheart;1236745]
It’s negatively helpful because it drowns out other, legitimate suggestions.[/QUOTE]

The ARB doesn’t listen to anything that happens in this forum. Why? Because of people who constantly suggest the same thing 30 times.

Continuing to make these unrealistic demands will only make the ARB continue to ignore anything that gets said here.

Your suggestion is not going to be acted upon. Ever. No matter how many threads you make, no matter how many times you suggest it.

OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.

Why do you keep talking on the behalf of the ARB? Are you their representative or something?
If not, please restrain yourself from pretending you are some OpenGL authority.

It is not you who defines what a “legitimate suggestion” or “unrealistic demand” is.

The OP sees problems (very valid IMO) with the current OpenGL state and does what he can - post suggestions. That’s is exactly what this forum is for.
And you? You keep telling people to stop posting suggestions because it is useless as OpenGL will never get improved. I don’t know what are you doing but it most certainly is not for the good of OpenGL.

If you say that I am getting personal, check this quote of yours first:

And thank you for trotting out the same tired old ideas that always get trotted out on this forum. Your contribution to the noise in this forum is appreciated.

It is not glfreak but you from where comes most of the noise in this forum.

[QUOTE=l_belev;1236803]Why do you keep talking on the behalf of the ARB? Are you their representative or something?
If not, please restrain yourself from pretending you are some OpenGL authority.

It is not you who defines what a “legitimate suggestion” or “unrealistic demand” is.[/QUOTE]

It’s unrealistic to ask for something that there is documented evidence that the ARB will not do. If someone tries to do something twice and fails twice, it’s obvious that they’re not going to do it.

And no, it is not me who decides what is legitimate or not. But look around: do you see any members of the ARB posting here? Commenting on suggestions? Interacting with this community in any way? Look over the history of this part of the forum. The ARB used to talk. We used to discuss suggestions.

That doesn’t happen anymore.

Maybe it’s because so many of the suggestions made are so unrealistic that they’re not worth discussing.

And maybe it’s not. But of the last 25 threads on this forum, I was only able to find 5 that I believe the ARB would even consider implementing. Most of them are things like this: obvious personal wishlist and trash.

But he’s already done’ that. And the ARB has already attempted what he has suggested and rejected it. Twice.

What good is it to constantly spam the forum with the same suggestions over and over again, when the ARB has already said about as well as it can be said that it’s not happening?

No, I tell people to stop posting suggestions that will not be implemented. What expectation is it that anything he has suggested would even be considered, given that the ARB tried twice and failed twice?

What I want is for people to stop asking for what they want. I want people to ask for something that the ARB would actually do. To stop thinking about what they would do if they were the ARB and start thinking about what the actual ARB would reasonably debate and consider.

I want people to filter their own ideas first before presenting them for public consumption. Is that so much to ask?

For example, we would all like to have a programmable blend stage. But that’s not going to happen, not with current hardware. Asking for what is not going to happen serves no purpose.

If glfreak truly wants to improve OpenGL, then he will limit suggestions to things which the ARB hasn’t clearly decided not to do. Simply saying “rip out half of separate_shader_objects and rewrite the GLSL interface to be more like D3D” is simply not going to happen.

If glfreak believes that the only way to fix the problems of OpenGL is by rewriting parts of it, then OpenGL will never be fixed for him. The sooner he accepts that, the better for everyone.

While I agree that sometimes Alfonse is a bit negative, he is right here.
Suggestions like “remove Opengl32.dll” or “rewrite <insert random feature here> in the spec even if it breaks backward compatibility between two versions of the core profile” are useless. There is definitely a need for reorganizing the spec document to better reflect modern OpenGL, but that does not necessarily mean a rewrite and especially not something that redefines the behavior of certain features, it should be rather a refactoring, i.e. language rewrite that doesn’t change behavior.
My personal opinion is that OpenGL requires the following (in priority/chronological order):
[ul]
[li]All new OpenGL software should use core profile only[/li][li]Legacy OpenGL software should (even if slowly) move to use core profile only[/li][li]Trully remove deprecated features once the critical mass of core-only software has been reached[/li][li]Do another deprecation phase (things like mutable textures, standalone uniforms and by-mistake left-overs of the previous deprecation phase like texture environment LOD bias should go away)[/li][/ul]

Some current mobile hardware has programmable blending exposed via NV_shader_framebuffer_fetch. Is it unreasonable to think that current or near future OpenGL hardware might have similar functionality to existing OpenGL ES hardware?

[QUOTE=Alfonse Reinheart;1236804]
No, I tell people to stop posting suggestions that will not be implemented. What expectation is it that anything he has suggested would even be considered, given that the ARB tried twice and failed twice?[/QUOTE]

I would say that if they already tried TWICE then certainly there is a chance they will try it a third time, and hopefully now they even might succeed.

Repeated suggestion shows that people are STILL interested in this API and believe that it may be improved (unlike you -

OpenGL is what it will always be. It will be a functional but crufty API; the sooner you get over that, the better for everyone.
).
And when the ARB see the repeated suggestion I doubt they will say “ah, we see some spammer here. Now we WONT do what he wants, even if we would do it otherwise!”
I think they rather would say something more like “we already tried that twice and failed, but since still there is a popular demand, we shall keep trying!”

Things don’t always work from the first time. If you remember the history of the very wanted feature “render in texture”. The first attempt ended up with the lousy pbuffers. Then people kept complaining and wanted improvement. Then ARB tried again and the second time they did it right (we got the framebuffer objects).

What I want is for people to stop asking for what they want. I want people to ask for something that the ARB would actually do.

The “suggestions” this forum is for are exactly things that people want. They are not what “the ARB would actually do”.
It is not our job to guess what ARB would actually do. Our job is to decide what WE need and formulate it well.

Of course you are free to censor and apply your criteria for what is good and what is bad to your OWN suggestions (if you ever make ones), but please dont try to impose them on other people. Other people have brains to decide for themselves.
Even a moderator would intervene only on breach of forum rules. But you try to censor the peoples very legal suggestions when you are not even a moderator.

But he’s already done’ that. And the ARB has already attempted what he has suggested and rejected it. Twice.

I’m just curious. Any idea why it was rejected? Resources please?

The first was called simply OpenGL 2.0, and it was initially proposed by 3D Labs. From an outsider’s perspective, it seems like 3D Labs simply walked into a GDC one day in 2001 and said, “Here’s some stuff; let’s talk about it!” According to that Slashdot article, they wanted an open dialog on the subject.

The only copy I can find of the original proposal is here. Be warned, it’s an unvirus-checked PDF. The general idea was something like the current GL 3.0, only with what was probably a cleaner break between the older APIs and the newer ones. There was some form of backwards-compatibility layer between the two, such that you could use bits of 2.0 in 1.x code.

Exactly why the ARB abandoned it is not known. They weren’t particularly forthcoming about it at the time.

The second effort was eventually called Longs Peak. There were four public newsletters released by the ARB about it during its development. They used to be available on this site, but I can’t find them anymore.

This thread is a catalog of the community reaction when told that 3.0 would not in fact be Longs Peak. This post by Barthold presents the ARB position on why it was ditched. The gist of it is that it was taking too long, they couldn’t commit to what exactly to remove, and many GL users aren’t going to accept having to rewrite large parts of their apps.

That last point hasn’t changed and isn’t going to change. So long as the ARB prioritizes those who do not wish to do rewrites, they’re not going to rewrite the API.

Also, note the “taking too long” point. Barthold’s post was made over 2 years after the initial Longs Peak pipeline newsletter. There is information that they stopped working on Longs Peak in early 2008 or thereabouts. So even with that, you’re still looking at 1.5 years.

The ARB could not settle on a new API in 1.5 years. Has something changed that would make them more productive?

Also, Barthold promised, “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.”

It is closing in on 4 years since then. What “incremental” “improvements” have been done to the object model?

  1. Texture storage. It creates partially immutable textures; immutability being one of the features of the “new” object model.

  2. DSA-style uniform setting (thanks to separate_shader_objects, but only because it’s a lot more convenient that the other way that SSO lets you set uniforms).

  3. DSA-style shader objects.

… That’s it.

You be the judge as to how much the ARB has fulfilled this promise.

… and until they do all others are stuck in limbo. Personally I have made my peace with OpenGL’s shortcoming a while ago but I believe that backwards compatibility can only be a valid reason for delaying long overdue API redesign for so long. At some point they have to do it anyway so it might as well be in the near future.

A much more efficient route would be if the ARB told the community what features they are willing and able to incorporate in a certain time frame, have a vibrant discussion and then ratify the most promising draft. From my perspective it is very hard to tell what they would and would not do. The ARB and the interests of the companies involved aren’t transparent. For instance, asking to get rid of object binding isn’t something that’s illogical and impossible to do and the discussion about it has gone on for years. This redesign is something one could shove down developers’ throats without losing sleep. I doubt anyone would seriously oppose losing this ancient mechanism. And in my eyes such a proposal is completely valid and still they haven’t done it until 4.2

We need more direct communication again.

Taking so long to fulfill promises and keep disappointing the community over all these years every time they come up with a new version, shows one and only one thing, incompetence!
I understand driver and CAD developers don’t want to rewrite. However laziness is not a valid excuse.

I wouldn’t necessarily blame that on incompetence. Although I don’t know what the vetoing rules are I imagine that every, or at least major decisions have to be unanimous. If one member is blocking something intentionally, it’s most likely due to business interest. No single corporation involved in the ARB would ratify anything out of good faith and software engineering idealism. If my little research is correct, Microsoft did just that before they left the ARB - blocking everything just to slow down the development of the API. In the case of Direct3D, however, there is only one decider - Microsoft. Of course, they will try to please their customers as much as possible, but if they want to do something drastic they don’t ask hundreds of companies over multiple years, they simply tell them: “Look, the next version will break this and that and the simple truth is you will have to adopt the changes or stay with earlier versions.”

I recently read one of NVIDIA’s presentations on Longs Peak dating back to 2006 which already proposed a model to seperate legacy and new code to maintain compatibility while drastically renewing the API and making it easier for developers and implementors. Later presentations on the other hand clearly state, that NVIDIA doesn’t believe in dropping “perfectly valid” (IIRC) functionality and therefore provides fully backwards compatible GL drivers. I cannot imagine that maintaining drivers which support everything up to 4.2 is what one can call “making it easier for implementors”. The whole thing seems quite schizophrenic.

When it come to backwards compatibility is ask myself: Why don’t they unanimously agree on breaking it and simply do it Microsoft’s way? If they simply said “we’re gonna redesign the whole GL so live with it and adopt the damn thing”, would legacy developers choose not to invest time and money to port their apps? Would they abadon OpenGL and move to Direct3D thus creating the necessity to rewrite the whole rendering code anyway? What are all the legacy developers gonna do? Blow up AMD’s or NVIDIA’s headquarters? I imaging that every member of the ARB is aware of that and still they don’t do it.

However, all speculations are ultimately irrelevant. As long as the ARB doesn’t tell the community stuff we’re simply doomed to live with it or abadon x-platform development and go Direct3D (which I for one will surely not do).