VAO with DSA about globjects HOT 6 OPEN

Hello,
the problem seems to be that the call of
globjects::VertexArray::create()
ends in glGenVertexArrays instead of glCreateVertexArrays.

I've already set globjects's VertexArray to use the DirectStateAccess extensions.
How do you configure glbindings or globjects or both to invoke glCreateVertexArrays instead of glGenVertexArrays ?

kind regards.

from globjects.

It seems, that VertexArray::create ignores the DSA settings
VertexArrayObjectResource::VertexArrayObjectResource() : IDResource(createObject(glGenVertexArrays)) { }

kind regards,

Edit: seems to be a problem with the nvidia driver, but a dsa implementation would be nice.

from globjects.

Sorry, next post.
I had a look at the specifications to direct_state_access_arb and direct_state_access_ext.

Core DSA and EXT_DSA take different approaches to resolving this problem. In EXT_DSA, all of the DSA-style functions are permitted to take an object name that had no state data associated with it (ie: had not yet been bound). These functions were therefore required to be able to generate the default state behind those names, then perform whatever processing the function normally did.Core DSA does not do this. If you pass a new object to any of the core DSA functions, they will fail with GL_INVALID_OPERATION. Instead, the object's state must be initialized. This can be done via glBind* functions (which goes against the point of the functionality), but the preferred method is to use the glCreate* set of functions. These create object names and fill them with their initial state. Those object types which have a target that defines the type of that object (Textures and Query Objects) have this type specified by their glCreate* function.
https://www.khronos.org/opengl/wiki/Direct_State_Access

Guess this brings it to the point. Wonder if AMD/ATI drivers accept a mixture of glGenVertexArrays followed by DSA functions related to the vertex array object.

kind regards.

from globjects.

Thanks for the in-depth analysis. I can confirm that for DSA, the glCreate* functions should get used and that within globjects, this implementation path is missing.
Problably we have to add implementation strategies for Vertex Arrays as well. And while we're at it, check other directly created objects within Resource.cpp as well.

from globjects.

Hello,
thank you for your comment. I'm a big fan of this library.
I've implemented a strategy for the vertex arrays so far for testing. But you should consider to synchronize vao settings with the vao binding strategy. what i mean is, if you set the VAO strategy to use DSA implementations then the DSA strategy for vao bindings should be set automatically under the hood.

The VertexArray now has
static void hintAttributeImplementation(AttributeImplementation impl);
static void hintVertexArrayImplementation(VertexArrayImplementation impl);

But it should be only one method that sets the implementation strategy since the vao and binding belong together.

So far it works, but one method to change the implementation should be the goal.

I'll check the other dsa objects.

kind regards,
PonchoBob

from globjects.

Thanks for the in-depth analysis. I can confirm that for DSA, the glCreate* functions should get used and that within globjects, this implementation path is missing.
Problably we have to add implementation strategies for Vertex Arrays as well. And while we're at it, check other directly created objects within Resource.cpp as well.

Hello there,
"found" some more in the resource.cpp at line number 185
IDResource(createObject(glGenSampler))

Actually glCreateSamplers is the current DSA function. But using glGenSamplers with subsequent calls to glSamplerParameter* caused no errors, so....

kind regards

from globjects.