ConstantMemory（常量内存）是 GPU 上一种特殊的只读高速存储区域，专门用于存储着色器参数、变换矩阵、材质属性等在渲染过程中不会改变的数据。其核心设计围绕 GPU 的并行执行模型和内存访问特性展开。
Warp 内线程访问同一变量时的冲突问题
GPU 的核心执行单元是 Warp（线程束，NVIDIA 术语，AMD 称为 Wavefront） ，一个 Warp 通常包含 32 个线程（不同架构可能有差异）。这些线程遵循 SIMT（单指令多线程） 模型 —— 同时执行完全相同的指令，但操作各自的数据。
当 Warp 中的 32 个线程需要访问同一个变量（比如一个 Uniform 变量）时，如果这个变量只存在于一个物理内存地址（比如普通全局内存），会出现问题：GPU 的内存控制器一次只能处理一个地址的访问请求。32 个线程同时要读这个地址，内存控制器只能串行处理（一个接一个响应），导致 31 个线程等待，产生访问延迟（冲突） 。
这就像 32 个人同时要喝同一杯水，只能轮流喝，效率极低。
ConstantMemory 的广播机制
ConstantMemory 本质是通过硬件级的常量缓存（Constant Cache） 优化访问。当 Warp 中的线程访问 ConstantMemory 中的同一个变量时，GPU 的常量缓存会执行 "一次读取，广播给所有线程" 的操作：
- 内存控制器只需从 ConstantMemory 中读取一次该变量；
- 通过硬件电路将这个值同时传递给 Warp 内的所有 32 个线程，无需等待。
这就像 32 个人同时要喝的水，被装在一个 "多头饮水机" 里，所有人能同时喝到，没有等待。
需要注意，这里并非物理上复制多份到每个线程，而是通过缓存的广播机制实现 "一次访问，全体共享"，从根本上避免了串行访问的冲突。
注意：广播机制仅在 Warp 内所有线程请求同一个地址时触发。如果线程请求不同地址，会导致访问序列化，性能大幅下降。
ConstantMemory 为什么是只读的
ConstantMemory 的设计目标是存储不会被修改的常量数据（如着色器参数、变换矩阵、材质属性等），这些数据通常由 CPU 预先设置，在渲染/计算过程中保持不变。
只读特性的原因有两个：
- 简化硬件设计：如果允许写入，需要处理多线程写入的一致性（比如 32 个线程同时写同一个地址，谁先谁后？如何同步？），会极大增加硬件复杂度。
- 保证缓存效率：常量缓存的广播机制依赖 "数据不变" 的前提。如果数据可被修改，缓存中的值可能失效，需要频繁更新，破坏了高效访问的基础。
ComputeShader 与 ConstantBuffer
ComputeShader 的核心功能是通用计算，经常需要对缓冲区进行写入操作（比如计算结果输出）。但 ConstantBuffer 属于 ConstantMemory，而 ConstantMemory 是只读的 —— 硬件不允许任何写入操作（包括初始化）。
因此，ConstantBuffer 的初始化必须由 CPU 完成（通过 API 如 DirectX/OpenGL/Vulkan 设置），再传递给 GPU。ComputeShader 作为 GPU 上的计算程序，自然无法对其写入，也就不能初始化。
Unity 实例化中 ConstantBuffer vs StructureBuffer
Instance 渲染（实例化渲染）需要为每个实例传递独立数据（如每个物体的世界矩阵、颜色等）。此时：
- ConstantBuffer：数据存储在 ConstantMemory 中，依赖常量缓存的广播机制。当 Warp 中的线程处理多个实例时，访问实例数据时能通过缓存高效广播，无冲突，延迟极低。
- StructureBuffer：属于全局内存（Global Memory）的结构化缓冲区，访问时需要通过索引计算地址（每个实例有不同索引）。全局内存的缓存机制（如 L1/L2 缓存）对这种 "分散访问" 的优化不如常量缓存，且可能产生线程间的访问冲突（不同线程访问不同地址时，缓存利用率低）。
因此，在 Instance 场景中，ConstantBuffer 的访问效率更高，表现更快。
总结
ConstantMemory 的核心价值是通过 "只读 + 常量缓存广播" ，解决 Warp 内线程访问同一变量的冲突问题，特别适合存储高频访问的常量数据。而其只读特性、无法被 ComputeShader 初始化等限制，都是为了保证这种高效访问的设计取舍。在 Unity 实例化等场景中，正是这种硬件级的优化让它比普通缓冲区更快。
尽管 ConstantBuffer 极快，但受限于 64KB 的容量上限，它更适合存储高频复用的"全局常量"或"中等规模的实例数据"。