计算着色器同工作组内共享变量访问为何属于非一致性内存访问？

首先纠正一个常见认知误区：非一致性内存访问的可见性问题并非完全来自跨计算单元的多缓存副本，同计算单元内的硬件指令重排、存储写缓冲延迟、读写路径调度差异，同样会导致“逻辑上写发生在读之前，但读拿到旧值”的问题，和存储是否存在多副本没有必然绑定关系。

下面直接对应不同存储类型，明确同工作组内的访问规则：

共享变量（shared修饰） #

同工作组的共享变量是组内工作项专属的存储区域，硬件层面确实不会跨计算单元留存多副本，可见性规则非常明确：

• 仅使用barrier()即可满足顺序和可见性要求：barrier()会强制组内所有工作项执行到屏障点位，同时刷新共享存储的所有挂起写操作，屏障前完成的共享变量写入，在屏障后对组内所有工作项必然可见，不需要额外添加内存屏障。
• 如果不插入barrier()，哪怕你从逻辑上能推断写操作时序早于读操作，编译器优化、硬件指令重排、写缓冲未刷新都可能导致读操作拿到旧值，这和多副本无关。

非coherent修饰的全局图像/缓冲变量 #

这类资源属于全局存储范畴，哪怕同组工作项运行在同一个计算单元上，硬件和编译器都不会自动保证读写顺序与可见性：

• 仅插入barrier()完全不够，barrier()不负责全局存储路径的刷新与顺序保障，必须搭配对应作用域的内存屏障，才能保证写入的数据对后续读操作可见。
• 这类全局资源的读写可能走独立的缓存队列、或者被硬件调度重排，哪怕在同一计算单元内，没有显式内存屏障的情况下依然可能读到过期数据。

coherent修饰的全局图像/缓冲变量 #

coherent限定符的作用就是显式告知编译器和硬件：对该存储的访问不能做违反可见性的重排，需要维护访问一致性：

• 同工作组内访问这类资源时，只要用barrier()保证执行顺序，屏障前的写入在屏障后对组内所有工作项是可见的，不需要额外添加内存屏障。
• 注意如果是跨工作组访问这类资源，依然需要插入全局内存屏障，因为跨组访问会涉及不同计算单元的缓存同步问题。

针对“共享变量仅存在单个缓存，为什么仍和非一致性访问相关”的疑问：

核心原因是API规范从不会绑定特定硬件实现细节。规范不会假设所有厂商的硬件实现中，共享存储都不存在指令重排、没有写缓冲延迟，只会明确规定哪些同步操作能保证可移植的可见性。“单个工作组运行在单个计算单元上”只是当前主流硬件的实现特征，不能直接作为代码正确性的依据，严格遵循规范写出的代码才能在不同厂商硬件上稳定运行。

最后直接明确核心问题的结论：

同工作组场景下，使用barrier()保证读写时序后：

• 对共享变量、coherent修饰的图像/缓冲变量的写入，对后续读操作必然可见，不存在非一致性访问的可见性问题
• 对非coherent修饰的图像/缓冲变量，仅靠barrier()不保证可见，必须搭配对应内存屏障

内容的提问来源于stack exchange，提问作者wangsy