Guest Post by Gavriel State, Founder and CTO of TransGaming Inc.

From time to time we plan to open up our blog to guest posts from leaders in the field of 3D graphics. Today's guest post is written by Gavriel Slate, CTO at TransGaming.

In June, the O3D team announced O3D's new software rendering feature, which is powered by TransGaming's SwiftShader software rendering system. High performance software rendering is a critical feature to enable 3D applications on the web to have the same level of global reach as the traditional 2D web. While most current PC hardware now ships with at least basic graphics hardware capable of accelerated 3D performance, there are hundreds of millions of PCs that lack such hardware, or which have older GPUs that do not support the shader capabilities needed for O3D. For example, around 50% of Pentium 4 based PCs shipped with on-board integrated graphics chipsets with no shader features. Many such PCs with poor support for shaders are in the developing world, so without software rendering the 3D web could be inaccessible to huge parts of the planet.

Makers of massively multiplayer games have long understood this problem - Blizzard, the developer of the hit MMO World of Warcraft, has built their game to be compatible with graphics chips developed as far back as 2001, for example. And yet, World of Warcraft's 10 Million+ users pales in comparison to number of people using the web, which is currently estimated as 1.6 Billion. In order for 3D content to become part of the mainstream web, users of older systems can't just be left behind.

Luckily, SwiftShader provides a solution to this problem. Unlike traditional software rendering, SwiftShader uses highly efficient techniques to analyze and dynamically compile shaders and other parts of the graphics pipeline into optimized CPU-specific code. This code is then cached, so future rendering of similar objects always takes place with pre-built code. SwiftShader also takes advantage of CPUs with multiple cores. Using these techniques on modern CPUs, SwiftShader can in many cases actually outperform integrated graphics hardware.

In fact, in many ways, SwiftShader's software rendering model points the way for some of the developments now occurring on the hardware side. Over time, graphics technologies have been getting ever more programmable - first with ever more powerful vertex and pixel shader instruction sets, and more recently with geometry shaders and tessellation which actually generate new triangles for a scene. As GPUs become more flexible in this way, they begin to be useful for general purpose computations, traditionally the domain of the CPU. On the flip side, every year, CPU vendors are cramming in more and more cores capable of high performance vector processing. Chips such as Intel's forthcoming Larabee are designed around the idea of purely programmable software rendering on hardware with a massive number of cores.

Back in the here-and-now however, O3D will automatically switch to using SwiftShader if the hardware renderer on the end-user's system doesn't have enough oomph. Although content developed for O3D should just work regardless of whether the rendering occurs in hardware or in SwiftShader, it's important for developers to test how their O3D content will run on different configurations. Ideally, this includes testing content on different 3D hardware configurations as well as testing software rendering.

Note that on MacOS X and Linux, O3D uses OpenGL, so software rendering works differently. On the Mac, the underlying OpenGL implementation will automatically switch to it's own built-in software rendering if the feature you are trying to use is not available. On Linux, you can install the Mesa driver to switch your computer to use software rendering.