OpenGL 3.1

Ok, I’m sure we’d all like to say ‘the object model’ but that isn’t going to happen. So for OpenGL 3.1 I’d like:

  1. Make direct_state_access core.

  2. A function like:

void ProgramSamplerEXT(uint program, int location, int texture);

So we can bypass the whole texture-units/textures/samplers annoyance and set which texture we’d like which sampler to use.

  1. A replacement for Vertex Array Object. So we can bind the entire layout in one go. It’s very annoying to have to use VertexAttribPointer every time. E.g:
struct Vertex
{
  float x, y, z, nx, ny, nz, tx, ty;
};

would look like:

glGenVertexArrayObject(1, &vao);
glSetVertexAttributeObject(vao, 0, 0, 32, 3, GL_FLOAT, GL_FALSE); 
glSetVertexAttributeObject(vao, 1, 12, 32, 3, GL_FLOAT, GL_FALSE); 
glSetVertexAttributeObject(vao, 2, 24, 32, 2, GL_FLOAT, GL_FALSE);

where glSetVertexAttributeObject is defined as:

glSetVertexAttributeObject(vao, attributeNumber, offset, stride, size, type, normalise);

(offset is the distance from the start of the buffer, as we can’t do fancy pointer fiddling)

We’ll also need a couple of functions for binding a buffer to the vertex array object or binding a buffer to each attribute individually.

Thanks & Regards
elFarto

A replacement for Vertex Array Object. So we can bind the entire layout in one go.

You don’t need to replace the entire vertex array object to do that. It’s just an alternate method of setting the attribute, which a “direct_state_access” version that was written against “3.0” would provide.

Replacement was a bad choice of words. All the functionality is there, but calling VertexAttribPointer multiple times every time you need to change the layout of the VBO is silly.

We just need a way to group the calls together, in a way that allows the driver to not have to go through the setup procedure every single time.

The direct access extension doesn’t give us anything, as there is still just a glVertexAttribPointer call, all the state is stored in the context, where you can only have one at a time.

Regards
elFarto

The direct access extension doesn’t give us anything, as there is still just a glVertexAttribPointer call, all the state is stored in the context, where you can only have one at a time.

Did you miss the part of the “direct_state_access” that said, “This extension is written against the OpenGL 2.1 specification.” Therefore, it does not provide entrypoints for VAO and other 3.0 features.

When they get around to making “direct_state_access” for VAO and other 3.0 features, they will provide this. It isn’t something you have to ask for.

Nope, I missed the bit in the OpenGL 3.0 spec about Vertex Array Objects. I apologise for that.

Regards
elFarto

I missed the bit in the OpenGL 3.0 spec about Vertex Array Objects.

It even comes in a convenient extension form. The extension functions don’t even have the ARB syntax, which makes switching from a 2.1 context to a 3.0 context easy.

Keep in mind that this extension was started about a year ago if not a little longer which was before the big change to GL 3.0. So there’s no way direct state access as it is now could support the 3.0 stuff as 3.0 was in an “interesting” state at the time.

I agree 10000000000% that direct state access should be in the core. Of course, after it is updated a bit. :slight_smile:

Keep in mind that this extension was started about a year ago if not a little longer which was before the big change to GL 3.0.

This extension was “started”? What kind of “start” does it take to say, “Hey, let’s make a version of all those functions that operate on objectified state and make them use an object instead.” This is something that the original GL 2.0 was going to do. This is something that the original GL 3.0 was going to do.

This extension was “started” half a decade ago. It should have taken no human thought as far as implementation goes.

From GL_EXT_direct_state_access (not some pie in the sky GL proposal):
“1 11/20/07 mjk Initial version”

That’s not a half of a decade ago when THIS extension started.

Like I have said before, this is something that should have been in GL a long time ago. I agree, John Carmack agrees, etc. But a lot of times it takes some event (sometimes serious) to get something that seems obvious implemented. It happens all the time in all areas other than graphics. You know that.

