Sign in to follow this  
Jiddoo

How fast is glIsEnabled ?

Recommended Posts

I wondered how efficient glIsEnabled is. E.g. if I want to render parts of my scene with the depth test disabled. What is more efficient, if I write:
bool depthTestIsEnabled = false;
if(glIsEnabled(GL_DEPTH_TEST)){
    glDisable(GL_DEPTH_TEST);
    depthTestIsEnabled = true;
}
render();
if(depthTestIsEnabled){
    glEnable(GL_DEPTH_TEST);
}
or is it more efficient to write
glDisable(GL_DEPTH_TEST);
render();
glEnable(GL_DEPTH_TEST);
Has anyone made some experiences with this?

Share this post


Link to post
Share on other sites
It is very easy to try this yourself. Shouldn't take more than a minute to actually try it. But if you are absolutely worried about the insignificant performance hit in most practical situations, you can track the state yourself to make sure you're not doing any redundant state changes nor querying states.

Share this post


Link to post
Share on other sites
glIsEnabled is probably as expensive as a virtual function call and a memory read, however you have no guarantee for that, as the implementation is free to do whatever it wants, in principle. Thus, a particularly stupid implementation could query the graphics card for that instead of returning a boolean.

glEnable/glDisable are state changes, and as such often provoke pipeline stalls. An implementation might still cache the state and coalesce redundant calls, but you have no guarantee that this will be done. Also, seemingly simple things like "turn on/turn off something" may require huge amounts of voodoo going on in a driver, as GPU functionality often does not correspond to the API, which may make state caching impossible in one case or another. The problem is, you never know. Plus, you never know what happens on a different computer with a different graphics card.
Therefore, changing state needlessly is always expensive, unless proven otherwise.

Share this post


Link to post
Share on other sites
Thanks for your replies. So I guess I either have to hand-tune my applications to prevent unnecessary state changes or write a state handler by myself. Sad. I hoped I could avoid this.

Share this post


Link to post
Share on other sites
The best option, and the one that is applied most frequently in production, is to simply use some mechanism that will sort your render graph by major state changes. A predicated tree, for instance, such that each level of the tree applies a predicate matching the next sorting parameter and deposits the elements into the appropriate sorted bucket for the next layers predicate. Then you simply have the leaf nodes be lists (pointer array, etc), and link the leafs in a linked list of sorts. State chances could then be applied by simply walking each leaf and changing states only when you move to the next leaf node. A example, listed by probably the best priorities, would be to sort in the following manner:

-Pixel shader changes.
-Pixel shader constant changes.
-Vertex shader changes.
-Vertex shader constant changes.
-Render target changes.
-Vertex format changes (SetVertexDeclaration).
-Sampler state changes.
-Vertex and index buffer changes (without changing the format).
-Texture changes.

Clearly this doesn't cover every possibilities, and there may be other things you might want to sort by (complex materials for instance, transparency, occlusion culling, z-ordering). The goal of this is to essentially batch up your state changes to minimize the total number of major states that have to change per frame.

I nabbed the list from here, while the FAQ is for DirectX, the underlying behavior between OpenGL and DirectX will be pretty much identical in many respects for the hardware, as such anything as abstract as this list will apply to both platforms equally in most cases.

Share this post


Link to post
Share on other sites
Thanks for the answer.

What'S the difference between "Sampler State Changes" und "Texture Changes"? Isn't a sampler a texture? At least it is in GLSL, not?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this