PresentationPDF Available

Automated Combination Of Real-Time Shader Programs

Authors:

Abstract

Presentation of Research Paper "Automated Combination Of Real-Time Shader Programs"
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 1
Automated Combination
Of Real-Time Shader Programs
Matthias Trapp :: Jürgen Döllner
+=
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 2
Outline
1. Motivation & Overview
2. Concept
3. Tagging Shader Source Code
4. Preprocessing Step
5. Shader Combination
6. Conclusions
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 3
1. Motivation & Overview
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
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 4
1. Motivation & Overview
Example Scenegraph
Texture
Normal
X-Ray
Shapes
Texture Shader
Color Map
Normal Shader
Normal Map
Root
Fog Shader
Phong Shader
X-Ray Shader
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 5
Next
1. Motivation & Overview
2. Concept
3. Tagging Shader Source Code
4. Preprocessing Step
5. Shader Combination
6. Conclusions
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 6
2. Concept - Overview
Straightforward modular principle:
Basically: Dynamic uber-shader construction
Exploits static branching to control execution paths
Main phases:
1. Decomposition shader into shader handler (next)
2. Preprocessing of shader handler to intermediate shader source
3. Combination of intermediate shaders to a single uber-shader
Shader ProgramA
Vertex ShaderA
Geometry ShaderA
Fragment ShaderA
Shader ProgramB
Vertex ShaderB
Geometry ShaderB
Fragment ShaderB
Shader ProgramC
Vertex ShaderC
Geometry ShaderC
Fragment ShaderC
=
+
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 7
2. Concept - Decomposition
Shader functionality is split into handler with predefined semantics
Shader handler can work on global context (interface)
Shader ProgramA
Vertex ShaderA
Geometry ShaderA
Fragment ShaderA
Vertex ShaderA
void main()
{
vec3 N, L;
vec4 D, A, GL;
float NdotL;
N = gl_NormalMatrix * gl_Normal;
L = vec3(gl_LightSource[0].position);
D = gl_FrontMaterial.diffuse *
gl_LightSource[0].diffuse;
A = gl_FrontMaterial.ambient *
gl_LightSource[0].ambient;
GL = gl_LightModel.ambient *
gl_FrontMaterial.ambient;
NdotL = max(dot(normalize(N),
normalize(L)), 0.0);
gl_FrontColor = NdotL * D + GL + A;
gl_Position = ftransform();
}
Vertex ShaderA
VertexShaderHandlerA1
VertexShaderHandlerA2
onLighting
onTransform
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 8
2. Concept - Combination
Vertex ShaderA
VertexShaderHandlerA1
VertexShaderHandlerA2
Vertex ShaderC
Vertex ShaderA
VertexShaderHandlerA1
VertexShaderHandlerA2
Vertex ShaderB
VertexShaderHandlerB1
VertexShaderHandlerB2
VertexShaderHandlerB3
VertexHandler Controller
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 9
2. Concept Decompostion Details
Shader: is an ordered 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
Must be declared by developer in advance
Differ for each shader type (vertex, fragment, …)
onAnimation
onLighting
onTransform
onLighting
onTransform
onAnimation
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 10
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
struct us_VertContext
{
vec4 us_Position;
vec3 us_Normal;
float us_PointSize;
vec4 us_ClipVertex;
} vertContext;
Vertex Handler Interface
struct us_FragContext
{
vec4 us_FragColor;
vec3 us_FragNormal;
vec3 us_FragView;
vec3 us_FragLight;
gl_MaterialParameters us_FrontMaterial;
float us_FragDepth;
} fragContext;
Fragment Handler Interface
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 11
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
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 12
2. Concept Execution Modes
Example Scenegraph
Texture
Normal
X-Ray
Shapes
Texture Shader
Color Map
Normal Shader
Normal Map
Root
Fog Shader
Phong Shader
X-Ray Shader
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 13
Next
1. Motivation & Overview
2. Concept
3. Tagging Shader Source Code
4. Preprocessing Step
5. Shader Combination
6. Conclusions
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 14
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;
}
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 15
Next
1. Motivation & Overview
2. Concept
3. Tagging Shader Source Code
4. Preprocessing Step
5. Shader Combination
6. Conclusions
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 16
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
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 17
Next
1. Motivation & Overview
2. Concept
3. Tagging Shader Source Code
4. Preprocessing Step
5. Shader Combination
6. Conclusions
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 18
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 handlers 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)
SH1SH5SH0SH6
SH3SH7SH2SH8SH4
UberShader
PH0PH1PH2PH3PH4
Prototype Handler Table
SH1
SH0SH2
Shader Handler
Program 0
SH3SH4SH5
Program 1
SH6SH7
Program 3
SH8
...
Sort
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 19
6. Conclusion
Summary
Combination of shader programs
Generic uber-shader construction
Control parameter for execution logic
Drawbacks
No automatic shader decomposition
Future Work
Resource management for shader state
Optimize generated programs for fixed execution paths
Enable the usage of LoD shader handler
:: Matthias Trapp :: Jürgen Döllner :: Automated Combination Of Real-Time Shader Programs :: 20
Thank You.
matthias.trapp@hpi.uni-potsdam.de
juergen.doellner@hpi.uni-potsdam.de
:: www.hpi.uni-potsdam.de ::
Article
Using programmable graphics hardware in or-der to solve both computer graphics and non-graphics tasks has become commonplace in recent years. High level shading languages have greatly simplified the effort of writing programs for graphics processors, and dedi-cated programming interfaces proposed recently by ma-jor hardware vendors abstract from computer graphics details. However, algorithms that strive for solving real-life problems while maintaining direct visualization capa-bilities are rather complex and require much more than individual shader components. In this work, we propose a framework for efficiently integrating programming resources of both GPU and host applications. We therefore introduce a hierarchical approach to structure GPU and CPU program compo-nents with additional data-driven control. Transparently shared parameters and computation results enable flexi-ble communication between different computation steps, no matter if the computation is performed on the host or the graphics hardware. We illustrate a set of classes fa-cilitating the proposed functionality, while retaining the full design and programming capabilities from object-oriented programming languages. These approaches are supplemented by techniques available in shader program-ming languages to provide even more flexibility. In order to demonstrate the potential of the approach, we present a reasonable scenario and discuss the framework's per-formance in terms of programming efforts and run time overhead.
ResearchGate has not been able to resolve any references for this publication.