Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: High number of shader program switches?

  1. #1
    Newbie Newbie
    Join Date
    Feb 2013
    Posts
    2

    High number of shader program switches?

    Hey guys!

    So as this is my first post, I would like to say hello to everybody ...

    ... and dive directly into my question.
    After playing around for a while with OpenGL, I finally managed to setup my own little graphics engine. Until now everything runs well. But - texturering is the next big thing to come.
    I really don't like the engine to have plain images as textures so I am really going into all the special material stuff (or at least I plan to do so ;-) ).

    So I am really concerned about how to organize this stuff. How do you guys handle huge shaders (as they sure will be)? Is it better to develop shader's that get some state-variables (for example b_MaterialHasSpecularMap = true) and compute all the stuff depending on these variables or is it no problem if I have shaders for every single material type?
    I don't worry much about the code but as the title says, I am not sure about GL's beheaviour on an increasing number of shaderprogramm switches.

    Any hint on this topic anyone?
    I would appreciate any help!

    thanks!
    Ivan

  2. #2
    Senior Member OpenGL Guru Dark Photon's Avatar
    Join Date
    Oct 2004
    Location
    Druidia
    Posts
    3,209
    Quote Originally Posted by insane_ivan View Post
    How do you guys handle huge shaders (as they sure will be)? Is it better to develop shader's that get some state-variables (for example b_MaterialHasSpecularMap = true) and compute all the stuff depending on these variables or is it no problem if I have shaders for every single material type?
    You have lots of choices, and what works best for someone else might not work best for your application, but...

    I personally like the ubershader method alot for handling shader permutations. In particular, see:

    * link1, link2

    This works well for managing shader permutations where the shader code switches based on a boolean or enumerated value, particularly when the inputs provided to different shader permutations change (think light model, color material, texenv, etc.). Depends on your needs, but you'll probably still want to sort your batches by shader permutation for max perf.

    All that said, branches in shaders nowadays are fairly cheap "if" you don't have divergence between neighboring pixels (e.g. the branch chosen is constant within every batch). So you could do that. Though you'll probably still want different shaders if your permutations cause the shader to take different inputs.

  3. #3
    Newbie Newbie
    Join Date
    Feb 2013
    Posts
    2
    Thanks for all the information and your help!
    Guess I will go for the "ubershader"-method

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •