Latest posts

/ Technical / Latest posts >>

• 01/09/2010 Ovt'sa 1.2.0.0 released
• 28/08/2010 OpenGL Samples Pack 4.1.1.1 released (updated)
• 26/08/2010 GLM 0.9.0.3 released
• 22/08/2010 OpenGL Samples Pack 4.1.0.0 released
• 18/08/2010 OpenGL 4.1 review
• 16/08/2010 AMD OpenCL 1.1 drivers available
• 05/08/2010 The really too early OpenGL 4.1 drivers status
• 02/08/2010 OpenGL 4.1 released at Siggraph 2010
• 18/07/2010 OpenGL community drink at Siggraph 2010
• 13/07/2010 Git success story in parallel development

Ovt'sa 1.2.0.0 released

01/09/2010 - Technical / Content / Projects / Ovt'sa >>

5 years later... I gave a name to my simple raytracer! This is actually due to the upgrade of the project to my current development process. I need a Git repository for it which implies a SF.net project... so let gives it a great name!

Ovt'sa is the russian word for 'Sheep'. I guess everyone will appreciate that it is an obvious and perfect name for a raytracer!

The project uses CMake and will build on Visual Studio 2005, 2008, 2010 and GCC 4.5.0. Over version 1.1, this is just a minor update.

• Download: Ovt'sa 1.2.0.0 (ZIP, 12.23 MB) (7Z, 6.76 MB)
• Link: Submit a bug report

OpenGL Samples Pack 4.1.1.1 released (updated)

28/08/2010 - Technical / Content / OpenGL Samples >>

The OpenGL Samples Pack 4.1.1.0 is released with new samples which mainly features several layered rendering samples for OpenGL 3.3, 4.0 and 4.1.

I have also added an OpenGL 4.0 sample for dynamic sampler arrays, uniform buffers and renamed some samples for consistency with OpenGL.

This release contains 73 samples for Visual Studio 9/10 - 32/64 bits thanks to CMake.

Updated

Version 4.1.1.0 has a build problem with GLEW that has been fixed.

GLM 0.9.0.3 released

26/08/2010 - Technical / Content / Projects / GLM >>

GLM 0.9.0.3 is a revision that fixes various problems on non-squared matrices.

• Download: GLM 0.9.0.3 (ZIP, 1.2 MB) (7Z, 684 KB)
• Link: Submit a bug report

OpenGL Samples Pack 4.1.0.0 released

22/08/2010 - Technical / Content / OpenGL Samples >>

The OpenGL Samples Pack 4.1.0.0 is available. As the version indicated it, this release includes some OpenGL 4.1 samples for a total of 68 OpenGL samples.

The OpenGL 4.1 has been written upon nVidia beta drivers 259.31 and thus they should be considered as beta samples.

I have explored the separate programs, the new viewports, the debug output, the extended 64 bits capabilities and the new varying locations. There are also some new samples for OpenGL 4.0 and 3.3.

Also nVidia drivers behave very badly with blocks so I decided not to use them most of the time and instead build a dedicated samples to point out the problem. On other side, it's quite surprizing that nVidia has already fixed some of the bugs I have reported in thir second OpenGL 4.1 beta drivers released and I guess we are going see soon improvements for their OpenGL 4.1 support.

OpenGL 4.1 review

18/08/2010 - Technical / Comments / OpenGL >>

In this article we are going to have a closer look at OpenGL 4.1 and the new extensions that come along with its release.

The proper OpenGL 4 hardware features: double float vertex attributes and operations precision

OpenGL 4.1 includes the new extension called GL_ARB_vertex_attrib_64bit" which trivially adds support for double precision floating point scalars and vectors for the vertex attributes. OpenGL already provides such support but usually the double values are converted to single precision floating point values. This extension ensures that this precision will be kept. An important detail is that double attribute can consume more than one location which will have some consequences in the software design. This behaviour isn’t new as GL_ARB_gpu_shader_fp64 introduced it for double uniforms.

OpenGL 4.1 also integrates GL_ARB_shader_precision which is the first extension that defines no value, API functions nor GLSL functions. It simply clarifies the accuracy of various GLSL functions.