What about any draw-time fix-ups/validation w.r.t. a VAO and a particular vertexshader/program; is this a real world performance concern in GL3? Or is this just a bind on demand thing with errors reported on mismatches as they occur, pretty much what we have now only neatly wrapped.

Or is this just a bind on demand thing with errors reported on mismatches as they occur, pretty much what we have now only neatly wrapped.

What, you didn’t expect anything good, did you?

I want GS as a core feature in GL3.1. No compromise, or put that new tessellator unit in they are putting with DX11. Hell from what I hear the tessellator unit will be more useful than GS are…

GS, tesselator, … it’s all gravy to me :wink:

Since the new object model obviously isn’t going to happen, I’m going to add my GL 3.1 wishlist here. I hope someone from the ARB is reading this thread, and it’s not going to disappear under all the rant :wink:

1) Uniform buffer objects!

This is by far the top feature on my wishlist, I’m surprised nobody else mentioned it here.

Note that I don’t want global uniforms. Uniform buffer objects are a much more elegant solution to the same problem. As a bonus, they have the potential to be optimized by hardware, while still being easy to emulate in the driver (after all, I can emulate them with my engine abstraction, but without the potential performance bonus of course :wink: ).

2) directly bind texture objects to samplers

This was already mentioned, but I wanted to repeat it for emphasis. Combine this with direct state access, and you can deprecate all this texture unit, texture image unit, glActiveTexture, glBindTexture and so on nonsense…

3) program state objects

Analogous to vertex array objects. This would save a lot of unnecessary glUniform calls (or the equivalent buffer binding command with uniform buffer objects) when switching materials.

EDIT: Another reason why program state objects would be good: It would solve the “shader recompile on uniform change” problem in a quite creative way. The driver can recompile the shader all it wants, and store the optimized version in the program state object. This only happens when the program state object is built. Later, while rendering, only the current object is changed, which should then be reasonably fast.

I know everyone else is lamenting about the new object model and fast path issues, but I think after the removal of the deprecated features the situation is not that bad. What I posted above is what I consider the really urgent features missing from GL 3.0. And with “missing” I mean that there isn’t even an extension. Personally I couldn’t care less about things being in the core, that’s also the reason why geometry shaders are not on my list…

I liked the new object model, too, and I’d still prefer to get something like it at some point in time. But, as we go players say, “play the urgent move before the big move” :wink:

seconding 1) and I as well think that eventhough the “big” change didnt happen, focus on the important small bits now.

but in 2) wouldnt that require to assign textures for every shader? Typically you would have a single shader active for multiple meshes, and only textures changing. Which works well at the moment with just changing the binds.

Changing a bind or changing a uniform, where’s the difference?

Also, there is still point 3). This would of course include all uniform state, including samplers :wink:

Oh, and I just realized another important thing:

4) direct state access

In this particular case, an extension is really not enough. This is the one thing that I think should really go into the core, in order to be able to deprecate all the old state manipulation functions.

What’s the difference between these?, they seem to solve the same issue in different ways.

Regards
elFarto

Overmind, please can you explain what is the problem “shader recompile on uniform change”? I have heard something about it several times, but never experienced it though I am used to glsl shaders.

C’omn, cut a guy a little slack. It sure felt like I was thinking while implementing.

  • Mark

it’s natural that all the people invloved in making the extensions, of course are the ones that actually did do something, care about it, spent time and effort, show up on these forums and now reading/replying to reactions and get hit by the community first… when the ones that actually made the “political” miss decisions, will never be around.

the main frustration I guess comes from the "EXT"ness and the fact how many good EXT we currently have, but only implemented by one vendor. Which for “serious” application/research, I think is less of an issue (hardware way cheaper than software), but more so for games.

so hopefully direct_state makes it into ARB soon and replaces the old way? (I wish not just for 3.0 so)