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,
0
OpenGL Handles
Started by Wavarian, May 18 2012 12:25 AM
7 replies to this topic
Ad:
#2 Members - Reputation: 1771
Posted 18 May 2012 - 01:30 AM
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.
Edited by haegarr, 18 May 2012 - 01:32 AM.
#3 Moderators - Reputation: 4633
Posted 18 May 2012 - 03:58 AM
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.
#4 Members - Reputation: 3789
Posted 18 May 2012 - 04:35 AM
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.
It appears that the gentleman thought C++ was extremely difficult and he was overjoyed that the machine was absorbing it; he understood that good C++ is difficult but the best C++ is well-nigh unintelligible.
#6 Members - Reputation: 593
Posted 19 May 2012 - 02:15 PM
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 (*).I did not find an explicit statement in the specification, but the wording strongly suggests that name spaces for different objects are not shared.
*) While this unfathomable nonsense was removed in the new core specifications (non-backwards compatible) - driver providers still need to support it.
#7 Moderators - Reputation: 4633
Posted 19 May 2012 - 02:48 PM
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.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 (*).
I did not find an explicit statement in the specification, but the wording strongly suggests that name spaces for different objects are not shared.
*) While this unfathomable nonsense was removed in the new core specifications (non-backwards compatible) - driver providers still need to support it.
#8 Members - Reputation: 593
Posted 20 May 2012 - 05:56 PM
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.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.
Which is what i said.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.
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.
