I’m citing the 3.1 specification from March 24th, with the deprecated functionality omitted. Sections F.1 and G.1 mention the new features in OpenGL 3.0 and 3.1 and which extensions that were promoted to core in those versions. But a lot of extensions are either completely or partially missing in the specification itself.
Example: F.1 page 302 states that GL_APPLE_flush_buffer_range was added to 3.0, but BufferParameteri is not mentioned in the specification. Neither is BUFFER_SERIALIZED_MODIFY nor BUFFER_FLUSHING_UNMAP.
FlushMappedBufferRange is mentioned, but that’s because it is a part of another extension which was promoted, namely GL_ARB_map_buffer_range.
Example 2: F.1 page 302 states that GL_NV_depth_buffer_float was added to 3.0, but neither DepthRanged, ClearDepthd nor DepthBoundsd are mentioned in the specification. The new internalformats DEPTH_COMPONENT32F and DEPTH32F_STENCIL8 are however, as well as the new type FLOAT_32_UNSIGNED_INT_24_8_REV.
There are more occurrences where the listed extensions are completely missing or does not map one-to-one with the core. Am I reading the specification incorrectly, or have they simply not mentioned the changes they did to the language after the promotions?
Extensions may and do change when they are moved to core. Tokens are removed, function signatures are changed, behaviour is modified. In my understanding, the PDF version of the specs has the final word in case of a mismatch.
Mistakes are made from time to time, but not that often.
Right, I was just surprised the changes only were mentioned for NV_primitive_restart, but not for any of the other extensions.
Which means that even if you’ve used the extensions before, you have to re-read the whole specification and learn how to use the functionality again.
This still does not explain why GL_APPLE_flush_buffer_range is missing completely, though. Or that’s the way it seems.
It could be that they omitted the function prototype and renamed all the enumerations/tokens, or just listed the extension because GL_ARB_map_buffer_range is based on it.
Citing the F.1/G.1 sections: New features in OpenGL 3.x, including the extension or extensions if any on which they were based, include:
Hm, you are right, the released headers and spec files are still missing some methods. It seems they are gradually being updated - there were several additions between last Thursday and last Sunday. I’d wait a few more days and check them out again.
The irony is, that NV_primitive_restart was a very practical extension - BEFORE GL_POLYGON and GL_TRIANGLE_FAN were deprecated. Now it’s rarely useful, but well…
GL_POLYGON has never been natively supported by any hardware anyway, and triangle fans are mostly useless. NV_primitive_restart is useful for drawing series of triangle strips, which at least theoretically is the most optimal way to draw in terms of least data needed.
MapBufferRange != GL_APPLE_flush_buffer_range. The former is an ARB extension and the latter isn’t, the former has a different interface and usage as well.
Interestingly, APPLE_flush_buffer_range seems to be supported by the latest Catalyst drivers, which indicates there is some level of interest. No idea about Nvidia support.
Edit: or so I was told. I just checked again and this doesn’t seem to be the case. Weird…
That’s a surprise, i had in mind only triangles and triangle-strips had survived. That means with triangle fans and primitive restart i could no try out doing a terrain rendering algorithm more efficiently.
As I stated in my earlier posts, GL_APPLE_flush_buffer_range is listed under section “F.1 New Features”, but I wonder if it’s listed there because GL_ARB_map_buffer_range was included and perhaps is based on GL_APPLE_flush_buffer_range. They both share a function prototype, glFlushMappedBufferRange. Or at least my glext.h says that.
So my question still stands. Are all the extensions listed under F.1 and G.1 “New features” extensions that were promoted to core, or are some of them just listed there for completeness? (i.e promoted extensions are based on some of the extensions listed)
@Jan: Element buffer with triangles will give you better result theoretically both on amount of data side, on vertex caching side and event for amount of fragments according how you optimize the mesh.
NV_primitive_restart is rubbished, an optimization for old CAO application, nothing else. Triangle fans and triangle strips and NV_primitive_restart should be deprecated, it’s bad practice.