Version 3.x

What’s the features list of the next version of OpenGL, 3.1 or above?

When is that expected?

Is the current drivers from ATI and NV for 3.0 stable, and encouraging the move toward an upper version?

The feature set for GL 3.1 is not yet published.

Is not that one which was intended for 3.0?

For some reason I am not able to parse the comment. Can you re-phrase it ?

I meant to say that 3DLabs I guess had something about GL 2.1 or 3.1 I don’t remember, but with features that were promising. Unfortunately they are not adopted for 3.0.

With all due respect, we’ve been down this long and winding woulda-coulda-shoulda road before; it leads to a rickety old house at the end of a dirt road; a house with a bearded lady on the front porch in a rocking chair petting a mangy, 3 legged monkey who has, but for the steady stream of saliva from his maw and an occasional impromptu performance of “I’ve got to be me” from a traveling circus of fleas seeking lodging within his nostrils, remained motionless and inert for days.

This is does not answer the question

No but it was hilarious!
Rob answered your original question, and you haven’t written a coherent sentence since then. As far as we can tell you’re just flogging the dead horse of GL3 not being what was originally promised. If you have an actual question, please write it carefully in English and you’ll get a sensible response.

Well his answer was great but he forgot to quote it and give credit to some ppl. Anyway…

No more questions. I quit. I no speak “English.”

I can try to expand on what I originally wrote.

GL 3.1 is near completion. However due to the mutually-agreed rules of the Khronos working group, it would be premature for me or anyone else in the working group to start laying out the feature list for that release just yet. Restated, we’d like to be sure that the spec is complete and there are no remaining issues, and that there is consensus for its release.

Last year, we had the 3.0 document essentially frozen except for minor bug fixes at the end of June, but it was not announced until August SIGGRAPH because there is a 30-day period of promoter review through which the document has to pass unscathed(), before it can be made public. ( minor edits and typos getting fixed of course)

So while I would very much like to say “3.1 will have X and Y and Z” - it is not time to do that yet.

Will there be a version of the spec only containing non-deprecated features?

Most definitely.

What I would like to see in the nearest 3.x version:

Geometry shader integration as part of the core spec.

GPU statistics feedback

Object/buffer synchronization control

Can you elaborate on “object/buffer synchronization control” ? i.e. what use-case can you describe where there is a blind-spot in the current API?

I’ll go out on a limb and make a prediction…

Additions to 3.1:

  • EXT_bindable_uniform
  • ARB_draw_instanced
  • ARB_geometry_shader4
  • ARB_texture_buffer_object

Most of these are ARB already anyway, so admittedly that’s a short limb.

And for 3.2:

  • AMD_texture_texture4
  • EXT_direct_state_access (?)
  • EXT_timer_query
  • NV_explicit_multisample
  • NV_transform_feedback2
  • … other goodies

These seem inevitable in one form or another with the exception of DSA. Adoption of DSA would likely imply the elimination of selectors outright, which would be a pretty radical change for the API at large. May need more time to ease into that one (maybe even a 4.0 thing).

Please no NV_explicit_multisample. This is just fugly. D3D10 already has set a precedent with MSAA textures / texture arrays, what’s wrong with that?

How’s it fugly?

Getting right down to it EXT_explicit_multisample doesn’t seem all that different from the whole resource/view thing in d3d10. Creating and rendering to a renderbuffer would be analogous to creating and rendering to a rendertarget view. In the end it looks like we actually have fewer objects since you don’t need a shader resource view to sample the renderbuffer. The setup does seem a bit more convoluted at first blush - this latching business takes a bit of getting used to IMHO. I hosed myself early on with VAO because of it. Haven’t even use this yet so I’m probably talking out my arse anyway :wink:

Why no MSAA 1D/2D 1D array, 2D array, cubemap, cubemap aray textures with respective sampler functions, and then to the gutter with the render buffers.

Aliasing a render buffer with a texture object of custom texture type is beyond redemption, as it adds unorthogonal clutter to the API by making a non-texturable buffer texturable.

For GL3.1, PLEASE:

I’m so thankful for Rob Barris feedbacks but I’m guest we are going to have some more official information at GDC 2009 and anyway we have discussed these topics several times already on previous posts.