It looks like the spec for OpenGL 4.0 has come out: http://www.opengl.org/registry/ Reading through it, it looks like the most notable change is the addition of "Tessellation Control Processor" and "Tessellation Evaluation Processor". From the GLSL spec:

Quote:The tessellation control processor is a programmable unit that operates on a patch of incoming vertices and their associated data, emitting a new output patch. Compilation units written in the OpenGL Shading Language to run on this processor are called tessellation control shaders. When a complete set of tessellation control shaders are compiled and linked, they result in a tessellation control shader executable that runs on the tessellation control processor. The tessellation control shader is invoked for each vertex of the output patch. Each invocation can read the attributes of any vertex in the input or output patches, but can only write per-vertex attributes for the corresponding output patch vertex. The shader invocations collectively produce a set of per-patch attributes for the output patch. After all tessellation control shader invocations have completed, the output vertices and per-patch attributes are assembled to form a patch to be used by subsequent pipeline stages. Tessellation control shader invocation run mostly independently, with undefined relative execution order. However, the built-in function barrier() can be used to control execution order by synchronizing invocations, effectively dividing tessellation control shader execution into a set of phases. Tessellation control shaders will get undefined results if one invocation reads a per-vertex or per-patch attribute written by another invocation at any point during the same phase, or if two invocations attempt to write different values to the same per-patch output in a single phase. The tessellation evaluation processor is a programmable unit that evaluates the position and other attributes of a vertex generated by the tessellation primitive generator, using a patch of incoming vertices and their associated data. Compilation units written in the OpenGL Shading Language to run on this processor are called tessellation evaluation shaders. When a complete set of tessellation evaluation shaders are compiled and linked, they result in a tessellation evaluation shader executable that runs on the tessellation evaluation processor. Each invocation of the tessellation evaluation executable computes the position and attributes of a single vertex generated by the tessellation primitive generator. The executable can read the attributes of any vertex in the input patch, plus the tessellation coordinate, which is the relative location of the vertex in the primitive being tessellated. The executable writes the position and other attributes of the vertex.

I'm not sure that I see how this would be very useful. Any thoughts?

Wow, I'm still on version 2.1 :p. Doing tesselation on the GPU sounds pretty cool; I'm sure it can be adapted for several interesting uses like (as mentioned above) LOD's on meshes. I guess it's time to read up on tesselation for me then.

Keep in mind that tessellation will ONLY work on DX11 hardware.

Your OpenGL breakdown is now basically;
GL2.x - pre-DX10 hardware and up
GL3.x - DX10 hardware and up
GL4.x - DX11 hardware and up

I think a more interesting question is, "given a list of what the current crop of GPU's are capable of, where is OpenGL not exposing that functionality?" which is in some sense what has driven the feature set for 3.0, 3.1, 3.2, and 3.3 / 4.0 - there have been basically two GL updates per year for the last two years straight.

It was only a couple of years ago when DX10 was shipping and GL 3.0 was not. DX10 was doing a better job of exposing the silicon features on a timely basis, and GL was not, IMO. If you see parallels between them now, that's not unreasonable, they are on top of the same hardware after all.

GL can't dream up features that the hardware doesn't have (aside from API streamlining type moves), in the best case GL implementations arrive closer to hardware availability in the market. NVIDIA is claiming they will have GL4 available on Fermi at ship, this is good.

When you're behind, you can either close the gap, maintain position, or give up. The observation that Khronos and the OpenGL group is making an ongoing effort to close the gap - whether you feel that gap was "vs. DX" or "vs. hardware capability" - isn't bad news.

A position I have been vocal about is, as long as there is a feature gap against hardware, don't try to reboot the whole API. Timely hardware exposure is Job 1, and this is reflected in the last four releases.

We could be getting close to a corner where the immense pressure to catch up on hardware exposure is easing, and energy can go into other areas, or simply covering issues that have been missed to date. One example of that in GL 3.3 is the separation of sampler state from texture objects - it was an old feature request from DX-savvy developers, and there was finally enough breathing room in the schedule to do it, it's in there.

The multi threading discussion is interesting, there are use cases where async operations have always been possible on GL using a secondary shared context, and I am sure there are new use cases worth looking at that could affect future GL revs where a secondary context doesn't cut it. Look closely at the new ARB-sync stuff, it goes beyond fences and flushes..

There is a feedback thread on OpenGL.org forum w.r.t. 4.0 - just as was done for 3.0 / 3.1 / 3.2 - it's a good place to express needs to the working group. The feedback loop has been much more effective with the last couple of releases in particular, and it always helps to be specific about what you want that would help your app.

http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=postlist&Board=12&page=1



In summary, 2010 != 2007.