ie, as I see it you'd have two ways of doing it:

• Update the mesh transform, then issue a glDraw*Instanced call with a single instance, always fetch transform in index 0. Repeat for every single mesh.
• Update transform UBO with all the transforms that can fit, then issue glDraw*Instanced call, repeat this draw call increasing the base instance ID by one for every single mesh until you run out of transforms in the UBO (doing the instanced index buffer trick you mentioned since instance ID is always 0).

So you always end up with one draw call per each different mesh. Thing that differs is UBO updating scheme (no scheme in first one, batching scheme in the second one).

Doing this for just one instance is completely valid. If you do it the way you said, although valid; your API overhead will go through the roofs, specially if you have a lot of different meshes.

Then with the instanced method, how would you handle drawing different meshes?

ie, as I see it you'd have two ways of doing it:

1. Update the mesh transform, then issue a glDraw*Instanced call with a single instance, always fetch transform in index 0. Repeat for every single mesh.
2. Update transform UBO with all the transforms that can fit, then issue glDraw*Instanced call, repeat this draw call increasing the base instance ID by one for every single mesh until you run out of transforms in the UBO (doing the instanced index buffer trick you mentioned since instance ID is always 0).

So you always end up with one draw call per each different mesh. Thing that differs is UBO updating scheme (no scheme in first one, batching scheme in the second one).

glDrawElementsInstancedBaseInstance - one big per-instance buffer containing all of your instances. It doesn't have to be a UBO; if the per-instance data is small enough (which it will be if it's just a transform) it can be a VBO and specified in your VAO using glVertexAttribDivisor. Use the baseinstance parameter of your draw call to specify which instance you're currently drawing. That will index into your per-instance buffer effectively for free. gl_InstanceID remains 0-based but in this case it doesn't matter because you're not using it. You're not touching uniforms, you're not updating state between draws, the only thing that changes is the parameters to your draw calls.

I'm not arguing about the impact of the UBO updating/binding, we pretty much established we do are trying to do UBO update batching. Nor I am talking about OpenGL 4.x features as I've mentioned in a previous post (ie, no indirect draw calls). Strictly GL 3 here.

What I am asking is how much different is doing a glDraw*Instanced call changing the instance ID offset vs doing a normal glDraw* call while calling glUniform1i for the indices.

Mathias said the draw-glUniform1i combination it would be detrimental if you have many different meshes (we're still limited by one different mesh -> one draw call) but I'm trying to figure out if it would be that much worse than doing a glDraw*Instance call and changing the base instance ID, fetching the real index from an instance attribute buffer, since you still have one draw call per different mesh.

State isn't changing beyond the glUniform1i call, which requires no binding. If it matters, the same could be accomplished with glVertexAttrib*i and passing the index that way before each draw call (which is what nVidia guys used for their scene graph presentations in 2013 and 2014).

In short, for different meshes, we still have one draw call per mesh, we still can batch UBO updates, but there are several ways to get the needed index to the shader (glUniform*i, glVertexAttrib*i, or glDraw*Instanced with indices in instanced attribute).

EDIT: Reading mhagain's post:

t doesn't have to be a UBO

Then again, what you're saying here is basically, dont use UBOs, put all in instanced attributes? It sounds good but see this presentation for example, there is a small section on UBO updating and indexing inside the shader, maybe nVidia hardware doesn't works that well with instanced drawing.

EDIT2: Fucking quote blocks and fucking editor for fucks sake I fucking hate it.

This is the most compatible way of doing it which works with both D3D11 and OpenGL. There is a GL4 extension that exposes the keywords gl_DrawIDARB & gl_BaseInstanceARB which allows me to do the same without having to use an instanced vertex buffer (thus gaining some performance bits in memory fetching; though I don't know if it's noticeable since the vertex buffer is really small and doesn't consume much bandwidth; also the 4096 draws per call limit can be lifted thanks to this extension).

Not sure if it helps performance wise, azdo's slides say that gl_DrawID often cripples performance

http://fr.slideshare.net/CassEveritt/approaching-zero-driver-overhead (slide 33)

There is no word on gl_BaseInstance though.

I starting to be worried by rumors that Google may have its own low level api too. This would basically mean one API per OS which break the purpose of Vulkan in the first place...

Wouldn't that actually justify the purpose of Vulkan? One cross-platform API that will work regardless of the OS, more or less the same purpose as with OpenGL. This would be in contrast to it simply being intended to fill the platform gap, providing a high performance 3D graphics API on platforms that don't have a native one. I'd be highly disappointed if the latter purpose were all that the Vulkan designers ever hoped to achieve.

Edit: I suppose the core question here is: are the multidraws (indirect or not) actually pushed as such onto the GPU's command buffer (that is, is there a 'multidraw' command) or is the driver extracting the draws and inserting them individually (or batched, whatever) onto the command buffer? If the former, then it would certainly be faster. If the latter, I imagine a ton of draw bundles would be faster.

AFAIK, it's former that the application pushed the draws into the command buffer.

On Radeon beginning from hd6950 and geforce multi draw indirect is a hardware feature. On Intel (up to Haswell at least, don't Know for future chip) it is emulated by a loop in the driver.

One would hope that Intel at least validates once only rather than for each draw call in the loop.