View Full Version : redundant state changes
I use such constructs for my state changes
this should increase the performance. What about changes of glPolygonMode(GL_FRONT_AND_BACK,GL_LINE)? Is it also useful to check the state?
06-21-2002, 02:56 AM
If you think you're changing it a lot redundantly then yes on some implementations. Ideally you'd want to avoid the redundant tests.
Do most state changes really cost that much(enough to make the overhead of checking before changing worth it)?I mean glColor() for example should only change the current color of the gl,that is change 2 to 4 values(besides casting and checking).Also glEnable(*) shouldn't have much more to do than change 1 value to true or something.Of course changes like glBindTexture() might take much longer due to possible uploading.Is there something I'm missing(I confess I don't know much about how a gl implementation actually works).
06-21-2002, 12:17 PM
A redundant glEnable could be fairly expensive in some cases. It may just set one bit for certain enables, but for others, it may require a whole lot of derived state to be recomputed. For example, enabling TEXTURE_2D redundantly every primitive would be a bad idea -- although if you were doing a BindTexture every primitive it might be almost free.
06-21-2002, 12:19 PM
Originally posted by zen:
Do most state changes really cost that much ... ?
I'm wondering too http://www.opengl.org/discussion_boards/ubb/wink.gif However, by minimizing state changes one is able to send more vertices in a burst (with VA/CVA/VAR/whatever).
>>although if you were doing a BindTexture every primitive it might be almost free.<<
vertainly not the case with older nvidia drivers are the new ones doing checking now, bah!
When I'm talking about redundant state changes like glEnable(GL_TEXTURE_2D) I'm talking about a few changes per frame.Like say I have a function to draw strings of mapped text.To do this I need to set the blending mode and enable blending and texturing for rendering each string.Now assuming I'll render a few strings(which is usually the case),like 10 console lines and maybe a couple of numbers(points,health,etc.).That's 45 changes per frame.Will doing checking to avoid these changes make any noticeable difference(for the better)?Of course if(for some reason) you change a couple of states for every tri you draw,well that can't be good.
06-22-2002, 01:54 PM
If you're talking 45 changes per frame, and are not looking into further flexibilizing your code to do more than just that, I'd say don't worry about it. That little of a number of state changes per frame is probably not worth the effort (unless you want to use it as an exercise in how to implement an efficient state engine http://www.opengl.org/discussion_boards/ubb/wink.gif).
Consider an engine though, that renders 500 meshes to the screen, with varying visual properties. For each mesh, state changes like texture enables, register combiner setups, texture environment setups, blending changes, etc. have to be made. It's easy to get into the 1000s of state changes that have to be made each frame, many of which can be fairly expensive (maybe even not expensive viewed as a single change, but consider hundreds of them being made redundantly), depending on the situation. In most of those cases, catching state changes is resulting in a noticeable performance increase.
It depends on what you want your app to do, how complex it's supposed to get, and, basically, how many state changes per frame you're going to encounter in a real-life case.
As I said in such a case it's obviously worth it.But if you put it this way,If your going to implement some state change tracking/avoiding mechanism,why not use it for this simple case as well.What abou glGet()s or similar calls to get the current state?Are they cheap/free?If that is the case ,1 get+1 compare per change shouldn't be much overhead so it should be a good idea to implement such a mechinsm in any case,provided that you can do it cleanly,that is without messing the code up too much.I'll look into it.
Powered by vBulletin® Version 4.2.3 Copyright © 2017 vBulletin Solutions, Inc. All rights reserved.