1) Does the d3d api return right now when call it? or return after it completely execute ? such as drawXXXX , setXXXBuffer
It depends on the API. Some APIs will wait for the GPU, while some will return immediately. A good rule of thumb is to check if you're allowed to use it on a deferred context - if so, it should return immediately on the immediate context. If not, it probably needs to wait for the GPU. One example is Map() with D3D11_MAP_READ.
2) the UpdateSubresource method modify the ram in graphic card directly or modify a temporary buffer in cpu side?
Ryan was pretty correct on this one. I suppose it's technically possible that the update could be done in lock-step with the GPU, but I don't know of a driver that does that. Instead, they allocate some storage, copy what you pass in, and then record the equivalent of a CopySubresourceRegion() to get the contents into the destination on the GPU timeline.
3) If the buffers are live in ram of graphic card, the setXXXBuffer(buffer) is just call gpu to use that buffer in graphic ram?
It depends on the type of buffer. If it's a DEFAULT buffer, then yes it is expected to live in VRAM, but an DYNAMIC buffer probably does not. The GPU has the ability to read from system RAM. The Set*Buffer call typically just records some state in the driver, which gets translated into a series of operations at draw time to ensure the right resources are used by that draw.
4) What discrepancy between context->Map/unmap and context->UpdateSubresource , the context->Map will cause lock?
You can think of UpdateSubresource (on a buffer) as a sequence of:
1. CreateBuffer() with type DYNAMIC.
2. Map(WRITE_DISCARD).
3. Memcpy().
4. Unmap().
5. CopySubresourceRegion().
Map with WRITE_DISCARD can technically block for the GPU to finish reading from previous contents, but typically performs "renaming", which gives you a new region of memory to write to. Future references to that buffer will refer to the new memory instead of the old contents. Map with READ or WRITE will block until the GPU is done with the buffer.
5) If I have n cbuffer, it sounds context->SetConstantBuffer(0, n, &buffers[0]) will much faster than SetConstantBuffer one by one, but some guys say perframe cbuffer must set once per frame, and per object cbuffer will be set many times per frame, Is it necessary for me to set perframe cbuffer together with perobject cbuffer to gain the "one commit will faster than multi commit" ? or set them dependently?
I'd say the rule of thumb is:
1. Batch bindings together when you can.
2. Avoid redundant API calls when you can.
3. Don't worry too much about this until you see it as a performance issue. Like Ryan said, profile.
device->UpdateSubresource call driver to update buffers, but it is still stored in RAM-side, when buffers are needed, it upload to VRAM, and when graphic card is out of VRAM, it download to RAM ?
The Windows memory manager does shuffle resources in and out of video memory depending on whether they're needed or not, but UpdateSubresource is unrelated. The memory that gets written during the API call doesn't get migrated like that, it gets copied. The preferred location of a given allocation is an immutable property, and whether or not the CPU can write to it depends on that. The CPU typically cannot write directly to VRAM, so if something prefers to live in VRAM, then CPU access is typically not requested.
I hear about cpi-gpu contention , what is the command buffer and non-mappable memory ?
The command buffer is a buffer that stores commands. It's allocated by drivers, and is the thing that is submitted to the GPU to trigger work to happen. Non-mappable memory is memory that can't have Map() called on it.
Here's another question, I have read some articles(forget which one) says the driver will pack something when draw, pack what?
You need to be more specific. I don't know what you're talking about.
