PDA

View Full Version : glDisableVertexArray()



ugluk
05-19-2010, 12:51 AM
I suppose when one is using VAO it is not necessary to call?

But what if one is not using VAO? I see in some tutorials people call it like this:

glEnableVertexAttribArray();
draw();
glDisableVertexAttribArray();

But some people don't do it, even though they switch to a different shader program.

Is it a good idea to call glDisableVertexArray() after the drawing to clean up if different vertex arrays are setup afterwards? Say I had 3 vertex arrays enabled at first and then I'd switch to a shader program using 2 vertex arrays, is a crash possible?

Dark Photon
05-19-2010, 05:20 AM
glEnableVertexArray();
draw();
glDisableVertexArray();
It's not completely clear what you're talking about because there are no such calls in the API.

You may be talking about something else (I see two possibilities), but the calls I "think" you're referring to are gl{Enable,Disable}VertexAttribArray (for generic attributes).

Yes, make sure these are set properly when you submit a batch. No, you don't have to call these for a vertex attribute between batches if the "enabled" state doesn't change (which may explain what you were seeing). And with VAOs, the "enables" of each vertex attribute are stored in the VAO when you build it. So while you need these set right when building the VAO, you don't need set them when just using (binding) a preconfigured VAO to get ready for a batch.

ugluk
05-19-2010, 05:55 AM
Sorry for my mistake, I corrected my post.

I asked because I see that even in book samples, not just the tutorials, people neglect to call glDisableVertexAttribArray() to clean up after drawing. I've had the scenario in mind, where there are no VAOs available and whether the "enabled" state changes is not determinable (i.e. rendering from a partially culled scene graph).

So glDisableVertexAttribArray() in this scenario _is_ necessary? If one simply enables a vertex array using the same index (kinda overrides the old one), it could still work without deleting? Is the GL going to pump a batch into the shader even though no 'in' variable is bound to a certain vertex array?

Dark Photon
05-20-2010, 05:38 AM
So glDisableVertexAttribArray() in this scenario _is_ necessary?
Well, if you're not using that attribute, you should disable it. If you don't, GL will pull from the bound pointer/VBO, which if that references a freed block might do some ugly things.


If one simply enables a vertex array using the same index (kinda overrides the old one), it could still work without deleting?
Your wording is confusing here ... don't understand the deleting reference. I think you are talking about:

Enable attr array 1
Set attr array 1 pointer
glDraw...
Set attr array 1 pointer
glDraw...

This is fine. There's no need to mess with the enables unless they change.


Is the GL going to pump a batch into the shader even though no 'in' variable is bound to a certain vertex array?
I don't think you mean batch, you mean vertex attribute. And yes, AFAIK, if you enable it, it'll be pulled from memory and sent down. The fact that your shader isn't using it is somewhat academic.

And of course, if your shader "does" reference an attribute and you "don't" populate/enable it to send it down, that can cause problems as well.

skynet
05-20-2010, 06:05 AM
And yes, AFAIK, if you enable it, it'll be pulled from memory and sent down. The fact that your shader isn't using it is somewhat academic.

What makes you think so? Pulled by whom, sent where?


And of course, if your shader "does" reference an attribute and you "don't" populate/enable it to send it down, that can cause problems as well.

That is what latched attributes are there for. Using glVertexAttribXXX() you can provide some default value for attributes that you don't have per-vertex.

Dark Photon
05-20-2010, 07:46 AM
And yes, AFAIK, if you enable it, it'll be pulled from memory and sent down. The fact that your shader isn't using it is somewhat academic.

What makes you think so? Pulled by whom, sent where?
Pulled by the GPU memory fetch logic into the pre-vertex-shader cache to be made available to the vertex shader.

I don't know this for sure, but AFAIK nowhere are we told that it won't be. Enable the attribute and set the pointer, and it'll probably fetched.

It's possible the driver is doing some "smart stuff" here selectively (or totally) ignoring your enables based on the attributes actually referenced in the vertex shader, but I doubt it, and past experience doesn't support that conclusion.

Though if we could count on that, why wouldn't we just enable all of the vertex attributes at program startup, always leave them enabled, and only set the pointers for batches? Less GL calls, right? Then what's the purpose of the enables again?

So I don't know for sure, but it's an educated guess.



And of course, if your shader "does" reference an attribute and you "don't" populate/enable it to send it down, that can cause problems as well.
That is what latched attributes are there for. Using glVertexAttribXXX() you can provide some default value for attributes that you don't have per-vertex.
Yeah, good point.