8

Currently I have around 15 render passes in my pipeline. For every pass, I set the correct settings before drawing and reset them afterwards. Those settings include viewport size, depth test on or off, blending function or off, stencil function, stencil operation, and more.

I wonder whether OpenGL is clever enough to ignore API calls which set a state that is already present. Because otherwise I would keep track of the state with a lot of flags and before a render pass only set the state if it is actually necessary.

Improve this question
1
  • I've asked a bit 'similar' question regarding uniforms for GLSL: stackoverflow.com/questions/14724324/…. The answer was also "it depends on the driver" :) Commented Jun 17, 2013 at 10:39

3 Answers 3

Reset to default
8

The short answer: It depends on the driver.

OpenGL itself doesn't do much of anything. It is up to vendors to implement the functions specified by the standard any way they see fit. Do they usually test the existing state to avoid unnecessarily stalling the pipeline? Perhaps, but short of reading advice from vendors or measuring performance yourself, there is no way to know for sure.

The consensus of the advice I have seen (no reference for this as it is spread around all over the place), is that you should avoid calling OpenGL with redundant state changes. It can't do very much harm and it might do some good.

In your case (changing state a few times per frame between passes), it probably won't make much difference.

Improve this answer
Sign up to request clarification or add additional context in comments.

10 Comments

An even shorter answer is: No. By the time the driver pulls the command from its queue and thus has a chance to ignore duplicate calls, you have already made the API call. Also, querying state usually involves stalling the pipeline, which is much more expensive than setting it redundantly.
@Damon. The driver don't have to query the state, it could be cached in a variable easily. Also when we assume driver developers either implemented this tests or they don't make sense, then in both cases it doesn't make sense for me to implement it myself.
@danijar: There are only 2 state changes in graphics that really impair performance: Texture switches and shader switches. One usually sorts by textures and shaders before rendering, for that reason.
@datenwolf: Though note that this only accounts for the GPU stall part. As for the driver CPU overhead, almost every state change is possibly harmful, even only changing the base pointer of a vertex buffer (as the X-Plane author mentions on his blog, IIRC). @danijar: State could maybe be cached (at least some), but it isn't. Otherwise, glGet would be lightning fast, and it isn't. It's one of the slowest functions.
@Damon: hmm... do you think I should change "Probably" to "Probably not" (or "Perhaps" as a compromise :-)?
|
2

Because otherwise I would keep track of the state with a lot of flags and before a render pass only set the state if it is actually necessary.

Please note that this might or might be not faster than leaving it as-is. OpenGL is, as others said, only an API specification, leaving the implementation to GPU vendors (or Open Source communities such as Mesa). In general, you should expect every call to produce some result, but if your main concern is performance, the only way to really choose is profiling.

These results may vary from platform to platform or even the version of graphic driver, and sometimes such unsuspected things like running from battery power. Until you measure, you can't say what's a real performance problem in your application.

Improve this answer

Comments

-1

a lot of these seem to be flags, and it would likely be more expensive to set a flag than to test and set it. so the question would be whether OpenGL is dumb enough to do that rather than clever enough.

for the rest i doubt if the cost of computation, perhaps setting up the transformation matrix would be significant compared to the work of actual rendering, and accordingly not worth optimizing at the library level.

Improve this answer

1 Comment

Don't make such assumptions. On many cached memory architectures, unconditional writes must be copied all the way back, but a read/compare/conditional-write might avoid that expensive write-back.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.