为什么我们仍然在D3D11等中使用固定功能混合操作？

Question

我正试图理解为什么我们仍然在较新的3D API（如D3D11）中使用固定功能混合模式。在D3D10中，删除了固定功能Alpha Clipping，转而使用着色器。为什么，因为它对几乎任何情况都是一种更强大的方法。

那么为什么我们不能计算或拥有混合操作（也就是我们当前渲染的RenderTarget中的纹理样本）？视频卡管道中是否存在一些难以实现的硬件设计问题？

这个有用的原因是因为你可以做一些事情，比如使折射着色器运行得更快，因为你不必在每个折射对象覆盖的两个renderTargets之间来回交换。例如用于OS或游戏UI的折射窗口系统。

在哪里可能是提出这样一个想法的最佳地点，因为这不是一个讨论论坛，因为我很乐意在D3D12中看到这个？或者这在D3D11中已经可以使用了吗？

Answer 1

  

那么为什么我们不能计算或拥有混合操作

谁说你不能？使用shader_image_load_store（和D3D11等效），你可以用图像做任何你想做的事情。前提是您遵守规则。最后一部分通常是绊倒人们。在着色器中执行完全读取/修改/写入，以便稍后的片段着色器调用不会读取错误的值，这在最一般的情况下几乎是不可能的。您必须通过说每个渲染对象不会与自身重叠来限制它，并且您必须在渲染对象（可以与其他渲染对象重叠）之间插入内存屏障。或者您使用链表方法。

但问题在于：通过这些机制，不仅人们在着色器中实现了混合，而且还实现了与顺序无关的透明度（通过链接列表）。没有什么能阻止你现在做你想做的事。

嗯，除了表演当然没有。固定功能的混合器总是更快，因为它可以使用片段着色器操作在 parallel 中运行。混合单元是与片段着色器分开的硬件，因此您可以在执行混合操作的同时执行片段着色器操作（显然来自后面的片段，而不是正在混合的片段）。

混合硬件中的读取/修改/写入机制专门用于混合，而image_load_store是一种更通用的机制。虽然泛型可能在长期的硬件演变中具有特定性，但对于近期和近期，您可以期望固定功能混合每次都能在性能方面优于image_load_store混合。

只有在必须时才能使用它。即使是，确定你是否真的，真的需要它。

Answer 2

  

视频卡管道中是否存在一些难以实现的硬件设计问题？

是的，事实确实如此。如果可以在片段着色器中进行混合，则会引入可能的反馈循环，这确实使事情复杂化。出于性能和并行化原因，在单独的硬连线阶段进行混合。