Update Constant Buffer的驱动实现

在使用经典的图形 API （比如 Direct3D11 ）时，一个典型的场景渲染过程可以用伪代码描述如下：

Map Constant Buffer For View  //For example, View Transform, Projection Transform

for each Mesh

{

Map_Write_Discard Call For Constant Buffer For Per Mesh Data //For example, Model Transform

...... //For example, CPU Write to Constant Buffer For Per Mesh Data

Unmap Call

Draw Call For Mesh

}

或

for each Mesh

{

UpdateSubresource Call For Constant Buffer For Per Mesh Data And Pass The Pointer For Per Mesh Data In //For example, Model Transform

Draw Call For Mesh

}

尽管我们需要绘制很多个 Mesh ，但是我们只需要创建一个 Constant Buffer 。

那么问题来了！当我们在绘制第 2 个 Mesh 时，该 Constant Buffer 中存放着第 1 个 Mesh 的相关数据，很可能正在被 GPU 读取；但是，我们仍可以用 CPU 将第 2 个 Mesh 的相关数据写入到该 Constant Buffer 中，并不会与 GPU 的读取发生冲突，这是为什么呢？

MSDN / Direct3D11 / How to: Use dynamic resources

https://docs.microsoft.com/en-us/windows/desktop/direct3d11/how-to--use-dynamic-resources

MSDN 上的 Direct3D11 文档中对 Map_Write­_Discard 的实现方式进行了说明：当应用层以 Write_Discard 的方式 Map 一个 Buffer 时，驱动会返回一块新的内存区域给应用层，从而避免了 CPU 与 GPU 之间的读写冲突。

Holger Gruen. "Constant Buffers without Constant Pain". NVIDIA GameWorks Blog 2015.

http://developer.nvidia.com/content/constant-buffers-without-constant-pain-0

NVIDIA GameWorks Blog 上的一篇文章对 Map_Write_Discard 的驱动实现进行了说明：驱动根据某个配额（目前是 128MB ）预先分配一大块内存，当应用层调用 Map_Write_Discard 时，驱动以类似于线性分配器的方式不断将指针后移动，并将新的内存区域返回给应用层。

同时该文章中指出：驱动将应用层对 UpdateSubresource 的调用转发到 Map_Write_Discard ， UpdateSubresource 和 Map_Write_Discard 在本质上是等价的。

// 分界线 ---------------------------------------------------------------------------------------------------------------------------

MSDN / Direct3D12 / Fence-Based Resource Management / Ring Buffer

https://docs.microsoft.com/en-us/windows/desktop/direct3d12/fence-based-resource-management

在使用次世代的图形 API （比如 Direct3D12 ）时， Map_Write_Discard 不再被 API 支持，需要在应用层实现相关的语义， MSDN 上的 Direct3D12 文档中给出了一种基于 RingBuffer 的实现方式（本质上即模仿驱动实现 Map_Write_Discard 的方式，只不过配额（即上文中的 128MB ）可以根据应用层自身的实际情况进行定制）。