OpenGL Code impact Question

What I am wondering is how much impact the following code would make on speed if i called it more than once a frame to bind different vectors of floats for different models.


GLuint vertexbuffer;
glGenBuffers(1, &vertexbuffer);
glBindBuffer(GL_ARRAY_BUFFER, vertexbuffer);
glBufferData(GL_ARRAY_BUFFER, verts.size() * sizeof(float), &verts[0], GL_STATIC_DRAW);

GLuint uvbuffer;
glGenBuffers(1, &uvbuffer);
glBindBuffer(GL_ARRAY_BUFFER, uvbuffer);
glBufferData(GL_ARRAY_BUFFER, texs.size() * sizeof(float), &texs[0], GL_STATIC_DRAW);

glBindBuffer(GL_ARRAY_BUFFER, 0);

My current setup uses a single, large vector, but this has many bugs that are hard to track.

Will this code cause any if at all speed detriments to use it to bind many different vectors from different models.

Also, any suggestions on different render methods are allowed.

Try it and benchmark it. Binding buffers is expensive. VAOs help. Bindless helps more. Packing multiple batches into the same buffers can reduce binds and increase performance. Lots of info in the archives on this.

Follow up question: How costly are matrix operations.

Depends on what kind of matrix operation you mean…

Sending a new Matrix to the program with glUniformMatrix4fv();

You’re talking about things that are very difficult to quantify, and which will be at least somewhat implementation-dependent.

Is updating a matrix via a uniform faster than updating a matrix stored in a uniform buffer? It may be, it may not. For example, on most ATI hardware, uniforms in shaders (except for opaque types) always use an internal uniform buffer. So a single glUniformMatrix call will probably not be much slower than updating a single matrix yourself on ATI hardware. However, NVIDIA hardware may have a more optimized way of storing uniforms, in which case, the call may be faster. Or the call may be slower, but accessing the matrix in the shader is faster.

By contrast, uniform buffers allow you the ability to update multiple matrices in a scene all at once, potentially using advanced streaming techniques to do so. They can also update other per-instance data. Which is faster? It depends. Do you need to change UBO bindings for each object, or are you able to simply pass an instance index to tell the shader where its data is? How do you pass this instance index? And so forth.

The answer is that it’s complicated. Performance always is.

I guess this a case of try it and see what works best.

Performance is always like this too.

As well as the items Alfonse mentions, which are absolutely correct, it’s also the case that everybody’s code is different, and everybody’s code stresses different parts of the pipeline differently. So what’s faster with my program may be slower with yours, and vice-versa. The best advice that can be given tends to be along the lines of more generic guidelines, i.e fewer large updates are preferred to many small updates, minimize state changes between draw calls, these API entry points are more likely to be optimized by vendors, etc; but in reality you do need to benchmark in your own code, and you also need to evaluate what is sometimes a tradeoff between faster code and cleaner code. If you already run fast enough it may even be perfectly acceptable to leave some of your code on a slower path.