**Sigh**

If anyone has lots of questions, you can just compile and try Ogre 2.1, then disect its source code to see how we're handling it. It's Open Source after all.
Doing what I'm saying is not impossible, otherwise we wouldn't be doing it.

To answer The Chubu's question, glDrawElementsInstancedBaseVertexBaseInstance has THREE key parameters:

• baseInstance: With this I can send an arbitrary index as I explained, which I can use to index whatever I want from a constant (UBO) or texture (TBO) buffer. I can even perform multiple indirections (retrieve an index from an UBO using the index from baseInstance)
• baseVertex?: With this I can store as many meshes as I want in the same buffer object; and select them individually by providing the offset location to the start of the mesh I want to render. With this, I don't need to alter state at all (unless vertex format changes). The meshes don't even need to be contiguous in memory; they just need to be in the same Buffer Object and aligned to the vertex size.
• indices: With this I can store as many meshes' index data as I want in the same buffer object, and select them individually by providing the offset location to the start of the index data. Remember to keep alignment to 4 bytes. Bonus points: You can keep the vertex and index data in the same buffer object.

The DX11 equivalent of this DrawIndexedInstanced and the analogous parameters are StartInstanceLocation, BaseVertexLocation & StartIndexLocation respectively.

We treat all of our draws with these functions.

The DX11 function works on DX10 hardware just fine. glDrawElementsInstancedBaseVertexBaseInstance was introduced in GL 4.2; however it is available to GL3 hardware via extension. The most notable remark is that OS X doesn't support this extension, at the time of writing.

The end result is that we just map the buffer(s) once; write all the data in sequence; bind these buffers and then issue a lot of consecutive glDrawElementsInstancedBaseVertexBaseInstance / DrawIndexedInstanced calls without any other API calls in between.

We only need to perform additional API calls when:

• We need to bind a different buffer / buffer section (i.e. we've exhausted the 64kb limit)
• We need to change state (shaders, vertex format, blending modes, rasterizer states; we keep them sorted to reduce this)
• We're using more than one mesh pool (pool = a buffer where we store all our meshes together), and the next mesh is stored in another pool (we sort by pools though, in order to reduce this switching).

To be fair, I understood what you were doing after my first post - I just wanted to know if you were experiencing any stalling from filling your buffer prior to a large batch of draws, and how you were going to handle a Vulkan/D3D12 transition with bundles and the like.

Also, I've never really liked the 'just look at the source' thing. I have no familiarity with Ogre, and last time I tried to build it, it was relatively difficult and frustrating. It would probably take me quite some time not only to understand what you're doing, but why, whereas spending the 10 minutes in conversion would be more productive (and I get the benefit of talking to a fine chap such as yourself :) ).

To be fair, I understood what you were doing after my first post - I just wanted to know if you were experiencing any stalling from filling your buffer prior to a large batch of draws, and how you were going to handle a Vulkan/D3D12 transition with bundles and the like.

I don't understand why you think there would be a stall.

Let's assume we draw exactly 4096 meshes (doesn't matter if they're different or not).
This will consume the whole 64kb buffer.

If I split this into smaller batches, I will perform 4096 draw calls and use 16 bytes per draw. In the end I will still have used 64kb, but with much more binding in the middle.

If I draw less, say, 16 meshes; then I will write 256 bytes from CPU into the GPU. Then two things may happen depending on RenderSystem:

1. GL/Vulkan/D3D12: We bind 256 bytes, the GPU loads exactly 256 bytes into their L1/L2 caches (or constant register file)
2. D3D11: We bind 64kb (since D3D11 binds the whole buffer's size). We will be using 256 bytes. The remaining 65.280 bytes may be loaded by the GPU, but not be read by the shader and are filled with garbage.

The most "wasteful" here is D3D11. However, reading the extra 65.280 bytes is a joke for any GPU; and is certainly not going to be a bottleneck to worry about.

I was thinking in the sense that you batched 4,096 draw calls, before the call even got submitted to the GPU, you'd have to perform a copy to GPU memory for your 64KiB of data. Until that copy is complete, the GPU may not be doing anything at all. However, I am quite possibly vastly underestimating the speed of such a copy (which is probably on the order of microseconds).

I was thinking in the sense that you batched 4,096 draw calls, before the call even got submitted to the GPU, you'd have to perform a copy to GPU memory for your 64KiB of data. Until that copy is complete, the GPU may not be doing anything at all. However, I am quite possibly vastly underestimating the speed of such a copy (which is probably on the order of microseconds).

If you do it properly, copying data is completely asynchronous, in that it only involves CPU work - the GPU is unaware.
Also, the GPU is almost always 1 or more frames behind the CPU - i.e. The OS/driver are buffering all your draw calls for 1+ frames.
Stopping issuing draws to copy some data, or run gameplay code, etc will not starve the GPU, because there's this massive frame long buffer of work. As long as once per frame you submit a frame's worth of work, the GPU will never starve.

I think I'm too used to working on CPU-bound applications to ever actually experience this :)

Well in a CPU bound situation, the GPU will starve every frame until you can manage to get your CPU frametimes below your GPU frametimes.

As for the copy, say we're lucky enough to have a 20Gbps bus -that's ~2.33 GiBps, or ~2.38 MiB per millisecond, or ~2.44 KiB per microsecond!
So, 64KiB could be transferred in ~26 microseconds.

On the other hand, if you have to to a GL/D3D map/unmap operation, that's probably 300 microseconds of driver overhead!

Yup, on certain projects I've certainly seen map/unmap operations build up.

This is a different (and personal) codebase from what I usually work on (which are clients'), so I'm trying to "do things right" - I suspect I'm a bit 'polluted' by other people's codebases that didn't necessarily work well. Forgive my questions if they seem ignorant - I haven't worked on an actual modern, well-performing codebase :(.