• a+b, a-b, a*b: correctly rounded
• <, =<, ==, >, >=: correct result
• a/b, 1.0/b: <= 2.5 ULP
• a*b+c: correctly rounded single operation or sequence of two correctly rounded operations
• fma(): same as a*b+c
• pow: <= 16 ULP
• exp, exp2: <= 3 ULP
• log, log2: <= 3 ULP
• sqrt: <= 3 ULP
• inversesqrt: <= 2 ULP
• conversions: correctly rounded

All in all the proper OpenGL 4 hardware features are quite minors unlike what I was expecting but it provides much more interesting features which would actually work on OpenGL 2.1 and OpenGL 3 hardware.

A new development area through OpenGL debugging (GL_ARB_debug_output)

OpenGL 4.1 comes along with a new ARB extension which is just so great that I want to speak about it first: With GL_ARB_debug_output, the ARB has finally shows some mercy for us OpenGL developers by providing a more advanced mechanism based on callbacks than glGetError for debuggging. This extension brings a new era for OpenGL!

GL_ARB_debug_output is an extension only and will probably stay as an extension as the ARB thought it is just good for developers, leaving the possibility of user of OpenGL applications to not have such feature. This may imply 2 types of OpenGL drivers in the future, one for developers and one for users. This is an interesting idea even if I actually see in the debug output capabilities, a way to generate a crash dump.

This extension is supported by nVidia drivers and through GL_AMD_debug_output on AMD drivers. For this extension "supported" doesn't mean much because it could just return the glGetError but we can also imagine more accurate messages so that it will be the reponsability of AMD and nVidia to make the best of this extension on a long term development process.

• glDebugMessageControlARB(GL_DONT_CARE, GL_DONT_CARE, GL_DONT_CARE, 0, NULL, GL_TRUE);
• glDebugMessageCallbackARB(&glf::debugOutput, NULL);

Separate program object (GL_ARB_separate_program_objects)

As part of OpenGL 4.1 core, GL_ARB_separate_program_objects is another welcome feature expected from a long time and quite successful in it's approach.

It allows to independently use shader stages without changing others shader stages. I see two mains reasons for it: Direct3D, Cg and even the old OpenGL ARB program does it but more importantly it brings some software design flexibilities allowing to see the graphics pipeline at a lower granularity. For example, my best enemy the VAO, is a container object that links buffer data, vertex layout data and GLSL program input data. Without a dedicated software design, this means that when I change the material of an object (a new fragment shader), I need different VAO... It's fortunately possible to keep the same VAO and only change the program by defining a convention on how to communicate between the C++ program and the GLSL program. It works well even if some drawbacks remains.

With the separate programs, the fragment shader and vertex shader stages can be independant so that we are free to change the fragment program without touching the VAO. Finally! It's incredible all the conscequences of an awfully designed API (VAOs)!

So just like Direct3D, OpenGL support separate programs but actually and we should get use to it, OpenGL outperform the Direct3D design. We have had a single program for ages for some reasons: the resource by name convention that requires a linking step across stages but also because it allows some effective compiler optimizations. From those, the one I rank number 1 discards all the unused varying variables... This consideration has an impact on the design decision of the extension.

GL_ARB_separate_program_objects is a superset of GL_EXT_separate_program_objects extension including just the right improvements to transform a badly design extension to a great extension. With the ARB version, a new object called pipeline program object is used to attach multiple programs. Also, it's possible to communicate between stages using user-defined variables instead of the deprecated varying variables... GLSL programs can contained multiple shader stages so that multiple stages can be linked and optimized all together. Chances are that vertex, control and evaluation shaders will be design to be use all together and conscenquently we can apply some extra optimizations by linking them. Finally, GL_ARB_separate_program_objects defines direct state access functions glProgramUniform* for all the glUniform* functions!

• glGenProgramPipelines(1, &PipelineName);
• glBindProgramPipeline(PipelineName);
• glUseProgramStages(PipelineName, GL_VERTEX_SHADER_BIT, ProgramName[program::VERTEX]);
• glUseProgramStages(PipelineName, GL_FRAGMENT_SHADER_BIT, ProgramName[program::FRAGMENT]);

