Sorry if this question has been asked before - I've searched Google on a number of occasions and can never get the answer I need.
Whenever an OpenGL object handle is created, i.e. glGenTextures(...), glGenBuffers(...), etc. is it possible for these functions to share a handle namespace, or do they have their own separate namespaces (one for textures, one for buffers, ...)?
Put simply, is it possible for a handle to represent two different objects such that 'IsTexture(handle)' and 'IsBuffer(handle)' would return true?
Many thanks,
OpenGL Handles
In OpenGL, the "handles" are just unsigned integer numbers. This means that there is no type based distinctions between names (as the "handles" are called correctly in OpenGL) for e.g. textures and names for e.g. VBOs. So it is principally possible to pass a name allocated for a VBO to glIsTexture, as an example.
Moreover, the values returned by OpenGL resource allocators are usually small numbers, increased by a small amount compared to former allocations. Strictly speaking, a value need to be unique only in the specific context of use as a texture, VBO, or whatever. Hence it is not exclusionary that a call to e.g. glGenTextures returns the same value as a call to e.g. glGenBuffers.
At the end I would say that it is implementation specific (I haven't found something concrete in the specs). As a conclusion I'd say that it is possible that a name of a texture can be passed to any glIsXyz and return with a "true". However, this doesn't mean that the named object is actually of the Xyz type. Passing a texture name as VBO name is simply a programming error not detectable by OpenGL.
Moreover, the values returned by OpenGL resource allocators are usually small numbers, increased by a small amount compared to former allocations. Strictly speaking, a value need to be unique only in the specific context of use as a texture, VBO, or whatever. Hence it is not exclusionary that a call to e.g. glGenTextures returns the same value as a call to e.g. glGenBuffers.
At the end I would say that it is implementation specific (I haven't found something concrete in the specs). As a conclusion I'd say that it is possible that a name of a texture can be passed to any glIsXyz and return with a "true". However, this doesn't mean that the named object is actually of the Xyz type. Passing a texture name as VBO name is simply a programming error not detectable by OpenGL.
I did not find an explicit statement in the specification, but the wording strongly suggests that name spaces for different objects are not shared. Thus, the same actual value can be used for objects of different types. The only exception is that shader and program objects share name space, but other objects are separate name spaces.
Testing with glGenTextures and glGenBuffers shows that they both give 1 on first call for me, so glIsTexture (1) and glIsBuffer(1) would both return GL_TRUE.
I did not find an explicit statement in the specification, but the wording strongly suggests that name spaces for different objects are not shared.
Handles can be used without actually acquiring one via the glGen* calls (legacy of stupidity as i call it) - so, that kind of answers that question (*).
*) While this unfathomable nonsense was removed in the new core specifications (non-backwards compatible) - driver providers still need to support it.
[quote name='Brother Bob' timestamp='1337335089' post='4941143']
I did not find an explicit statement in the specification, but the wording strongly suggests that name spaces for different objects are not shared.
Handles can be used without actually acquiring one via the glGen* calls (legacy of stupidity as i call it) - so, that kind of answers that question (*).
*) While this unfathomable nonsense was removed in the new core specifications (non-backwards compatible) - driver providers still need to support it.
[/quote]
Whether or not you can make up your own handles does not, by itself, say anything whether the handle values can be the same for different object types or not. Furthermore, user created handles is only supported by the legacy API. In the new API, handles must be allocated by the glGen-functions. Custom handles are not allowed there.
Whether or not you can make up your own handles does not, by itself, say anything whether the handle values can be the same for different object types or not.
Erm, wut? ... it kind of does. As one is allowed to use whatever values (except zero) then one can, for example, choose 1 for every object type => which was the very thing being questioned.
Furthermore, user created handles is only supported by the legacy API. In the new API, handles must be allocated by the glGen-functions. Custom handles are not allowed there.
Which is what i said.
Worth to note tho: as not implementing the legacy API is not really an option for anyone for quite a long time (NVIDIA keeps repeating that they will never drop it) then there are good chances they wont do anything crazy there even with the new API (have not encountered any exceptions and as GPU needs the freedom to move stuff around - per object type indexing is the most performant/sane option i can think of, especially as they need to implement a fairly similar legacy code-path anyway).
So, yes, technically something crazy could go on with new API, but OP did not specify his target => lowest common denominator is the answer.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
