if I just have the GLuint from a texture object, I can check whether it is in fact a texture (glIsTexture()) but I can’t check what target it has, right? I can try to bind it to GL_TEXTURE_2D, GL_TEXTURE_3D etc… and test which call generated errors and which succeeded. Bound to the right target I can query all kinds of parameters (glGetTexParameter*).
So my question is, have I overlooked a function that can tell me the kind of texture / the target if all I have is a GLuint from which I only know that it is a texture (result from glIsTexture) ?
I don’t think there is one - oddly enough - but should be trivial to implement. I guess you’ll have to store the info on the application level.
This is a hole due to the nature of the API. Remember: DSA doesn’t exist. So if you have a texture object, the only way you could ever use it to even query something from it would be to bind it to the context. And glBindTexture will fail if you bind it to the wrong target. So clearly, if you bound it, you must know what target you used. Especially since glGetTexParameter takes the target as a parameter…
Of course, that in itself tells you one way to do it: try to bind it to every target and see what works and what doesn’t.
Could be a valid addition to the API though.
Not that I would use it, but since the GL in some way has to keep track of the target as soon as you first bind the texture object, a glGetTextureTarget(GLuint) which returns either the target or preferably 0 (i.e. GL_NONE) if not bound yet (or generated an error) could be implemented rather easily, I suspect. Being able to query if a name refers to a texture and not being able to query the target if already bound is simply inconsistent.
I don’t quite get how DSA helps here since for any DSA style texture functions (at least from what I remember from GL_EXT_direct_state_access) you need to provide the target as well. Did I miss something?
Storing the target in the application is what I do in my apps (I wouldn’t query it each time I want to bind a texture even if that would be possible…).
Trying to bind it to each target and see what fails and what works is what I do now in a special use case where I can’t store the target (more of a debugging use case). I hoped I would just have missed a way to do it more elegantly.
What is the best way to suggest something like glGetTextureTarget(GLuint)? This forum or the Khronos Bugzilla? Some other way?
I would suggest the appropriate sub-forum but I don’t think there is much evidence for anything in there having an actual effect. It would be nice to know in general if anyone relevant to any significant implementation listens to us here in the forum.
On the the other hand, there are active fellow board members here which have actively contributed to extensions, namely Groovounet and aqnuep, both for AMD. Maybe those guys have anything to say on this which could give us some insight as to why such a function doesn’t exist in the first place.
I can’t speak to the Khronos bug tracker and if feature requests are possible and actually evaluated. IIRC, Alfonse has commented on Khronos’ bug tracking/fixing behavior in the past, but I might be wrong.
I don’t quite get how DSA helps here since for any DSA style texture functions (at least from what I remember from GL_EXT_direct_state_access) you need to provide the target as well.
Yes, but that doesn’t mean they have to.
glBindImageTexture doesn’t need it. Neither does glTextureView (for the source texture). Indeed, there’s really no reason why most of the DSA functions have that parameter, save for the fact that it’s theoretically possible that you could call glTextureParameter before calling glTextureImage*.
I would much rather they have a glTextureType function, which sets the texture’s type. Attempting to use any DSA function when a texture’s type hasn’t been set results in an error.
For images I agree. For tex views, however, you’d still need to know the source textures type in order to select a compatible format for the view - if you can’t store the information, as in menzel’s case, you’re doomed to walk the path of trial and error again.
Was this suggestion purely in regards to throwing the target out of DSA APIs? If so, I completely agree. Otherwise, this doesn’t solve the original problem of not being able to determine the target of a texture if you cannot store the information when creating the texture object in the first place.
Another approach would be to have the target set immediately at generation time with an alternative
glGenTypedTextures(GLsizei, GLuint*, GLenum target)
or similar, which directly associates returned names with the specified target. It’s basically a factory. Generating unbound names as with glGenTextures() is a well and good, but really, most of the time I assume we generate and shortly afterwards bind to a specific target anyway so this whole “a texture is without a type until bound” thing doesn’t need to be the only way.
For tex views, however, you’d still need to know the source textures type in order to select a compatible format for the view - if you can’t store the information, as in menzel’s case, you’re doomed to walk the path of trial and error again.
You’re misunderstanding my point. I mean that the API doesn’t need to be told what the texture type is. You can therefore use the API without knowing the type.
Yes, if you use the wrong type, you get problems. But that’s true of anything. Unless you’re writing what is essentially a naked wrapper around OpenGL, you probably know what a given texture object is supposed to represent. And that means that you know it’s type.
The point is that you don’t have to carry around an OpenGL enum or equivalent information; if all of your textures are 2D or 2D array textures… you don’t need to advertise that everywhere. Or maybe you wrap the OpenGL API inside something and know in some other way that’s not an enum what the texture’s type is.
You only need a GL enum because the OpenGL API says so.