3 hours ago, matt77hias said:

But does the command allocate memory for buffer mappings or buffer updates?

Turans explanation is pretty complete but i have some gaps in my own knowledge.   If you are doing updates during the command recording phase then its allocating memory for each map discard.  I'm not sure though about updates outside of MAP_ DISCARD.     Hodge has more experience on this front.   

I do multithreading and command buffer recording in my dx 11 engine but nothing to the level you are after.  I've set my constant buffers up prior to command recording to reduce the amount of buffer update calls during replay.  And i try avoiding doing map discard updates anyway more than once per frame only because it becomes a bad habit and encourages done bad design decisions. 

From what i remember.  Everything you do in a deferred context incurs memory consumption.   I would give you a more definitive answer.  I'm just in the middle of Thailand on a phone ???

10 hours ago, ErnieDingo said:

I've set my constant buffers up prior to command recording to reduce the amount of buffer update calls during replay.

But if you do not update buffers more than once every frame, then I assume you have some buffer resource for every model? I currently reuse one buffer resource for all my models, so more like an update per draw.

Maybe think about a constant buffer pool (instead of fixed per-asset buffers), where before each draw operation you pick a "fresh" buffer (of a suitable size), and memcpy your transforms and whatnot into it. You'll promise the driver that you won't be overwriting it under GPU's hands (NO_OVERWRITE), and you hold that promise by not writing into the constant buffer more often than every 2 frames since the last use (simple solution, pronounce buffers fresh again when you're sure GPU passed enough frames) or use fencing (complex solution) to be sure GPU isn't reading anymore. That way, driver won't have to make hidden copies of it. This approach is multi-platform-friendly. The pool needs to be big enough and/or you have to implement the complex solution with more precise fences.

Edit: An even simpler solution is stick to your per-asset cbuffer, but have multiple copies (2-3 frames) and cycle them each frame, also with NO_OVERWRITE.

Also, do read the article from NVIDIA linked by Infinisearch, it's a good approach.

44 minutes ago, matt77hias said:

But if you do not update buffers more than once every frame, then I assume you have some buffer resource for every model? I currently reuse one buffer resource for all my models, so more like an update per draw.

Yah.  I do use instance buffers for instance specific attributes say like color and a cbuffer for any material related attributes.   I'm not too complicated at the moment. 

2 hours ago, pcmaster said:

Also, do read the article from NVIDIA linked by Infinisearch, it's a good approach

Thanks for pointing out, I didn't receive an email/popup for every post in this topic.

I need to refactor some day. Currently I do one update/draw call involving two bindings to the shaders (vertex and pixel). So that would be ok for d3d11.0, but can be optimized for d3d11.1 by adding them together and binding a location in that larger buffer. But why is there a 256 bytes alignment instead of the normal 16 bytes alignment?

Didn't know though that UpdateSubresource is implemented as Map/memcpy/Unmap for NVidia hardware.

1 hour ago, matt77hias said:

Thanks for pointing out, I didn't receive an email/popup for every post in this topic.

IIRC there are two more articles in that series... they were all informative IIRC.

edit - I was wrong the one with three articles were on structured buffers, not constant buffers.