Update 8/5: By request from Khronos, I’ve added all the little ™ and ® ‘s.

Last week I posted a rather, well let’s just say “sensational”, article about the coincidental announcement by AMD/ATI of their new OpenGL|ES2.0 Driver for Desktops and Khronos’s announcement of the OpenGL® 4.1 spec which offers full backwards compatability with the OpenGL ES 2.0™ standard.  Most people wouldn’t care about OpenGL ES 2.0™ on the Desktop, as it’s the OpenGL Spec for Embedded Systems like set-top boxes and mobile phones, however the OpenGL ES 2.0™ spec is the foundation of the up-and-coming WebGL spec that promises plugin-free 3D graphics on the internet for all to enjoy.

Currently in the WebGL space, you have about 4 options:

  • Download a Plugin.  This is basically what Google started out with, you download a plugin that offers a translation layer between the actual hardware support and the WebGL spec.
  • Download an OpenGL ES 2.0™ Driver. This is what AMD/ATI Announced just prior to SIGGRAPH.
  • Download an OpenGL® 4.1 Driver. This is what NVidia announced during SIGGRAPH.
  • Download a new browser. WebGL is currently supported in some fashion or another in the latest dev releases of Chrome, Safari, and FireFox.

However, each of these has problems.  The whole point of WebGL is to be “plugin-less”, so the first one is out.  This leaves the other three, however, they have hidden issues as well.

Before I continue, many people ask “Why do I need a driver?”, and it’s a valid question.  Right now, without any OpenGL ES 2.0™ driver, you can go download development versions of Safari, Chrome, and FireFox and get WebGL.  It all works just fine, but you’ll notice it works a bit differently in each one.  This is what the driver is for: consistency. With working drivers in place, the visuals will be identical across browsers and hardware, because the rendering is all handled in the Driver, not the Browser.  Currently, browsers have a built-in translation layer that turns the JS-based OpenGL ES 2.0™ commands and turns them into regular OpenGL commands, and some do a better job than others.

Initially, as in the article, I was a bit harsh on ATI for releasing a dedicated OpenGL ES 2.0™ driver and favored NVidia’s announcement of an upcoming OpenGL® 4.1 driver that would encompass the same results.  This way, the user only has 1 driver to manage that in future systems will be installed by default, so the user literally has to do nothing.  Unfortunately, NVidia’s OpenGL4.1 support is limited to only the latest revisions of hardware:

You will need any one of the following Fermi based GPU to get access to the OpenGL® 4.1 and GLSL 4.10 functionality:

  • Quadro Plex 7000, Quadro 6000, Quadro 5000, Quadro 5000M, Quadro 4000
  • GeForce GTX 480, GeForce GTX 470, GeForce GTX 465, GeForce GTX 460

This means all those people with little GeForceM cards in their laptops are out of luck, as well as anyone with the GTX285 or earlier.  No doubt these cards have the horsepower to handle WebGL, but they’re currently unable to get the drivers necessary.

ATI’s solution is a bit less elegant, but by offering a dedicated driver they open it to all of their hardware, not just the latest and greatest.  Unfortunately, it does return us a bit to the previous world of loading plugins, except you’re loading a system-level driver instead.  However, this opens the world to all those old ATI Rage chipsets in laptops and FirePro’s in the wild, covering the full gamut of users.

In the end, I’m sure NVidia will offer a driver for WebGL to older hardware, but there’s no news on when that will be.   If NVidia lags too far behind, we could find ourselves in a “VRML Situation”, where individual browsers begin to support various extensions in attempts to best utilize the hardware, leading to inconsistencies and incompatibilities we already see with HTML & CSS across browsers.  Hopefully, with a good standards organization in place like Khronos, which VRML didn’t have, we’ll find consistent drivers coming to all platforms soon.