Automated Combination of Real Time Shader Programs (EG 2007)

  • 769 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
769
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Automated Combination Of Real-Time Shader Programs Matthias Trapp :: Jürgen Döllner + =
  • 2. Outline
    • 1. Motivation
    • 2. Concept
    • 3. Tagging Shader Source Code
    • 4. Preprocessing Step
    • 5. Shader Combination
    • 6. Conclusions
  • 3. 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
  • 4. 1. Motivation
    • Example Scenegraph
  • 5. 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
    = +
  • 6. 2. Concept - Decomposition
    • Shader functionality is split into handler with predefined semantics
  • 7. 2. Concept - Combination
  • 8. 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, …)
  • 9. 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_Frag Normal ); vec3 fragView = normalize ( context.us_Frag View ); vec3 fragLight = normalize ( context.us_Frag Light ); 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 ; }
  • 10. 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
  • 11. 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)
  • 12. 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,…)
  • 13. Thank You. [email_address] [email_address] :: www.vrs3d.org :: www.hpi.uni-potsdam.de ::
  • 14. Thank You. [email_address] [email_address] :: www.vrs3d.org :: www.hpi.uni-potsdam.de ::
  • 15. 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
  • 16. 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
  • 17. 2. Concept – Execution Modes
    • Example Scenegraph