Direct State Access

[xahir]

From EXT_direct_state_access (For TextureImageEXT etc.):

If the texture parameter is for an unused name, the name becomes used and the named texture object is set to a new state vector, comprising all the state values listed in...

So, even if the given texture handle(or name), is not generated by GenTextures function it is recognized as a texture!? Or, may be I am getting confused.

If the texture parameter is for a used name and that named texture object has a different target than the specified target parameter, the INVALID_OPERATION error is generated

If given handle's referred texture will not be updated according to the given target, why would I be forced to remember the target of the texture all the time? I mean instead of a single uint, I need to hold on to an integer target property too.

Oh, answer is a bit lines above:

If the texture parameter is zero, then the target parameter selects the default texture of the specified target to update

Hmm, so target is useful if I select zero handle. Ok, good for proxy textures. But using target as proxy texture but using handle other than zero also generates an error too.

Well, I'd go for two different sets of commands where, one set taking only handle for my textures and other set for default texture with only target parameter. Then what would be the target of my textures?

myTextureHandle = glCreateTexture(target, internalFormat, size, ...);

Just a create object scheme not so different from shader creation, plus getting texture_storage player into the game. nothing else.

[kyle_]

From EXT_direct_state_access (For TextureImageEXT etc.):

So, even if the given texture handle(or name), is not generated by GenTextures function it is recognized as a texture!? Or, may be I am getting confused.

Your confusion arises from the fact that the extension is written against GL2.1 spec, where this was true. It continues to be true for some object types in compatibility profiles in newer GL versions. In core profile you always have to Gen all your objects.

If given handle's referred texture will not be updated according to the given target, why would I be forced to remember the target of the texture all the time? I mean instead of a single uint, I need to hold on to an integer target property too.

Oh, answer is a bit lines above:

Hmm, so target is useful if I select zero handle. Ok, good for proxy textures. But using target as proxy texture but using handle other than zero also generates an error too.

Well, I'd go for two different sets of commands where, one set taking only handle for my textures and other set for default texture with only target parameter. Then what would be the target of my textures?

Rewrite from scratch would probably avoid targets, as they are useless in most cases other then broken cube map uploads, which could be avoided in such case. Texture proxies aren't particularly good reason for api complication, as they are pretty much useless.

Just a create object scheme not so different from shader creation, plus getting texture_storage player into the game. nothing else.

A spark of brilliance, that was shyly followed with sync objects, but abandoned ever since. 'Gen' stuff is silly, really. I have never seen an actual application that would gen names en-masse (which was probably perceived perf. benefit by api designers). Probably there was much to be gained there in times of SGI (though i find it hard to believe). Right now its just a relic of the past kept in the api for compatibility reasons (there are a couple of things like that in GL).

To recap, you need to take history into account when trying to make sense of GL API. Otherwise you may be seriously surprised here and there.

[xahir]

...that was shyly followed with sync objects...

What i actually wanted to mean was shader objects, like you give the type and create it. And use that object when you need it via attaching to program etc. Sync objects are a bit weird actually. You use it at the same time of the creation. It is a bit awkward tho. According to ApendixD of spec. sync objects are cross-context share-able, but if you want to wait on a sync object, you should actually have inserted it into the pipeline. Before ARB version (dont remember actually it was either APPLE or NV) it was like you were creating the object then insertion/waiting was taking place. In current way of fences second thread should also wait on the creation to be more precise. May be i am still confused here

Anyways, back to DSA, when I see matrix modes etc. i was a bit "hmm" on the weirdness but being written against 2.1 makes a lot of sense now But to be honest as DSA being an object creation/referencing scheme instead of the older state machine paradigm; it is highly appreciated by the OOP users or DX migraters. In that sense this extension is much more useful for core-profile users other than compatibility users in the sense that they have a very large codebase depending on old features and not gonna change in the near future. If they are not willing to change why not to serve such beauty to core profile instead I believe is long-time users/supporters of OpenGL will migrate to core profile when they are in need of change

[kyle_]

What i actually wanted to mean was shader objects, like you give the type and create it.

Well, i didnt mean all the usage stuff of sync. Just that its creation model is optimal, and what should have been done with rest of objects (and probably would if it was possible by now), namely - create _single_ object and return a _pointer_ to it. The 'names' stuff is pretty pointless.