05/08/2010 The really too early OpenGL 4.1 drivers status

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!
Drivers: AMD Catalyst 10.7 betanVidia Forceware 259.09
410-program-separateA lot of things...
410-program-64
410-program-primitive-blockGeometry input block unsupported
410-debug-outputAMD_debug_output support only
400-transform-feedback-object
400-sampler-gather
400-sampler-fetchARB GLSL function instead of core GLSL function
400-program-subroutine
400-program-64Draw calls ignored, double not supported
400-primitive-tessellationNo full support for user-defined blocks
400-primitive-instancedNo full support for user-defined blocks
400-fbo-texture-array
400-fbo-rtt
400-fbo-multisampleMin/mag tex param required
400-draw-indirect
400-buffer-texture-rgbTBO fetch not correct
400-blend-rtt
330-query-conditionalCan freeze the system! Oo

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!

AMD OpenCL 1.1 drivers available >
< OpenGL 4.1 released at Siggraph 2010
Copyright © Christophe Riccio 2002-2016 all rights reserved
Designed for Chrome 9, Firefox 4, Opera 11 and Safari 5