Jump to content
  • Advertisement
Sign in to follow this  
Red Ghost

OpenGL number of GL state changes

This topic is 3728 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

Hi, When learning OpenGL a while ago, I read that I should keep the number of OpenGL state changes low (less than 100 state changes - it was an optimum due to card technology of this period of time). The articles and books where I read this are now dated. I wanted to know If with recent cards, this optimum in number of state changes has increased. Thanks in advance. Red.

Share this post


Link to post
Share on other sites
Advertisement
As state changes costs, if only very little, the optimum number would be zero. But zero state changes are not possible for a non-trivial application, so you have to do a certain number of them. If you aim for N number of changes, but your application can do with only half of it, then you're wasting changes. If you require at least twice as many at minimum, then aiming for N would be wasting time also. That leads to the logical conclusion; do as little state changes as possible, as that approaches your optimum.

Share this post


Link to post
Share on other sites
There are expensive and non-expensive state changes, and it is batches that matter more than actual state changes. For example, setting 1 uniform and setting 100 uniforms is practically the same thing, even though one is a single state change, and the other is 100 of them. After the first one, it doesn't matter any more.

Among the more expensive state changes (likely to cause a stall) are changing shaders, textures, and uniforms. Note that changing shaders (and even uniforms, on some old drivers!) may, in addition, cause a shader to be recompiled.
On the other hand, things like for example changing a vertex attribute cost you next to nothing, you can do thousands of them (see pseudo instancing).

It is hard to tell exactly what will stall you and when, because modern GPUs can manage several sets of those states without stalling, but you don't know how many. So, in general, one should assume that they are very few (possibly only one) of those sets, so every significant state change should be considered a possible batch-breaker.

As for the number of batches going up, I'd rather expect the opposite. GPUs have been (and still are) increasing in power much faster than CPUs, so stalls are getting more painful. To get the maximum out of your card, the GPU has to be kept busy as much as possible.

Anyway, I'd not worry too much, because if you handle your state changes only with a little prudence, you're getting it 95% right, which should work ok.
It isn't possible to get it 100% right anyway (unless what you render is entirely uninteresting).

Share this post


Link to post
Share on other sites
@Brother Bob:
Err... I do not quite understand your answer. Are you telling me that it is the hardware that eventually forces down the optimum number of state changes ?

@samoth:
I am already batching my costly state changes (and use vertex arrays). I am now adding dot3 bump mapping feature and I get an increase of state changes. As it is a costly new effect (even after batching state changes), I wanted to know if I should limit the number of effects I get or if recent hardware now cope with a greater number of state changes.

Ghostly yours,
Red.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ghost
@Brother Bob:
Err... I do not quite understand your answer. Are you telling me that it is the hardware that eventually forces down the optimum number of state changes ?

If you have a scene that requires you to use 10 different shaders, then you NEED at least 10 shader changes. Saying that 5 would be optimum, you can spend an infinite amount of time trying trying to get to 5. You will require at least 10 shader changes, and so you will never reach the optimum.

By trying to minimize the number of changes, however, you will reach 10 shader changes, which would be the optimum in that case, since you cannot reduce the number any further.

So what I mean is that you should focus on minimizing them, not aiming for a specific number of changes.

Share this post


Link to post
Share on other sites
Quote:
Original post by Red Ghost
@Brother Bob:
Err... I do not quite understand your answer. Are you telling me that it is the hardware that eventually forces down the optimum number of state changes ?


He's telling you that since every state change has a cost, the "optimum" is zero state changes. And since you can't get away with that, "as few as possible" is as optimal as you're going to get.

There's nothing magical about, say, 100 state changes per frame. If they're all performed together, the cost will probably be more or less the same as for a single state change, and if they're performed one at a time, it'll cost 100 times as much as a single state change.

There's no reason why 100, 50, 500 or any other number should be "optimal".
As he said, the only truly optimal number is 0. And that's not really practical.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!