What does immutable texture mean?

Question

ARB_texture_storage was introduced into OpenGL 4.2 core.

Can you explain what immutability for texture objects means?

Why it is better from the previous texture usage and what are disadvantages of this feature?

I know I can read the spec of this extension (which I did :)), but I would like to see some examples or other explanation.

Corsiglia

"what are disadvantages of this feature?" The fact that it wasn't in OpenGL 1.1. – Lewert

possible duplicate of What does glTexStorage do? – Lewert

It basically fix design flaws in OpenGL. Apart very few really interesting features, most of modern OpenGL is about API change rather than providing new functionality. the fact is that now we have a precise Idea of GPU capabilities (still space for new stuff eh XD) and we need better and more consistent APIs to provide cababilities to users. – Shedd

Answer 1

Just read the introduction from the extension itself:

The texture image specification commands in OpenGL allow each level
to be separately specified with different sizes, formats, types and
so on, and only imposes consistency checks at draw time. This adds
overhead for implementations.

This extension provides a mechanism for specifying the entire
structure of a texture in a single call, allowing certain
consistency checks and memory allocations to be done up front. Once
specified, the format and dimensions of the image array become
immutable, to simplify completeness checks in the implementation.

When using this extension, it is no longer possible to supply texture
data using TexImage*. Instead, data can be uploaded using TexSubImage*,
or produced by other means (such as render-to-texture, mipmap generation,
or rendering to a sibling EGLImage).

This extension has complicated interactions with other extensions.
The goal of most of these interactions is to ensure that a texture
is always mipmap complete (and cube complete for cubemap textures).

The obvious advantages are that the implementation can remove completeness / consistency checks at runtime, and your code is more robust because you can't accidentally create a wrong texture.

---

To elaborate: "immutable" here means that the texture storage (one of the three components of a texture: storage, sampling, parameters) gets allocated once and it's already complete. Note that storage doesn't mean the storage contents -- they can change at any time; it refers to the logical process of acquiring resources for those contents (like, a malloc).

With non-immutable textures, you can change the storage at any time, by means of glTexImage<N>D calls. There are many many ways of shooting yourself in the foot this way:

• you may create mipmap-incomplete textures (probably the most common newbie error with textures, as textures by default have 1000 mipmap levels, and people upload only one image)
• you may create textures with different formats in different mipmap levels (illegal)
• you may create cubemap-incomplete cubemaps (illegal)
• you may create cubemaps with different formats in different faces (illegal)

Since you're allowed to call glTexImage<N>D at any time, the implementation must always check, at draw time, that your texture is legal. Immutable storage always does the right thing for you by allocating everything in one go (all mipmap levels, all cubemap faces, etc.) with the right format. So you can't screw up a texture (easily) any more, and the implementation can remove some checks, which speeds things up. And everybody is happy :)

Josey

thank for the aswer. I see that in general this extension reduced complexity and should improve speed. When you have a simple texture loaded from a disk you should use TexStorage2D to do all the work up-front. – Corsiglia

@Corsiglia "When you have a simple texture loaded from a disk" - No, that should read "When you have any texture". – Counterclaim