我一直在试图理解为什么我们仍然在较新的 3D API（如 D3D11）中使用固定功能混合模式。在 D3D10 中，移除了固定功能 Alpha Clipping，以支持使用着色器。为什么，因为它在几乎任何情况下都是一种更强大的方法。
那么为什么我们不能计算或拥有混合操作（也就是我们当前正在渲染的 RenderTarget 中的纹理样本）？视频卡流水线中是否存在一些硬件设计问题使得这难以完成？
这很有用的原因是因为您可以做一些事情，例如使折射着色器运行得更快，因为您不必在每个折射对象叠加的两个渲染目标之间来回交换。例如用于操作系统或游戏 UI 的折射窗口系统。
哪里可能是提出这样一个想法的最佳地点，因为这不是一个讨论论坛，因为我希望在 D3D12 中看到这个？或者这在 D3D11 中已经可以实现了吗？
那么为什么我们不能计算或拥有混合操作
谁说你不能？使用 shader_image_load_store（和等效的 D3D11），您几乎可以对图像做任何您想做的事情。前提是你遵守规则。最后一部分通常是人们绊倒的地方。在着色器中进行完整的读取/修改/写入，以便以后的片段着色器调用不会读取错误的值，在大多数情况下几乎是不可能的。您必须通过说每个渲染对象不会与其自身重叠来限制它，并且您必须在渲染对象之间插入内存屏障（可以与其他渲染对象重叠）。或者您使用链表方法。
但重点是：通过这些机制，人们不仅在着色器中实现了混合，而且还实现了与顺序无关的透明度（通过链表）。没有什么能阻止你现在做你想做的事。
好吧，当然除了性能。固定功能混合器总是更快，因为它可以与片段着色器操作并行运行。混合单元是与片段着色器分开的硬件，因此您可以在执行片段着色器操作的同时进行混合操作（显然是来自后来的片段，而不是正在混合的片段）。
混合硬件中的读/修改/写机制是专门为混合而设计的，而 image_load_store 是一种更通用的机制。虽然从硬件发展的长期来看，通用可能会击败特定的，但在近期和不久的将来，您可以期望固定功能混合每次都在性能方面击败 image_load_store 混合。
只有在必须时才应该使用它。甚至，决定你是否真的，真的需要它。
视频卡流水线中是否存在一些硬件设计问题使得这难以完成？
是的，事实就是这样。如果可以在片段着色器中进行混合，这将引入可能的反馈循环，这确实使事情变得复杂。出于性能和并行化的原因，混合是在单独的硬连线阶段完成的。