Jump to content

  • Log In with Google      Sign In   
  • Create Account

OpenGL Handles


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 Wavarian   Members   -  Reputation: 720

Like
0Likes
Like

Posted 18 May 2012 - 12:25 AM

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,

Sponsor:

#2 haegarr   Crossbones+   -  Reputation: 4313

Like
2Likes
Like

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.

Edited by haegarr, 18 May 2012 - 01:32 AM.


#3 Brother Bob   Moderators   -  Reputation: 8201

Like
2Likes
Like

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 mhagain   Crossbones+   -  Reputation: 7979

Like
1Likes
Like

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.


#5 Wavarian   Members   -  Reputation: 720

Like
0Likes
Like

Posted 18 May 2012 - 05:41 AM

Excellent, thanks guys!

#6 tanzanite7   Members   -  Reputation: 1296

Like
0Likes
Like

Posted 19 May 2012 - 02:15 PM

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.

#7 Brother Bob   Moderators   -  Reputation: 8201

Like
0Likes
Like

Posted 19 May 2012 - 02:48 PM


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.

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.

#8 tanzanite7   Members   -  Reputation: 1296

Like
0Likes
Like

Posted 20 May 2012 - 05:56 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.

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS