1. Can't really avoid putting the matrices in constant buffers. For something like world transform that is not necessarily constant frame-to-frame, more than one rotated constant buffer dedicated to the world transform would be necessary to avoid sync issues (unless you depend on drivers to do orphaning, which is far from gauranteed). It might be worth it though to simply modify a single 'matrices' constant buffer each frame for each object, and only do something more complex if you actually need to.

2. Which is essentially how tons of one object with one draw call (instancing) works.

3. Probably not worth the trouble unless you have a ton of unique non-moving objects and that single matrix multiplication in the shader is slowing things down (unlikely).

To clarify:

-When rendering an object in OpenGL 2.*, fixed function (or even in most shaders) there are exactly two matrices involved: the projection matrix and the modelview matrix.

-When rendering an object in OpenGL 4.*, you must use a shader, and there are no built-in matrices. So you can have as many as you want. If your shader does use them, it's fastest to compute a P*V*M and pass that in as one matrix. That way, there's only one matrix multiply per vertex.

-In your OP, I'm assuming you're asking about drawing many objects with instancing, and you want each to have a different model matrix, but the same view and projection matrices?

In the latter case, a crufty strategy that I know will work is to store each matrix in a single texel of a RGBA32 texture, and then sample that in your vertex shader. I think the right way to do this though is to look at uniform buffer arrays.

Or, you know, just draw your objects one at a time.

This works, but this seems really counter-intuitive from a performance perspective as you have to do a lot of synchronization for a simple rendering process. Not to mention drawing operation becomes O(n) for the number of objects.

A couple of quick thoughts:

- There isn't as much synchronisation as you think, because commands to the GPU are pipelined. If you rapidly issue multiple draw calls, the GPU is going to overlap their processing as and when it can (provided you don't explicitly force synchonisation).

- Rendering N objects is always an O(N) operation. Parallelisation just obscures that fact.

The easiest and obvious solution I can think of is to put world matrices in a constant buffer but if I am not mistaken from the architecture of video card memory, you are not able to dynamically allocate constant buffers. I can think of this being a big problem because in real situations, the number of objects to be rendered would vary realtime.

I don't think this is so huge problem, you actually can allocate new (bigger) buffer, copy old buffer to new one, and remove old.

The right way is definitely through uniforms (as mentioned), for example we send just single matrix to GPU (computed World * View * Projection on CPU), and it's fine for single objects.

For instancing we pre-compute matrices into texture from which we read in vertex shader. Note that you can dynamically add/remove instances from texture and it auto-sizes in our implementation, when you could get over capacity we "realloc" to twice the space, and when you're less then half of capacity we "realloc" to fit the space again. It works, but reallocations are really rare (with exception to state, where you're editing your world, where "reallocations" happen more often) in runtime.