Sick of only seeing the features of your video card shown off in benchmarks? Never fear, for James Wang sees big changes ahead.
When the first 3D games emerged, the game developers demanded more features and speed than even the fastest 3D accelerators could offer. Some eight years later, the best of 3D games, even those yet to be released, don't even scratch the potential of a $200 video card. Why?
In the pioneering days of 3D acceleration, it seems everyday someone would claim to have a killer engine. Everyday a new idea would pop up: voxels, quads, NURBS- you name it. Since then, the 3D market has expanded many magnitudes over. The technologies, documentation and experiences have all ripen. But where's the jaw dropping graphics? Will we ever be awed as we did in the first live running of Tomb Raider on Voodoo Graphics? The question that begs an answer is why have developers been outstripped in graphics technology by 3D vendors?
Features are gimmicksDoes it not bother you what happened to such hyped and promising technologies like Environmental Bump Mapping? What about T&L or T-buffer? Wouldn't it be good to know which features are essentially doomed to be duds and which will be the next big hit? The good news is in the future, there won't be any new 'features'.
A feature such as T&L or EMBM requires dedicated silicon. In the unlikely event that a developer wishes to implement this feature, he will need to write two sets of code: one to support this feature and another if the host machine's video card does not support this feature. When you have a handful of vendors pushing unique and often proprietary technologies, it will require so much redundant coding that no developer in their right mind (unless paid for by a vendor, as often is the case) would implement all the graphics technologies available at the time. The phenomenon of multiple, vendor dependent feature sets and shifting target platform is the prime factor why 3D technology has outstripped the speed in which it can be adopted. The only solution is to find a way for the developer to write code without worrying about the hardware that will be executing it. In other words, we need a machine independent, higher level shading language. This is the very essence behind DirectX 9 and OpenGL 2.0.
ABOVE: we are reaching a stage where CGI artists can feed slightly re-worked and cut-down versions of movie production media into a GPU and render at near real time speed using multi-pass algorithms. Eventually, older CGI productions will be able to done in real time little visual difference.
DirectX 8 was revolutionary because it introduced programmability into the graphics pipeline. However, it didn't help with the issue of diverging standards. All the programmability in the world isn't going to be realised if the developer is faced with v1.0, v1.1 and v1.4 shaders, each for a specific vendor.
To help games realise the benefits of shaders faster, we need to save programmers the time used in making vendor specific adjustments for their games. After all, not all developers are as fanatical as Carmack, who wrote a different rendering path for nearly every graphics card released since the Geforce 256 for Doom III. With the introduction of DirectX 9 and OpenGL 2.0, ideally only one set of code will be written and the time saved spent on more important things.
A Higher Level Shading Language's (HLSL) core characteristic is abstraction from hardware. Any shader code, no matter how complex should automatically be decomposed by the compiler to multi-pass on the host video card. For example, code written in a HLSL that's 100 vertex instructions long should be done in one cycle on a GPU which can deal with 100 instructions per cycle but automatically decompose into multiple passes on less capable GPUs. This way the developer can write code that target the fastest GPUs and not worry that half of the world's machines won't run. It'll definitely be slow when multi-passed on less capable processors, but by scaling down the resolution, one can still see the shader effects as they were intended.
There are a few conditions which need to be met before either of the two languages become useful. The first is a large installed user base of DirectX 8 level hardware. This will not happen until at least another year and until then, HLSL will not be able to flex its muscles. Unavoidably, some effects just simply can't be decomposed into DirectX 7 operations. The second requirement is good compilers which can decompose HLSL into machine code with relatively good efficiency. NVIDIA's Cg compiler is the only one available at this time. With these two in place, a developer can finally hope to make use of shaders with confidence and perhaps even catch up with the blazing fast development in 3D technology.
DX 8 vs. DX 9 shaders In the DirectX 8 era, shaders were programmable but with severe limitations -- you couldn't control them. Suppose you want to run a vertex shader over a triangle mesh. You could write a long string of instructions and execute it. But you could not make conditional branches like “if the current state is such, then execute this shader, if not, go down the other shader path instead.” Conditional branches which are at the heart of true programmability weren't available. Another essential ingredient that was missing was loop functionality.
Loops allow you to perform a specific task indefinitely until a certain condition has been reached. You may want to repeat certain shaders until a desired effect has been reached for example. With the inclusion of loops and conditional branching into the vertex and pixel shaders, the new higher level shading languages finally brings programmability to a near CPU level.
With new flexibility also comes new trouble. When working with loops and shaders, the accuracy of the input will tend to degrade as each loop is executed if the value is not kept in a high precision format. It does no good to go through thousands of calculations when you are always rounding to the nearest integer; in the end your data has accumulated too much error to be useful. This is why along with the introduction of long, loop-able shaders has come a floating point representation for data. Floating point preserves decimal places so your data can go through myriad twists of shader routes and still come out relatively accurate. Colour depths of 96-bit and 128-bit colour are supported, which is in same league as that of CGI production.
Up until now, we've discussed the core essentials that are common between OpenGL 2.0, DirectX 9, and Cg. Because their goals are the same, their differences are actually quite subtle. Any one of the three languages will be a huge leap over what we have today. Most of the differences are motivated either by industry politics or syntax wars. OpenGL 2.0 -- due end of 2002The chief body promoting this standard is 3D Labs. NVIDIA proposed an alternative named 'Cg', which received only one vote -- from themselves. There's also a Stanford model which is well known but does not allow easy backward compatibility to the existing GL1.3 standard and hence the 3D Labs proposal is now set as the shading language for OpenGL 2.0. Because the Architectural Review Board that governs OpenGL incorporates many vendors from a variety of fields (Intel, SGI, NVIDIA etc), forming a standard which can all be agreed on is a difficult and strenuous process. The
Issue: 137 | June, 2012