Unified shaders

Sep 27, 2006 07:07 GMT  ·  By

The Unified Shader concept pays dividends but at the same time it brings some additional troubles. Dis-unified Shading is a good approach and it will run DirectX 9 games fast for the months to come, but it won't help developers too much, as these chaps have to prepare to write unified code. It is a take-it-or-leave-it offer, as Microsoft requires them to use unified shaders from now on, showed The Inquirer.

Here's how the thing works, when you (over) load the Pixel Shader - which is the case in most of the games to come - the vertex Shader comes for free. In this case, you can tell your artists: 'don't draw a normal map, please model it for me'. This is how it works in DirectX 9 games. But when the developers go to Unified Shader and DirectX 10, this will take a different direction. When you load, or overload the Vertex engine, you automatically overload your pixels as well. And once it gets unified, you cannot count pixel and vertex budgets separately, as it is all unified budget. A 64 Unified Shader pipeline card can do any combination, including 32 pixel and 32 Shaders, 60 Shaders and 4 Vertex or 50 Vertex and 16 Shader information per clock, or any other combination that adds up to 64.

Nvidia is crawling, while ATI is about to launch its second-generation Unified Shader hardware and claims that it managed to totally eliminate vertex to pixel switching overhead, a problem that the developers have been struggling with for a while; and not only that, but they developed Ashli (Advanced Shading Language Interface) too. Ashli provides the artist a framework for mapping arbitrary complex shaders onto graphics shading hardware, while alleviating resource limitations concerns. Ashli is multi-lingual and supports a subset of the RenderMan, DirectX (HLSL) and OpenGL (GLSL). It operates on a program entity, which is a collection of shaders, destined for compilation. A RenderMan is a combination of any of displacement, surface, light, volume and imager shader types. HLSL and GLSL programs are composed of vertex and pixel (fragment) shaders. Incoming shaders are compiled to any of DirectX 9.0 Shader Models 2.0 and 3.0, and OpenGL ARB_vertex_program and ARB fragment program API's. Optionally, Ashli emits metafile in the Microsoft FX format, which encapsulates hardware shader segments and techniques. In addition, Ashli generates a formals text metadata structure that specifies the mapping of runtime appearance parameters onto hardware shader resources, such as input, constant, sampler and output registers.

Ashli embeds traditional complier technology with a front end and a back end component. Ashli folds all shader instances in a program into one, while optimally unrolling lighting constructs. The folded shader is then distributed onto graphics hardware processors - vertex and pixel. A simplification process converts all original input expressions to a native instruction set, to closely match the target low level language. Constant folding and dead code elimination is part of Ashli's optimization. Code generation is the final stage with the goal of reducing usage of temporary registers and dependant texture accesses.

Sometime, a complex high level shader may not fit the scarce graphics hardware resources. Exceeding the number of any of input, constant, temporary or sampler register or reaching instruction space limits is considered an unrecoverable compile error. Ashli automatically breaks the complex shader into many smaller segments (passes), where each segment uses up resources within the prescribed hardware limits.

Photo Gallery (2 Images)

Open gallery