I want to set the initial data of a texture in an OpenGL 4.5 program (using OpenTK.Next and .NET), utilizing the new Direct State Access methods.

However, I cannot find a DSA version of glTexImage2D. There are methods like glTextureSubImage2D which accept a texture object ID, but using those to set the intial data fails with InvalidOperation.

I'm pretty sure there should be such a method... comparing textures to array buffers, array buffers do have a DSA version to set their initial data, glNamedBufferData.

According to the documentation, the DSA methods are all named ...Texture... unlike the "old" methods which are named ...Tex..., but searching through them didn't reveal me something like glTextureImage2D.

Anyone knows if there even is a DSA method to set the initial texture data?



There is none.

Issue 5 in the DSA specification reads (in part):

This extension omits TextureImageND (mutable texture definitions)...

Specifically, glTexImage/glTextureImage is the older "mutable textures" API which DSA omits, requiring you to use the immutable textures API instead. Therefore the non-DSA API is glTexStorage, whereas the DSA API is glTextureStorage.

Note that glTexStorage/glTextureStorage creates the texture object and it's backing storage but does not set the data; you must make a further call to glTexSubImage/glTextureSubImage in order to do that.

There are several advantages to using glTexStorage/glTextureStorage, and I refer you to the GL_ARB_texture_storage specification for a fuller discussion; for the purposes of this answer it's sufficient to quote the first paragraph of the overview:

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.

And issue 24 of the DSA specification confirms the reason why mutable textures were omitted:

24) Do we need DSA functions for mutable textures?

RESOLVED: No. Immutable texture is a more robust approach to handle textures

  • 1
    \$\begingroup\$ I didn't know about the history behind mutable textures. This makes things a lot more logical to me. Thanks for the details on the background about this! \$\endgroup\$
    – Ray
    Dec 10 '16 at 13:24
  • 1
    \$\begingroup\$ @RayKoopa - A pleasure. I believe it's always useful and interesting to know the reasons why certain API decisions were made; it can help you get a better understanding of how things work (in this case the fact that mutable textures were such a poor API demonstrates that hardware really prefers many things to be fully specified up-front). \$\endgroup\$ Dec 10 '16 at 13:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.