• #version 410 core
• // Declare all the semantics
• #define ATTR_POSITION 0
• #define ATTR_TEXCOORD 4
• #define VERT_TEXCOORD 4
• #define FRAG_COLOR 0
• uniform mat4 MVP;
• layout(location = ATTR_POSITION) in vec2 Position;
• layout(location = ATTR_TEXCOORD) in vec2 Texcoord;
• layout(location = VERT_TEXCOORD) out vec2 VertTexcoord;
• void main()
• {
• gl_Position = MVP * vec4(Position, 0.0, 1.0);
• VertTexcoord = Texcoord;
• }

• #version 410 core
• // Declare all the semantics
• #define ATTR_POSITION 0
• #define ATTR_TEXCOORD 4
• #define VERT_TEXCOORD 4
• #define FRAG_COLOR 0
• uniform sampler2D Diffuse;
• layout(location = ATTR_TEXCOORD) in vec2 Texcoord;
• layout(location = FRAG_COLOR, index = 0) out vec4 FragColor;
• void main()
• {
• FragColor = texture(Diffuse, Texcoord);
• }

GLSL program binary (GL_ARB_get_program_binary)

Another feature we have been waiting for a long time: Program binaries. I must say, this is one topic I haven't followed closely nor thought about it but for what I have understood, the capabilities of loading and saving GLSL binaries provided by GL_ARB_get_program_binary and OpenGL 4.1 is just a subset of the wishes out there.

I'm not sure about how useful this is. This extension comes from the OpenGL ES extensions GL_OES_get_program_binary with a subtle change which favour the retrivable of the program binary after being used or at the end of the program... and here is my problem. A GLSL program is sometime rebuild considering the states context so that there are effectively several different binaries per program. What actually involves a linking of the program? This is fairly undocumented so far but I have high expectation from GL_ARB_debug_output for that regard.

The goal is not to be able to release a software without the GLSL source. A GLSL binary is platform dependant and loading a GLSL binary might fail which involves GLSL sources rebuild. We might see some standard binary formats in the future but so far there is nothing in the OpenGL world. However, binary formats has been present on the OpenGL ES world for a while and many propritary extensions have been released: GL_AMD_program_binary_Z400, GL_IMG_program_binary, GL_ARM_mali_shader_binary.

Conscequently, the program binary is just a cache system for GLSL binaries... It is really going to make the loading significantly faster? I have some doubt about it.

Multiple viewport (GL_ARB_viewport_array)

One difference from Direct3D and OpenGL is that OpenGL allows multiple rendertarget having different sizes. This is actually a contain relaxed from GL_EXT_framebuffer_object when is has been promoted to GL_ARB_framebuffer_object and OpenGL 3.0. Interestingly, this capability seems to me pretty useless without GL_ARB_viewport_array. This allows to render G-Buffers at various resolutions (and hence saving some memory bandwidth) in a single pass before the final G-Buffer compositing for example. I also imagine some interesting use for cascade shadows using layering rendering. It might look like a small feature at first look but for the rendering technique side, it's actually a key feature from which I expect a lot of performance benefits in lot of cases.

To use the extra viewports, GLSL includes a new variable called gl_ViewportIndex that can be written in the geometry shader.

