my wishes for OpenGL 3.x (1 <= x <= 2):
maybe:
Some drivers compile special versions of shaders when uniforms have special values. Consider for example this shader:
uniform float x;
in vec4 i;
out vec4 o;
void main() {
o = i * x;
}
This shader contains a single multiplication. But when x is 0 or 1, the multiplication could be optimized away.
In general, this is a good idea, as it makes the shader run faster. The problem with this is that it takes time to do it. And uniforms usually are changed in the middle of drawing something, I want this to be fast.
What’s the difference between these?, they seem to solve the same issue in different ways.
It’s not quite the same.
Uniform buffer objects are perfect for global state like matrices, light parameters and so on. They can be shared between multiple shaders, so you can put all the state in a buffer object and when changing shader you just need to bind a single buffer object instead of setting all the uniforms again.
They can also be used for material parameters. You would probably use at least two uniform buffer objects, one for material specific parameters, one for global state.
Program state objects don’t solve this issue, because you would have to change the values in every single program state object every time you change a matrix.
On the other hand, program state objects are perfect for material parameters, textures and so on. These are properties that don’t change while rendering. You would have a program state object for each “material” (that is, a shader/texture/UBO combination), and this never changes.
Also, uniform buffer objects are not really usable for textures. So at least sampler uniforms would have to be set separately.
This is a mechanism on top of uniform buffer objects. Without it, each time you switch material, you have to:
Instead, you just bind a single program state object that contains all necessary information, already nicely preprocessed, perhaps even with shaders optimized for the particular uniforms.
Point 4) would basically be the “old” glUniform. This is the only thing that overlaps a bit with uniform buffer objects, so you could deprecated it. But I think retaining the old glUniform mechanism in addition to buffer objects could be quite useful for compiler optimizations, because these uniforms could be effectively treated as constants. This is something some vendors already do now, but “hidden” and with the side effect that a uniform change may take an unexpected amount of time.
With program state objects the problem would vanish, because a uniform change at runtime is no longer necessary. Just put everything that changes often in a buffer object. Everything else (e.g. material constants) remains a normal uniform and can be used by the compiler to optimize, but this time there is another object in between, so the compiler needs to do this stuff only once and store the result in the state object.
In this regard, the program state objects are exactly the same as vertex array objects: A cache that prevents the driver from having to process everything again and again. Nothing more, nothing less.
Ok thank you Overmind, I understand now. 
and I agree now, program state objects would be a nice solution.
C’omn, cut a guy a little slack. It sure felt like I was thinking while implementing.[/QUOTE]
OMG! Mark Kilgard is not human! (Or at least does not think as a human).
So, no news about the BoF. Maybe they decided the Cone of Silence should extend over that too? Surely someone who was there can comment on it.
Overmind, your list 1-4 and my list have very strong alignment.
I agree, and you have my vote.
This is a mechanism on top of uniform buffer objects. Without it, each time you switch material, you have to:
this gets really old fast. Part of the reason I don’t get to fancy with using a lot of shaders is the long list of items you have to do to get the info the shader needs uploaded to it. If would be nice to call one function that takes all necessary items of importance, if that is even possible.
We also need a glNamedVertexAttribPointer method.
Regards
elFarto
Isn’t that in the new spec? Its under EXT_direct_state_access
Isn’t that in the new spec?
No. Direct State Access, as I keep saying, is written against GL 2.1. So it doesn’t include any GL 3.0 features like VAO (which is the object that glNamedVertexAttribPointer would use).
Growing the scope of DSA to cover GL3.0 is likely a straightforward exercise.
Hop to it then 
Regards
elFarto
There’s probably no OpenGL without extensions. I’m guessing the primary return on a vendor’s OpenGL investment probably comes from industry that uses their cards as their sole platform, rather than the situation you have with the gaming market. In the platform scenario, a single card and some extensions are all you really need, and it gives the vendors themselves a way to shine on their own as opposed to being forcibly blended into the hardware background. Vendor’s ace in the hole or APIs Achilles heel? Probably depends on which way is up for you.
The way I see it, as long as extensions make it into the core in a timely manner, it’s all good. Without extensions there’d be nothing to tinker with until all the ducks are in a row, and that’s no fun.
My POV is that extensions are OK as long as they have short lifetimes prior to integration (agreeing with what modus said).
FBO for example was out in the woods as an extension for way too long before being integrated. But part of that is due to too large of an interval between major releases.
May be look like this:
struct GL4_VERTEX_STRUCTURE_ELEMENT_DESC
{
GL4char *Semantic;
GL4uint SemanticIndex;
GL4_FORMAT Format;
GL4uint InputSlot;
GLuint ByteOffset;
// etc
};
GL4_VERTEX_STRUCTURE_ELEMENT_DESC Structure[4] =
{
// Place structure here
};
GL4handle VS = gl4CreateVertexStructure( Structure, 4 );
// later
gl4SetVertexStructure( VS );
What is all of this “gl4” nonsense? And OpenGL doesn’t need to be defining structs.
“gl4” is just separate C-style namespace for new version. And I’m not sure that numerous entry points are better than some structs 
Structs are probably more convenient to work with, but entry points are probably easier to extend.
Something sorta like
glGenPrograms(1, &program);
glGenProgramInputs(1, &input);
glBegin(GL_PROGRAM_INPUT_DEFINITION);
glProgramInputStreamType(input, stream, GL_RGBA32F);
glProgramInputStreamOffset(input, stream, 0);
glProgramInputStreamStride(input, stream, 4*sizeof(float));
…
glEnd();
// Check for valid input against program…
glValidateProgramInput(program, input);
…
glBindProgram(program);
glBindProgramInput(input);
gets the same job done and is infinitely extensible without making a break with the GL look and feel.
On second thought, maybe something like the WGL context creation attribute lists wouldn’t look too out of place…
utterly OT, but I couldn’t help but lol at modus’ new sig 
The ARB is not interested in a new API. They’ve said this about as clearly as it can possibly be said, seeing has how 2 separate attempts to create a new one have failed utterly and completely.
Further attempts to suggest one are not necessary.
Since OpenGL 1.0 API become too fat, look at EXT_direct_state_access It’s nightmare.
With right decisions, C-structs are extensible too. Like this:
struct GL4_VERTEX_STRUCTURE_ELEMENT_DESC1 // GL 4.1
{
GL4_VERTEX_STRUCTURE_ELEMENT_DESC Desc4;
GL4uint AdditionalMember;
GL4float AdditionalMember2;
};
GL4handle VS = gl4CreateVertexStructure1( Structure, 4 ); // GL 4.1
// later
gl4SetVertexStructure( VS );
Some functionality of GPUs are fixed from HW to HW for years, thus nearly immutable structs can be used in C-API.
Attribute lists is not an option when mixing of variuous types (float/uint) required.
I’ts my IMHO how good API should look. Ok, ARB too old/lazy for this [censored] (Lethal Weapon 4)