Automated CombinationOf Real-Time Shader Programs: Automated Combination Of Real-Time Shader Programs Matthias Trapp :: Jürgen Döllner


Outline: Outline 1. Motivation 2. Concept 3. Tagging Shader Source Code 4. Preprocessing Step 5. Shader Combination 6. Conclusions


1. Motivation: 1. Motivation Problem: Fixed-function pipeline is obsolete Functionality is provided by shader programs Combine functionality  combine programs Goals: Minimize shader permutations Dynamic configuration of combined programs Keep functionality of individual shaders Enable nesting of shader programs Applications Shader-driven rendering engines Emulate orthogonal fixed function pipeline features Dynamic material systems


1. Motivation: 1. Motivation Example Scenegraph


2. Concept - Overview: 2. Concept - Overview Modular principle for each shader type: Basically: Dynamic uber-shader construction Exploits static branching to control execution paths Main phases: Decomposition shader into shader handler (next) Preprocessing of shader handler to intermediate shader source Combination of intermediate shaders to a single uber-shader = +


2. Concept - Decomposition: 2. Concept - Decomposition Shader functionality is split into handler with predefined semantics


2. Concept - Combination: 2. Concept - Combination


2. Concept – Decompostion Details: 2. Concept – Decompostion Details Shader: set of shader handler (SH) Prototype (P) Represents an atomic functionality Assigned to a shader handler: P = prototype(SH) Prototype List (PL) Defines explicit order upon prototypes Important for handler combination P & PL Defined by developer in advance Differs for each shader type (vertex, fragment, …)


3. Tagging Shader Source Code: 3. Tagging Shader Source Code Extend shading language grammar (here GLSL) Shader Handler Example: handler [local|global|optional|explicite|ignore] hName (interface iName) handler local onLighting(interface context) { vec3 fragNormal = normalize(context.us_FragNormal); vec3 fragView = normalize(context.us_FragView); vec3 fragLight = normalize(context.us_FragLight); vec3 reflection = normalize(reflect(-phongLight, phongNormal)); float NdotL = max(0.0, dot(fragNormal, fragLight)); float VdotR = dot(fragView, reflection); float VdotRExp = pow(max(0.0, VdotR), context.us_FrontMaterial.shininess); context.us_FragColor = context.us_FrontMaterial.ambient * (gl_LightSource[0].ambient + gl_LightModel.ambient) + NdotL * gl_LightSource[0].diffuse * context.us_FrontMaterial.diffuse + VdotRExp * context.us_FrontMaterial.specular * gl_LightSource[0].specular; return; }


4. Preprocessing Step: 4. Preprocessing Step Transforms tagged source into: Intermediate source code (language specific) Mapping: Shader Handler  Prototype Basically via token substitution: Insert specific interface source code Result is ready for API shading language front-end compiler


5. Shader Combination: 5. Shader Combination During Pre-traversal by Shader Management System (SMS) Create priority program list (PPL) Create controller for each shader type: Generated controller configured by an invoker table Array of Boolean variables represents activity-state of handler Passed to the controller as uniform shader state During evaluation of a shader program: Activate/deactivate shader handler by modify invoker tables With respect to the handler execution modes foreach prototype P  PL do foreach shader program SP  PPL do foreach shader handler SH  SP do if (prototype(SH) = P) do appendIfStatement(SH)


6. Conclusion: 6. Conclusion Summary Combination of shader programs Generic uber-shader construction Parameters to control execution logic Drawbacks No automatic shader decomposition Future Work Resource management for shader state Enable the usage of LoD shader handler Integration into FX formats (CG, Collada,…)


Slide13: Thank You. matthias.trapp@hpi.uni-potsdam.de juergen.doellner@hpi.uni-potsdam.de :: www.vrs3d.org :: www.hpi.uni-potsdam.de ::


Slide14: Thank You. matthias.trapp@hpi.uni-potsdam.de juergen.doellner@hpi.uni-potsdam.de :: www.vrs3d.org :: www.hpi.uni-potsdam.de ::


2. Concept – Interfaces: 2. Concept – Interfaces Properties Shared state between shader handler Depend on shader type Must be defined in advance Deposited as source code in specific shading language GLSL Examples


2. Concept – Execution Modes: 2. Concept – Execution Modes Control shader handler execution Propagate active state of program  Activate handler according to execution modes Can be configured at runtime for each handler Handler execution modes: Local: handler is invoked only if the program object is active Global: handler will always be invoked Optional: invoke handler if no handler of resp. prototype is active Explicit: all other handler of this prototype will be disabled Ignore: handler will never be invoked


2. Concept – Execution Modes: 2. Concept – Execution Modes Example Scenegraph