• glViewportIndexedfv(0, &vec4(0.0f, 0.0f, Size)[0]);
• glScissorIndexedv(0, &ivec4(0, 0, ivec2(Size)[0]);
• glDepthRangeIndexed(0, 0.0f, 0.5f);
• glViewportIndexedfv(1, &vec4(0.0f, 0.0f, Size * 0.5f)[0]);
• glScissorIndexedv(1, &ivec4(0, 0, ivec2(Size * 0.5f)[0]);
• glDepthRangeIndexed(1, 0.5f, 1.0f);

Compatibility with OpenGL ES 2.0 (GL_ARB_ES2_compatibility)

It could be hard to believe but OpenGL ES 2.0 has features that OpenGL 4 didn't had until OpenGL 4.1. GL_ARB_ES2_compatibility is the last extension integrated to OpenGL 4.1. This extension is fairly a boring one that only aims completeness and to ensure that OpenGL 4.1 is a superset of OpenGL ES 2.0. Chances are, I'm never going to use any of the new functions: glReleaseShaderCompiler allows to unload the GLSL compiler to save some memory; glShaderBinary to load shader binaries... but we have glProgramBinary now; glGetShaderPrecisionFormat to get GLSL precision of each variable types (GL_LOW_FLOAT, GL_MEDIUM_FLOAT, GL_HIGH_FLOAT, GL_LOW_INT, GL_MEDIUM_INT, GL_HIGH_INT). What if the variable if a uvec*???; glDepthRangef and glClearDepthf which takes float parameters instead of doubles. Finally, glVertexAttribPointer can take GL_FIXED for its type parameter, for fixed point data.

Features for the sake of... something, why not but I would mark most of them as deprecated.

A bunch of things for WebGL

I quite believe that a lot of things released with OpenGL 4.1 have been done for WebGL. It's incredible the entousiam around this technology, probably higher than OpenCL. WebGL involves a large number of developers and users in a medium term: basically everyone all in all! WebGL is based on OpenGL ES 2.0 so that we really need OpenGL ES 2.0 features on desktop. OpenGL 4.1 contains all the OpenGL ES 2.0 features hence WebGL implementations can rely on OpenGL 4.1 drivers to implement all the features. To reinforce OpenGL ES 2.0 on desktop, an OpenGL ES 2.0 profile have been created through WGL_EXT_create_context_es2_profile and GLX_EXT_create_context_es2_profile. I guess, this way it will be easier for low-end OpenGL implementations to support OpenGL ES 2.0 and it isn't require to load a large amount of function pointers that anyway shouldn't be used in a WebGL environment.

Following the WebGL requirements, I think the ARB also build the following extensions: WGL_ARB_create_context_robustness, GLX_ARB_create_context_robustness and GL_ARB_robustness which introduces functions which prevent buffer overflows in a similar way that strncpy is for strcpy... These extensions will be a great use for Chrome developers, Firefox developers, Opera developers, Safari developers (Internet Explorer developers?) and we really want them to do a good use of them, but for the rest of use, I'm not sure.

Improved cooperation with OpenCL (GL_ARB_cl_event)

OpenCL has made steps toward OpenGL since its release through extensions but for once it's OpenGL which make a step toward OpenCL with the release of the extension GL_ARB_cl_event. This extension only allows to create an OpenGL sync object from an OpenCL sync object for more efficient images and buffers sharing between the 2 APIs.

Writing into the stencil buffer from a fragment shader (GL_ARB_shader_stencil_export)

Finally, an other extension that might generate some clever ideas based on the stencil buffer. GL_ARB_shader_stencil_export allows to write the reference value of the stencil test from a fragment shader which actually means writing into the stencil buffer when glStencilOp is set to GL_REPLACE.

Conclusions

OpenGL 4.1 has reach Earth in a quite different way I expected it. I expected a OpenGL 4 hardware oriented release but it's definetly not the case and actually it comes closer to my wish-list than my expectations.

The BIG missing feature is the overload buffer and image load and store embody by GL_NV_shader_buffer_load, GL_NV_shader_buffer_store and GL_EXT_shader_image_load_store extensions. An OpenGL 4.2 release with only these features would already be amazing!

Unfortunately, OpenGL 4.1 doesn't include GL_EXT_direct_state_access as a lot of people would expect. However, AMD as release drivers supporting this extension so that I presume that the ARB has an agreement on the goods of this approach. Moreover, OpenGL 4.1 integrates through GL_ARB_separate_shader_objects a subset of the direct state access extension. Thus, I think we have here an idea on how the ARB want to bring this approach in core. I don't think that the deprecated feature will ever have direct state access in the OpenGL Compatibility profile. From my point of view, this would be for the best. For the core features, the direct state access will probably reach core through new extensions.

Finally an angry word about the lack of conscistency of this new 4.1 specification. It's almost unbelievable! Sometimes it's so obvious that I stay stunned. I might be able to find in every extension something which doesn't follow the OpenGL convensions. This is a growing concern I have seen the OpenGL 3.0 release. OpenGL is a specification where every single word and API token mean something and it actually defines in the specification... at least, it uses to be. For example, OpenGL 3.0 introduces "geometry shader" while this stage was already cleary defines in the specification by "primitive". What is a "geometry" in OpenGL? Don't ask me I have no idea, it's undefined. OpenGL 4.1 is now using the token location and index for about everything, confronted to an API declarations or a specific paragraph it happens very often that the uses of some tokens is misleading. OpenGL 4.1 now introduces some new tokens like sub-pixel which comes from nowhere of arrays for a set of while arrays have been clearly defines since OpenGL 1.1. I quite believe that the overall "blocks" concept is mostly unspecified leading really different implementations on AMD and nVidia drivers. etc!!!

Next step, my OpenGL 4.2 wish-list!

• Download: OpenGL 4.1 core specification
• Download: GLSL 4.1 specification
• Link: OpenGL 4.1 man pages
• Link: My OpenGL 4.0 review
• Link: My OpenGL 4.1 wish-list

AMD OpenCL 1.1 drivers available

16/08/2010 - Technical / Comments / OpenCL >>

AMD has released OpenCL 1.1 drivers with the ATI Stream SDK 2.2; a release 2 months after the specification release. nVidia has an OpenCL 1.1 drivers but only available for nVidia registred developers.

So far, I haven't seen really good results of OpenCL benchmark on AMD. I don't really know if it's a hardware limitation or a lack of optimization of the drivers or maybe both. Some people will say that nVidia have a more advanced cache system but this is not true on GeForce 8/9 hardware which remains really efficient. One think is sure, nVidia has more experience through CUDA and their OpenCL implementation is built on top of it.

With the progress of AMD on OpenCL, I guess it's going to be interesting to observe OpenCL benchmarks in the next months!

• Link: ATI Stream SDK 2.2 for OpenCL 1.1
• Link: nVidia OpenCL 1.1 for registered developers

The really too early OpenGL 4.1 drivers status

05/08/2010 - Technical / Comments / OpenGL >>

Both AMD and nVidia have released drivers for the OpenGL 4.1 release. On AMD side it's titled beta OpenGL ES 2 drivers and on nVidia side it's an beta OpenGL 4.1 drivers. More than the OpenGL ES 2 support, the really interesting part is the EGL support on desktop! A really old community request and eventually, I expect to switch to EGL even if I haven't tried it yet. I explored if there is some bits of OpenGL 4.1 in AMD drivers but it does what it says: No OpenGL 4.1.

I was working on an OpenGL Samples Pack 4.X.0 version featuring extensions but with the release of OpenGL 4.1, I have to give another perspective on this version and focus on OpenGL 4.1 features indeed.

I am using an OpenGL Samples Pack 4.1.0 development version for this drivers status test. The OpenGL Samples Pack contains a lot samples from OpenGL 2.1 to OpenGL 4.1 but I focus only on the OpenGL 4.X samples for these tests. The OpenGL 3.3 drivers are now quite mature and I have included only one test which can be quite a problem on AMD platform. The tests have been done on a Radeon HD 5850 and a GeForce GTX 470.

• White: Unsupported.
• Green: the sample work just like expected.
• Orange: The sample doesn't work correctly but with a workaround is works.
• Red: The sample does't work and I haven't found any workaround.
• Black: Really distubing problem!

What to think about those results? First, it's much better than in my previous status for the support of OpenGL 4.0 and the OpenGL 3.3 is quite good now. nVidia seems to have better drivers according to these results but I quite think that it is more or less true. I would say that feature wise, the nVidia drivers is better than AMD's and for this I can give a couple of examples: bindless graphics(I mean, nice!), EXT_shader_image_load_store(I mean, super nice!) and some bit of OpenGL 4.1 support. However, these tests doesn't show how the GLSL compiler can be annoying and return irrelevant error messages sometime.

On the AMD side, the philosophy is maybe a bit different which implies an other repartition of the efforts. I quite like the GLSL compiler, I don't think it is perfect but compared to the nVidia GLSL compiler it gives nicer error messages. For the development it's great! It's necessary. AMD has been the initiative of the GL_ARB_output_debug extension with the GL_AMD_output_debug extension which is the feature announced at Siggraph 2010 that I am the most existed: In everyday life for an OpenGL developer, it will change everything by making OpenGL development much more efficient! It's easy to integrate in a software, to actually attached some debug informations for a bug report. I just think that it's going to make OpenGL drivers and softwares much more reliable. So far nVidia drivers more or less only returns what glGetError would return in a much more convenient way, however this extension aims much more! AMD has updated the man pages for OpenGL 3.3 and 4.1... and cherry on the cake, EGL support! Considering all these, I might say that AMD is currently more development centric than nVidia which is more features centric.

Fell free to desagree with me, I often disagree with myself! Actually, all in all, what I find really interesting is just the idea that OpenGL immediate future is linked to these 2 sides.

Finally, I haven't spoke about (or tested) Intel and Apple implementations... MacOS X 10.6.4 is stocked to OpenGL 2.1 support with all the features of OpenGL 3.0 but GLSL 1.30, through the OpenGL extensions. I think that MacOS X is a great platform (happy owner of a MacBook Pro!) and the interest for gaming on MacOS X is high so it deserved high-end OpenGL support... not yet the case. On its side Intel OpenGL implementation is technically irrelevant and out-dated. When we see that Intel represents half of the graphics chip market and I think it's the biggest limitation for OpenGL grows and real-time graphics everywhere for everything (Like my web browser!). In the future, I think OpenGL aims up to high quality games and CAD softwares down to Minesweeper and Paint. How to choose to use OpenGL everywhere for everything if we can't rich half of the platforms available? I completely dream of AMD and nVidia saling their graphics cards with a "It makes Internet faster!" sticker, NICE! I mean, GL_ARB_robustness, GL_ARB_ES2_compatibility and WebGL are a statement for that.

Some OpenGL community members said that with the OpenGL 4.1 release that OpenGL is almost done. In my OpenGL 4.0 review, I was stating I believe that OpenGL was at 2 or 3 iterations to be stable. Now, I think we still need 1 or 2 iterations (1 year) for important features and refinements and I will be detail these in my OpenGL 4.1 review and my OpenGL 4.2 with list!

• Download: OpenGL Samples Pack 4.0.1.2 (ZIP, 12.72 MB) (7Z, 6.76 MB)
• Link: nVidia OpenGL 4.1 beta drivers
• Link: AMD OpenGL ES 2.0 beta drivers
• Download: OpenGL 4.1 core specification
• Download: GLSL 4.1 specification
• Link: OpenGL 4.1 man pages
• Link: OpenGL 3.3 man pages
• Link: OpenGL BOF 2010 slides
• Link: AMD EGL code sample

OpenGL 4.1 released at Siggraph 2010

02/08/2010 - Technical / Comments / OpenGL >>

My little finger is usually realiable but this time was an exception: I was afraid that we will not see OpenGL 4.1 at Siggraph 2010 and I am glade I was wrong.

On the nVidia side, the announcement says full OpenGL 4.1 extensions support. On AMD side, the announcement state of an OpenGL ES 2 support with EGL.

An new extension called GL_ARB_ES2_compatibility and part of OpenGL 4.1 has been written to add the missing OpenGL ES 2 features in OpenGL 4. This is probably meant to improve WebGL support on desktop.

OpenGL 4.1 contains the following extensions: GL_ARB_seperate_shader_objects, GL_ARB_viewport_array, GL_ARB_get_program_binary, GL_ARB_shader_precision and GL_ARB_vertex_attrib_64bit. Actually, from these extensions only the 2 last ones are really OpenGL 4 level of hardware (Radeon 5800 and GeForce 400 series). So why not an OpenGL 3.4 specification? I actually asked the question to Barthold Lichtenbelt who gave me his thought: how to deal with the fact that OpenGL 3.4 would be a superset of OpenGL 4.0 and a lowerset of OpenGL 4.0? Yes, this is tricky so I think we will be limited to OpenGL 3.3 + a set of extentions which is quite ok actually.

The main OpenGL 4.1 feature is definetly the GL_ARB_seperate_shader_objects extension that allows to change program stages independently. A side and amazing feature from this extension is the direct state access for the uniforms. Also in AMD drivers 10.7, the direct state extension is fully supported and for having testing it, it works perfectly! A new age for OpenGL development is here.

GL_ARB_get_program_binary allows to cache a system the GLSL program binary. The binaries are not meant to be distributed with software releases and the loading of binaries can fail for any reason, new graphics card in the system, updated drivers could be the most common cases. GLSL compilers are so fast that I am not really sure how useful it's really is.

The only real OpenGL 4 hardware features are embodied by GL_ARB_shader_precision and GL_ARB_vertex_attrib_64bit extensions which are actually minor updates from OpenGL 4.0 features.

A set of extensions have also been released and from those my favorite is definetely the GL_ARB_debug_output which is just an ARBify version of GL_AMD_debug_output. Based on the previous AMD extensions this extension FINALLY gives some interesting debugging functionnalities to OpenGL.

On the level of the tools and documentations, OpenGL Extensions Viewer already support OpenGL 4.1 within version 3.31. The OpenGL man pages have been updated for OpenGL 3.3 and OpenGL 4.1. For the rest, it's pretty limited no support for GLEW yet or even glext.h and gl3.h.

Other great announcements during the OpenGL BOF: GLU3, KTX and even the up coming support of EGL on desktop with samples! AMD already provides EGL support in their last drivers. Finally, an updated OpenGL conformance test should be available soon.

This new OpenGL version is actually more an OpenGL 3.4 that an OpenGL 4.1 from my point of view. However, the improvements in every developers days is going to be significant and makes OpenGL a more than ever a great competitor to Direct3D. Considering the evolution of the graphics market, the commitment of nVidia and AMD for OpenGL it's really good to be an OpenGL programmer those days and it's going to be better and better!

• Link: OpenGL BOF 2010 slides
• Download: OpenGL 4.1 core specification
• Download: OpenGL 4.1 compatibility specification
• Download: GLSL 4.1 specification
• Link: nVidia OpenGL 4.1 beta drivers
• Link: AMD OpenGL ES 2.0 beta drivers
• Link: OpenGL registry with everything
• Link: OpenGL 4.1 man pages
• Link: OpenGL 3.3 man pages
• Link: OpenGL 2.1 man pages

OpenGL community drink at Siggraph 2010

18/07/2010 - Technical / Comments / Documentation >>

With Siggraph 2010 next week I thought it would be the perfect opportunity to meet some people from the community and I launched the idea of the informal community drink.

The event will take place on Monday, July 26th, 6pm at the Veranda Bar in the Fugueroa Hotel.

Veranda Bar in the Figueroa Hotel - 939 South Figueroa Street - Los Angeles, California 90015

For more information, leave a message on the OpenGL.org thread, send me an email or just show off during the evening!

Thanks to Patrick Cozzi for his motivation for this! Let's drop a stone for what I would enjoy to see becoming a regular event!

• Link: Thread on the OpenGL forum

Git success story in parallel development

13/07/2010 - Technical / Content / Articles >>

The time pass but my enthusiasm for Git continues to glow! Actually, it seams that I am not the only one to enjoy Git as surprisingly my last article on Git became the most read post (if I can rely on my website statistic...) before a lot of OpenGL articles as it can be expected.

One great tool with Git is Gitk. I was using it on the OpenGL Samples Pack and suddenly I was amazed by the graph Gitk gave me: A demonstration of the effectiveness of a development process based on Git! With Git, it's so easy to work on different things, on different version... in parallel!

The yellow labels are tags that I use as releases markers and the green labels are branches. Enjoy the branches communications.

With the OpenGL Samples Pack the graph is quite complex relatively to the project size. However, it's just what I need and this is where it's a success story. G-Truc Creation website development is also based on Git but the graph is much simpler (quite boring one actually) graph but it's still just what I need.

In conclusion, I would like to say that Git allows a flexible way to develop a project where features doesn't need to be locked into #define but are instead manage by the Version Control System... just like it should be! Git makes easy and nice the process of building the feature list of a release using a version branch and several feature branches. If a feature isn't finish for the release, it's easy to delay it to a future release and if the development of a feature fail or get cancelled, it's easy to discard it without polluting the code. A whole strategy to build better software but also, I insist on the importance of it, software nicer to work on.