OpenGL 2.1 and GLSL 1.2

The OpenGL 2.1 specification
http://www.opengl.org/documentation/specs/version2.1/glspec21.pdf
and the GLSL 1.2 specification
http://www.opengl.org/registry/specs/ARB/GLSLangSpec.Full.1.20.6.pdf
were just released.

Why are there no floating point textures and buffers in OpenGL 2.1?

This is a good new, but…

this is the specification, there are a place with a summary of the differences between one version or another?

I think that this is specially interesting at the GLSLspec, as at the OpenGL 2.1 the main differences (i think) are related to the new extensions.

If anyone knows where to find something similar to a summary, please post it.

API

How about the press-release ?

• glad to see PBOs making it into the core… then maybe ATI will start supporting them

OpenGL 2.1 adds backwards compatible enhancements to OpenGL’s advanced programmable pipeline including: Pixel Buffer Objects for fast texture and pixel copies between frame buffer and buffer objects in GPU memory; texture images specified in standard sRGB color space for enhanced application color management flexibility; and numerous additions to increase the flexibility of shader programming including non-square matrix support, support for arrays as first-class objects, a fragment position query in shaders using Point Sprites and an invariant attribute for variables to enhance shader code reliability.

Appendix J in the OpenGL specification details changes between version 2.0 and version 2.1.

First, thanks for the responses,

about the press release, well, you are right, this is really a summary, but when I ask for this I was thinking in a 2-3 pages summary, explaining a little the changes… as this appendix J at OpenGL 2.1 spec. It’s strange that at the GLSL spec doesn’t add a similar chapter.

API

Frankly i am a bit dissapointed that FBO didn’t make it into this one, it makes it feel like openGL 2.05,
But i guess it’s some progress, i am looking forward to the work the Khronos group can do.

Okay, Ive made some notes while reading GLSL spec, so here go the differences between 1.10 and 1.20.

1. New non-square matrices, like mat2x3 are added. You can construct a matrix from a smaller or of equal size matrix, putting it in the upper-left corner and filling the rest with identity. New functions outerProduct() are introduced that construct a matrix from two vectors - it is basicly V1*transposed(V2).
2. Float literals can have optional f or F suffix. They are making ground for future float precisions that way. There are also implicit conversions from ints, so now your shaders wont break on non-NVIDIA drivers.
3. Arrays are first-class citizens, as they promised. So now float[8] x; is legal and it can be assigned, compared and returned from functions. Arrays have java-like length() method, so you can pass arrays of any size to functions. Unsized arrays behave more like pointers and like references cause you cant assign to them and call the length() method. Array constructors are there also.
4. Emedded structures are not allowed - you cant declare a struct inside a struct. If you want nested structs, define them in global scope.
5. New centroid qualifier that works when multisampling is enabled. It assures better interpolation of varyings on geometry edges, but derivatives can be not so accurate.
6. New invariant qualifier that assures invariance along different vertex shaders that can be used in multipass algorithms.
7. Added transpose() functions.
8. New vec2 gl_PointCoord variable accessible from fragment shaders. It gives you coordinates in a point sprite in a range [0,1].

The changes are really minor

Two extensions made into core (PBO are being used for ages) and some cosmetical changes to GLSL

I bet 2.01 will do

Frankly i am a bit dissapointed that FBO didn’t make it into this one
Um, they told us that a couple of weeks ago. In the newsletter.

Additional FBO changes (necessary to promote inclusion into the core) are a part of the 3.0 API, with its revamped object model.

The changes are really minor
That’s one way to look at it.

The other way is that the ARB is potentially busy on our new API, and these were the only extensions/changes they felt were necessary before getting 3.0 out the door.

some cosmetical changes to GLSL
I wouldn’t call the changes to glslang cosmetic. The array thing plugs some important holes in glslang.

There is no texture lookup functions with explicit gradients in GLSL 1.2 ?

There is no texture lookup functions with explicit gradients in GLSL 1.2 ?
It’s in the ARB_shader_texture_lod extension.

Functionality is almost always put into extensions as a test run to being integrated into the core.

Originally posted by Korval:
[b] [quote]Frankly i am a bit dissapointed that FBO didn’t make it into this one
Um, they told us that a couple of weeks ago. In the newsletter.

Additional FBO changes (necessary to promote inclusion into the core) are a part of the 3.0 API, with its revamped object model.[/b][/QUOTE]I know, but openGL 3.0 with all the changes i have read about sort of feels somewhat like a new API (like c++ is to c), so i would not object to the promotion of FBO’s as they are now (perhaps merged with the two supplemental extentions, blit and multisample) to core status and then later when 3.0 comes we have a new way of doing things with the new object model, including FBO.
But i guess we can’t have everything.

So is openGL 2.1 the last version before 3.0?
And when do we get to see the suggestion for 3.0 so that the community get to give feedback on it?

And when do we get to see the suggestion for 3.0 so that the community get to give feedback on it?
What was that whole gamedev article/thingy all about, and a host of recent threads on the subject?

Maybe I missed something, but I seem to recall something about an intermediate language for GLSL (don’t know why, but that stood out like a sore thumb (tee-hee)).

I’m stoked.

i would not object to the promotion of FBO’s as they are now (perhaps merged with the two supplemental extentions, blit and multisample) to core status
It would be silly to promote an extension to the core knowing that you were just going to depricate/rewrite it next year anyway.

There’s nothing wrong with using the FBO we have now as an extension. Just as there’s nothing wrong with using the ARB_vertex/pixel assembly program extensions. They exist, and as long as implementations support them, they can be used.