This might sound stupid..I was reviewing my instanced sprites code, and something bothered me..

[its not about instancing, just the overall architecture/usage of cbuffers]

With a draw call I can say which piece of a vertex buffer to use. Meaning I can let it there and use it multiple times by saying offset and number for each drawable..ok

So, Instead of having a "drawable" cbuffer for each drawable/'renderable unit', or sharing one between multiple ones and remap it everytime (which is bad due syncing), why cant I just allocate a huge ass cbuffer and use it in slices just like vertex buffers? I could allocate a cbuffer for all my sprites, have each sprite hold an offset, and only map it once per frame..

So on the draw call I could have extra params for the cbuffers.

Well, I see you can have lots of different cbuffers on a shader, but its nothing a description structure couldnt solve. (actually, I think an array with offsets for each cbuffer would be enough)

Why the difference?

I hope Im making sense. This stuff is again cold in my head.

It was simply not available at this point in time. With DirectX11.1, you have access to this kind of functionality, via ID3D11DeviceContext1::VSSetConstantBuffers1 and equivalents. pFirstConstant does just what you described. I can't recall the requirements for DirectX11.1, but I suppose you need a pretty new GPU and Windows 8. So if you are still at DirectX10, it seems you are out of luck.

EDIT: Pardon, I linked the wrong MSDN page, should be fixed now

A little different than I expected. I was thinking in offseting from the draw call, just like for vertex buffers.

Whit the VSSetConstantBuffers1, I quite dont get it. You still need to bind it every time for each drawable, with the offset, and call draw() for each sprite.

If it where from the draw call, you wouldnt need to care about when or ordering. Just about updating all the data to the buffer and before rendering everything bind it only once.

The advantage of VSSetConstantBuffers1 over VSSetConstantBuffers would be I guess:

It doesnt move the buffer in the case you bind an already bound one with just a different offset.

Still a single buffer instead of a bunch of small ones.

But why not from the draw call?

But why not from the draw call?

Oups, I misread that part of your question.

As for why: You can see that the complexity of the parameters to be bound is quite high. You have an array with N entries of offsets for each bound cbuffer, and that for every shader stage. This would bloat the draw call quite a bit.

I also don't see what you are gaining outside of one less API call per shader stage for binding the buffers. Whenever you call Draw() you need to have the information about cbuffers around eigther way. So if you call Bind() and Draw(), or Draw with parameters doesn't change anything in my mind - IDK, but in my architecture of the renderer it would make things even worse.

The main advantage of having it the way that DirectX11.1 imposes that I can see, is being able to have one large cbuffer, that you can update once per frame with a single memcpy. This can improve performance quite a bit over having to map one cbuffer per drawable.

Did you originally come from a OpenGL background Juliean? I think the hardware abstraction layer optimizes the draw calls. You may have a bottleneck in ur render loop. Dont do any updates in the render but on a separate thread.

No, I started out with DirectX, and only recently adopted an OpenGL4 renderer. I gotta say I can't make much sense of what you are implying with your post right now, so if you could elaborate on that in more detail I'd be very grateful. What I was implying with in my post is that

a) in order to achieve what the OP wants on Draw-Call level, each draw call has to have eigther 1) 5 additional parameters merely for cbuffer offsets for each shader stage or 2) a double array for each shader stage and all bound buffers. This is not so much even a problem on performance end, but more for the API bloat it imposes.

It is a strict fact that you get more performance if you map one 128 MB Cbuffer and copy data to it in one pass than you would if you mapped an amount of say 1024 buffers of the same size seperately though. Thats why what I was saying is that i definately makes sense in what DirectX11.1 proposes, but having offsets being passes in into the drawcall doesn't gain much, and can make matters worse on an architectural level.