Official feedback on OpenGL 4.1 thread

Khronos Drives Rapid Evolution of Cross-Platform 3D Graphics with Release of OpenGL 4.1 Specification

  • New open API specification available immediately;
  • Wide-ranging enhancements with full backwards compatibility;
  • Enhanced integration with OpenCL for seamless visual computing;
  • Integrates OpenGL ES functionality for desktop and mobile platform portability

July 26, 2010 –Los Angeles, SIGGRAPH 2010 – The Khronos™ Group today announced the immediate release of the OpenGL® 4.1 specification, bringing the very latest graphics functionality to the most advanced and widely adopted cross-platform 2D and 3D graphics API (application programming interface). OpenGL 4.1 is the sixth update to OpenGL specification in two years, continuing the rapid evolution of this royalty-free specification. This new version continues to maintain full backwards compatibility to enable developers to begin using new features whenever they choose, while portably accessing state-of-the-art GPU functionality across diverse operating systems and platforms.

The OpenGL 4.1 specification has been defined by the OpenGL ARB (Architecture Review Board) working group at Khronos, and includes the GLSL 4.10 update to the OpenGL Shading language and is accompanied by a number of extensions introducing cutting-edge functionality to the OpenGL standard. The full specification is available for immediate download at

New functionality in the core OpenGL 4.1 specification includes:

  • [li]Full compatibility with OpenGL ES 2.0 APIs for easier porting between mobile and desktop platforms;[]The ability to query and load a binary for shader program objects to save re-compilation time; []The capability to bind programs individually to programmable stages for programming flexibility;[]64-bit floating-point component vertex shader inputs for higher geometric precision;[]Multiple viewports for a rendering surface for increased rendering flexibility.

New ARB extensions introduced with OpenGL 4.1 include:

  • [li]OpenGL sync objects linked to OpenCL event objects for enhanced OpenCL interoperability;[]The ability to set stencil values in a fragment shader for enhanced rendering flexibility;[]Features to improve robustness, for example when running WebGL applications;[*]Callback mechanisms to receive enhanced errors and warning messages.

Lastly, Khronos has simultaneously released a set of ARB extensions to enable as much OpenGL 4.1 core functionality as possible on previous generation GPU hardware; providing maximum flexibility and platform coverage for application developers.

Loading binary shaders! I like that!

Wow, that was pretty fast and some nice features too!

Please correct glspec41.core.20100725.withchanges.pdf, chapter K1, page 448, second bullet:
… the binary represtation of a program

Maybe im misreading the spec, but it looks like conforming implementation is allowed to support 0 binary formats of shaders … doh?

There are actually two different types of binary formats added in GL 4.1

I believe the one you are referring to is the ShaderBinary API that is part of the ES2_compatibility extension.

The other is the GetProgramBinary API that is part of the get_program_binary extension.

The former is more intended for offline shader compilation, and latter is intended caching compiled programs from one run of a program to the next for quicker loading times.


I especially find the following stuff great:

  • Program Binary Support - ie. “shader blobs”
  • Debug Output Notification - one of the best API enhancements! With D3D11 and PIX it is soooo great when you get real error-messages, instead of the dreaded GL_INVALID_XXX. Now IHVs please make good use of this debug-functionality and give us detailed error-messages please!
  • Shader Stencil Export - finally the stencil buffer becomes useful again (haven’t been able to make much use of it lately, because of the missing support to manipulate its content through shaders).

In general the spec seems to become more and more mature. No drastic API changes, only few new/improved features, but ones that are really useful.

As far as i can tell the most important features for future releases would be:

  1. direct state access
  2. multi-threaded rendering support

Can’t think of other important features at the moment.

Really great work from the ARB through the last 2 years!
(No, i haven’t forgiven you the GL3 thing, i still would have preferred a clean cut.)

So, how many hours will it take nVidia and AMD this time to announce the “world’s first GL 4.1 driver” ? :smiley:


According to Ars Technica, NVIDIA will release some 4.1 drivers on or before Wednesday, AMD shortly.


Once again it’s much more than what I was expecting. I can’t way to play around with it!

# GL_ARB_get_program_binary
# GL_ARB_separate_shader_objects 
# GL_ARB_debug_output 

With StarCraft II landing tomorrow, there’s really only one thing to say: “It’s about time!”

Now I want to see these extensions implemented on the widest range of hardware possible. Everything that IHVs still support should implement extensions.

Also, does anyone know what the expected hardware limitations of stencil_export will be? Will 3.x hardware be able to run it, or will it be reserved for 4.x?

OpenGL 4.1 is the sixth update to OpenGL specification in two years

Fifth. GL 3.3/4.0 were a single update; some features were simply spread between different hardware levels.

Either way, good job. OpenGL feels mostly finished now, ugly though some parts of it remain.

Really, really great job!!!
My congratulations!

I think there is just 2 extensions from OpenGL 4.1 that are actually limited to OpenGL 4 hardware:
GL_ARB_vertex_attrib_64bit and GL_ARB_viewport_array. I guess an OpenGL 3.4 specification would be nice even if we can still use the extension mechanism.

I had a lot of expectations with the separate shader but the extension feels quite limited in lot of senario so that we have to use a unified program. I still need to have a closer look.

DX10 has viewport and scissor arrays, so it should work on 3.x hw

The end of a sentence seems to be missing in glspec41.core.20100725.withchanges.pdf
2.11.3 Program Objects
Page 60

If a program object that is active for any shader stage is re-linked successfully, the LinkProgram command will install the generated executable code as part of the current rendering state for all shader stages where the Additionally, the newly generated executable code is made part of the state of any program pipeline for all stages where the program is attached.

Some more not consistant stuff in the API:

 void ViewportArrayv(uint first, sizei count, const float * v);
 void ScissorArrayv(uint first, sizei count, const int * v);
 void DepthRangeArrayv(uint first, sizei count, const clampd * v);

I’m not sure what to thing about that as the token “array” has always referenced “array buffer” in the past.

Typo in glspec41.core.20100725.withchanges.pdf page 470

L.3.98 Shader Stencil Export
Sharder stencil export enables shaders to generate a stencil reference value, allowing
stencil testing to be performed against per-shader-invocation values.

I had a lot of expectations with the separate shader but the extension feels quite limited in lot of senario so that we have to use a unified program.

Limited in what way? It even gives you a choice of rendezvous by resource or by name. I don’t know how it could be more flexible. Encapsulating combinations in state objects only makes sense.

Nice additions and great work.

But, personally I was expecting two more things this time:

  • shader includes in core
  • direct state access

Is there a larger problem with the shader include extension? After it is an ARB extension I expected its inclusion into 4.1 core.

Anyway, great work.


As far as I know there’s nothing wrong with GL_ARB_shading_language include. However, as far as I know it hasn’t been shipped yet by any of the OpenGL vendors. Before sticking it into Core, it will be nice to get some experience with it first.

(with my ARB hat on)

Ok, that is reasonable.

I, in my impatient nature, always hope that core features get adapted by the vendors faster. There are plenty of good and old extensions some vendors still do not support. So with making something a core feature i thought/hoped they would be kind of forced to implement it (looking at ATi here, nvidia is usually very fast with implementing new extensions).

So that leaves me hoping that the vendors at least support new extensions faster.