Jump to content
  • Advertisement
Sign in to follow this  
O-san

glUseProgram

This topic is 3450 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've made a lighting shader system which uses one shader for each number of lights. Let's say I've got two lights then I would use: glUseProgram(two_lights_prg) ...and for one light i would use: glUseProgram(one_light_prg) I was wondering how costly it is to change shader programs often, lets say 40 times per frame? I have not noticed any significant drops on my GF 7800gt, but I just want to know what you think.

Share this post


Link to post
Share on other sites
Advertisement
You answered your own question. If you didn't notice any difference, the difference is not significant. Now, of course there is some cost for it, and you should try to minimize the number of times you change it. But there are no absolute numbers.

If you're change between the two 40 times per frame, what's stopping you from grouping the objects such that only one change per frame is necessary? If there is none, you're not aiming for minimum number of state changes and your state changes are wasting time. If you actually need to change 40 times per second, then the cost should be irrelevant, becuase you need it and there's nothing you can do about it. Then, of course, there's everything in between also. Other states may need to change also, so something between 40 and 1 may be optimal.

Either way, the question is very difficult to answer.

Share this post


Link to post
Share on other sites
My understanding is that fragment shader switches are the most expensive opengl state change operation, followed by vertex shader switches. I remember reading somewhere that you want to roughly keep below 8 changes per frame, but that was a few years ago.

Share this post


Link to post
Share on other sites
Thanks for the replies! I use different shaders because I found it to be faster than to use for loops and one shader.

I got another question. Does OpenGL update the built-in glsl variables gl_LightSource[n].position.xyz every frame? I am wondering due to this problem:

I got a per pixel emulation of OpenGL's fixed function lighting in my shader. Let's say I got four fixed function lights in one part of my scene. I set up the lights and their positions and all looks okay using either fixed function or shader functions. Then when I am finished drawing that part I go on and render another part of the scene that also got four lights. I set up the fixed function lights for this new scene part and everything looks okay but since my shader already has four lights I shouldn't need to call my four lights program again. However, here is the problem... the fixed function lighting on the second part of the scene looks okay but the shader version of the same part has not updated the light variables, it is all dark. My code looks like this (pseudo):

lastNrOfLights=currentNrOfLights;

currentNrOfLights=setLighting(x,y,z);

If(currentNrOfLights!=lastNrOfLights)
{
glUseProgram(mProgramObject);
}



Then if I remove the "If(currentNrOfLights!=lastNrOfLights)" the shader starts to work. Just like as if glUseProgram() needs to be called for the built-in light variables to be updated. Is there anyone who can shed some light on this?

Share this post


Link to post
Share on other sites
Quote:
Original post by jdindia
My understanding is that fragment shader switches are the most expensive opengl state change operation, followed by vertex shader switches. I remember reading somewhere that you want to roughly keep below 8 changes per frame, but that was a few years ago.


glUseProgram binds the vertex and fragment shader at the same time so ...

Also, I have done a lot more than 8 shader changes per frame even on an ancient Radeon 9500 and it is not a problem. Don't worry about it.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!