Back to For Beginners

How fast is glIsEnabled ?

For Beginners

Started by Jiddoo May 29, 2009 02:58 AM

3 comments, last by Jiddoo 14 years, 10 months ago

Jiddoo

122

Author

May 29, 2009 02:58 AM

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?

Brother Bob

10,350

May 29, 2009 03:59 AM

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.

samoth

9,833

May 29, 2009 05:29 AM

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.

Jiddoo

122

Author

June 02, 2009 02:58 AM

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.

Washu

7,836

June 02, 2009 03:56 AM

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.

In time the project grows, the ignorance of its devs it shows, with many a convoluted function, it plunges into deep compunction, the price of failure is high, Washu's mirth is nigh.

Jiddoo

122

Author

June 03, 2009 09:18 AM

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?

How fast is glIsEnabled ?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

How fast is glIsEnabled ?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines