Official feedback on OpenGL 4.1 thread

[ScottManDeath]

You could check for the GL_ARB_debug_output extension. On a non-WGL_CONTEXT_DEBUG_BIT_ARB context this extension is/should be not supported.

-chris

That is what I'm doing right now, but a debug context doesn't have to have the GL_ARB_debug_output extension, it could have other debug functionality. A core GL inspection would be useful in that case.

[randall]

Referance Pages for 4.1 does not work on IE (there is an error when selecting any function).

[Khronos_webmaster]

Looking into this issue. Seems there are other issues in Safari and Firefox also. We are working on this.

[Groovounet]

and Chrome

[kyle_]

Updated reference pages are now online:

OpenGL 4.1 http://www.opengl.org/sdk/docs/man4/
OpenGL 3.3 http://www.opengl.org/sdk/docs/man3/
OpenGL 2.1 http://www.opengl.org/sdk/docs/man/

This is great news.
Imo even better than the actual features introduced by new spec.

Great job.

Now to port spec's to xml and we are pretty much set .

[kRogue]

Is there any chance to restore creating man pages for Unix systems? I've been trying unsuccessfully to generate man pages from the the sources, the current state of the GL wiki: http://www.opengl.org/wiki/Getting_s..._and_Man_Pages gives how to generate the xml, mentions man pages, but, does not have an entry in the makefile. I follow the instructions to setup the catalog stuff, but running

docbook2x-man something.xml

or for bash lovers:

for i in *.xml; do docbook2x-man "$i"; done

generates bad man pages at times [glTexImage2D comes out really bad on me]. Is there a possibility to add to the makefile "make man"? Sometimes I just want to type man glSomething.

I really like that glGet family has hyperlinks to the function that sets the value, that is really nice, similar for glGetShader too.

One suggestion, though potentially a great deal of work: to add a reference (chapter(s), section(s) and subsection(s)) where a given API point is named, so that one can get the quickly where in the spec it is described.

Something I just noticed for the GL3 man pages:

glFramebufferTextureLayer — attach a face of a cube map texture as a logical buffer to the currently bound framebuffer

That is the description of glFramebufferTextureFace, I guess the text should be "glFramebufferTextureLayer — attach a face of a texture array as a logical buffer to the currently bound framebuffer" In all honesty, kind of nitpicking I am there.

[xahir]

@Khronos

GJ for the new specs / man pages and all.

I want to comment on the spec versioning. Hardware brands are named under the version of DirectX (either we like it or not). So we have PreDx10HW, DX10HW, DX10.1HW and DX11HW.
Some of the specs released on 4.1 (especially multiple viewports) exists on DX10.1HW and some specs on 3.3 (sampler objects, GLSL33 attrib location layout ...) can be implemented on DX10HW.

When I want to release a product I try to handle the balance between graphics quality and spectrum of hardware supported. If OpenGL continue to release specs this way we are forced to think the worst and always try to check whether an extension is supported, implement both ways etc. It could be nice if we have some revision number on OpenGL versions so we may select a version with a revision. I guess minor version was there for this purpose but it is not being used this way.

@kRogue

That is the description of glFramebufferTextureFace, I guess the text should be "glFramebufferTextureLayer — attach a face of a texture array as a logical buffer to the currently bound framebuffer" In all honesty, kind of nitpicking I am there.

Actually, I cannot find any FramebufferTextureFace in specs, instead the FramebufferTextureLayer does the job for cubemaps (in specs, Table 4.12). Additionally, FramebufferTextureLayer can also attach level of a 2d-array or a 3d texture level.

[randall]

For OpenGL 3 capable hardware, these new extensions are provided:

ARB_viewport_array (also in core OpenGL 4.1)

viewport array is DX10HW.

[kRogue]

bash$ grep FramebufferTextureFace /usr/include/GL3/gl3.h 
GLAPI void APIENTRY glFramebufferTextureFace (GLenum, GLenum, GLuint, GLint, GLenum);

I could not find FramebufferTextureFace is not in the specification either. For FramebufferTextureLayer, to use a face of a cube map you provide an integer 0<=i<=5, for the Face, it looks like you use one of the enums from the family GL_TEXTURE_CUBE_MAP_POSITIVE/NEAGTIVE_X/Y/Z

Oh well, spec bug or manpage bug?

[Alfonse Reinheart]

some specs on 3.3 (sampler objects, GLSL33 attrib location layout ...) can be implemented on DX10HW.

All of GL 3.x should be implementable on DX10 hardware. That's the dividing line between GL 3.x and 4.x.

If OpenGL continue to release specs this way we are forced to think the worst and always try to check whether an extension is supported, implement both ways etc. It could be nice if we have some revision number on OpenGL versions so we may select a version with a revision.

Does it really matter? If the implementation didn't support a hypothetical GL 3.4, wouldn't you need to support a different codepath anyway? What's the difference between checking a version number and an extension?

Ultimately, all GL 3.3-capable hardware will support the various extensions they can. The only reason to create a version 3.4 would be to push a lazy implementer (I'm looking at you, ATI) to support something they should have been supporting.