Xen Shader System (Overview)

The goal of the Xen Shader System is reliability and catching errors early. It is high performance and has very low resource usage.


The fundamental change is that xen shaders are not content. They are treated as code in the project.

To achieve this, xen includes a Visual Studio CustomTool plugin. This plugin pre-processes .fx shader files at edit/compile time, generating code files that are compiled directly into the project binary.
A class will be generated for each Technique in a shader file. This class embeds the compiled shader byte code, so the original .fx file is not required at runtime.

This can be best shown with an example:

float4x4 worldViewProj     : WORLDVIEWPROJECTION;
float4 colour              : GLOBAL;
float scale = 1;
	
	
// vertex shader, scales the mesh by the scale attribute
void Example03VS(	
                   float4 position        : POSITION, 
               out float4 positionOut     : POSITION)
{
   position.xyz *= scale;
		
   positionOut = mul(position,worldViewProj);
}
	
	
// pixel shader, returns the global colour
float4 Example03PS() : COLOR 
{
   return colour;
}
	
	
// Technique that uses the shaders
technique Example03Technique
{
   pass
   {
      VertexShader = compile vs_2_0 Example03VS();
      PixelShader  = compile ps_2_0 Example03PS();
   }
}

This is a simple shader; drawing geometry with a user defined solid colour and a scale.


The class generated by the plugin does several things for you, including:
  • Because worldViewProj is marked with the 'WORLDVIEWPROJECTION' semantic:
    • The plugin understands 'WORLDVIEWPROJECTION', and this shader attribute will automatically be set to the world * view * projection matrix
    • The world * view * project matrix will only be calculated when it changes (in full or in part) - saving valuable CPU time
  • Because colour is marked as 'GLOBAL':
    • The plugin will generate code that assigns this value to an application-wide global of the same name/type
    • The assignment will be skipped if the global hasn't changed
    • Xen validates the global has actually had a value set by the application
  • scale doesn't have a semantic. It does have a default value:
    • A property is generated by the plugin, allowing the scale attribute to be set directly as a float
    • The default value is assigned

An example use:

Shader in use

The application need only call the 'Bind' method to have the shader bound. From this point on, the shader is in use and geometry can be drawn.
Subsequent calls to Bind will skip their internal logic unless something has actually changed. GraphicsDevice state changes are kept to an absolute minimum.
All globals, attributes and matrices will be kept up to date for you. There is no need to call Bind() again, although doing so won't hurt performance.


About the generated class:


All generated shaders implement the interface IShader. IShader includes Bind(), the ability to set attributes by ID, etc.

The generated class in this example is small. It's overhead can be measured at around 100 bytes per instance (most of this being the 64 byte matrix). The DirectX shader byte code is stored globally, as are the generated VertexShader and PixelShader objects - minimizing overhead.

Xen provides an efficient method to reuse a global instance of a shader, specified by type.

Texture samplers without filter/wrap state specified will default to wrap bilinear filtering - otherwise sampler state would be dependent on the last used shader.

Debug xen builds will validate the vertex shader input with the currently bound vertex buffer(s). The user will be alerted if the vertex shader is trying to access inputs not present in the vertex data.

Preshaders (if they are used) are generated as pure .net code, this makes the generated preshaders very efficient. These preshaders only run when the constants they access have changed.

A shader instance will allocate only six live objects. These objects represent the vertex/pixel shader registers. (With an extra three live objects for a preshader)
All name-based operations are based on globally-unique integer ids. No strings are used at runtime.
  • The live object count is the number of objects allocated on the heap. This is critical for performance in large projects and especially on the Xbox.
    • The Effect system in XNA GS 2.0 has been known to create 100,000+ live objects in very large projects, the majority being strings.

Read about vertex and index buffers in xen

Home Current Release Documentation Screenshots

Last edited Apr 8, 2010 at 11:55 PM by StatusUnknown, version 25

Comments

Chessy Apr 19, 2010 at 6:06 PM 
Error 1 Assembly 'Xen.Graphics.ShaderSystem, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ea32b475b7afa3fa' uses 'Microsoft.Xna.Framework, Version=3.1.0.0, Culture=neutral, PublicKeyToken=6d5c3888ef60e27d' which has a higher version than referenced assembly 'Microsoft.Xna.Framework, Version=3.0.0.0, Culture=neutral, PublicKeyToken=6d5c3888ef60e27d' c:\Documents and Settings\Hassan\Desktop\Gloss Mapping\GlossMap\Starting_code\bin\x86\Debug\Xen.Graphics.ShaderSystem.dll Starting_code

How can i fix this problem?