Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6605259
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 25, 20262026-05-25T19:15:45+00:00 2026-05-25T19:15:45+00:00

Its a fact that state changes in Opengl leads to performance degradation. //Say If

  • 0
   Its a fact that state changes in Opengl leads to performance degradation. 

//Say If i’m calling glEnable(GL_DEPTH_TEST) / glBlendFunc repeatedly in every frame.

EDIT: >Here I just mean to say ‘some state changes like this which state changes cause performance problems’

Can any one please explain the reason for this in detailed?

To my knowledge, The states can be maintained with in a register and can be used in traditional rendering GPU(Immediate mode kind) or can maintain a state
vector for each draw call in Tile based deferred Rendering. Is this really costly to maintain? (wonder why GPU’s are having still this problem 🙁 )

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-25T19:15:46+00:00Added an answer on May 25, 2026 at 7:15 pm

    Indeed state changes may be a performance killer. However the important question to ask is: “Which state”. Some state changes are so cheap, that is simply doesn’t make sense to keep track of them to minimize their use.

    On today’s OpenGL implementations glEnable/glDisable have virtually no performance penality (of course some states en-/disabled have large influence on the rendering performance in general).

    So what are expensive state changes? About everything that kills the caches’ contents, and the data in the cache is to be accessed at high bandwidth or requires high throughput.

    Textures are about the most expensive source of data to switch. So as a basic rule you sort your scene by use of textures, to switch textures as few as possible.

    Another expensive state change is switching shaders. Switching a shader affects the GPU in a negatively in two ways: First it forces the processing units into a full stop, flushing their execution pipeline. Refilling the pipeline until the thing works “like clockwork” takes a few hundred cycles. The other problem is, that different shaders have different execution and data access patterns. Execution patterns are determined by codepath prediction units to estimate which operations are about to be executed most likely. This also means knowing, which data to prefetch. Switching the shader trashes this vital information.

    States that are very cheap, but not for free is anything that can be described by a small set of numbers: Uniforms. Switching uniforms is extremely cheap, since it requires only very little overhead in the communication with the GPU and since Uniforms live in registers, changing them will effect neither cachelines nor execution prediction. And if you’re wondering about traditional, fixed function OpenGL: Transformation matrices, lighting parameters, clip planes are uniforms (just look into the OpenGL-2.1 GLSL spec, which built-in uniforms there are).

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

This snippet throws an NullPointerException due to the fact that its unboxed to a
Its a well known fact that a static method can work only on static
It's a known fact that Windows applications usually have 2Gb of private address space
Maybe it's just the fact that I've been using http://nodejs.org/ lately, but the lack
I have a problem with nodejs and connect and the fact that it's not
Trying to use autocomplete functionality of YUI, we ran into the fact that it's
Haskell is beautiful. That's a fact. It's concise, fast etc. Many of you will
It's a well known fact, that Oracle treats empty strings as null. However, I'm
This article states that Despite the fact that the Mersenne Twister is an extremely
Referring to a ~2-year old discussion of the fact that there is no operator

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.