1

glBindImageTexture(), access可以是GL_READ_ONLY, GL_WRITE_ONLY, 或GL_READ_WRITE. 我假设这些应该与GLSL 中图像单元(例如or )上的readonlyandwriteonly限定符匹配。image2DimageBuffer

设置只读或只写(2013,NVIDIA 319.49 驱动程序)时,我没有注意到任何区别。当然,我可能不会做任何会导致减速的事情,因此看不到任何改进。当前的 GL 实现也可以简单地忽略这些限定符。

  • 在什么情况下 GL 实现可以使用只读/只写,为什么它们存在?

我想到了缓存一致性,但coherent/volatile限定词是否已经涵盖了这一点?我用过这些,它们似乎有效。

  • 有没有人在使用只读/只写时经历过性能或结果的差异,它们有多重要?

如果已经有好几年了,不要害怕回复,我很想知道,我相信其他人也是。

4

2 回答 2

2

它只告诉驱动程序应该如何使用内存的提示。是否进行优化取决于驱动程序。我没有看到 NVidia 驱动程序有任何区别。有一件事是肯定的,如果你写入只读图像,结果是不确定的。读取只写图像也是如此。但是即使它对今天的驱动程序没有影响,您仍然应该将它们与您实际使用这些图像所做的事情连贯地使用它们:未来的驱动程序可能会使用这些提示来优化内存访问。

于 2013-10-29T15:24:32.427 回答
2

看,问题是这些访问策略没有实际执行。OpenGL 故意将写入只读图像的行为未定义,原因将在下面解释。除其他外,这允许在实现结束时为许多不同的优化策略使用只读属性有很大的灵活性(将其视为提示而不是严格的规则)。因为行为是未定义的,你是对的,它们可以被实现忽略,但不应被应用程序开发人员忽略。调用未定义的行为是一个定时炸弹。

为此,当您尝试将某些内容存储在只读图像中时,GLSL(或一般的着色器)中不存在发出错误的机制,这使得执行此策略变得更加困难。您可能希望的最好结果是在编译时进行某种静态分析,然后在运行时根据绑定图像纹理的访问策略进行验证。这并不是说它将来可能不会发生,但目前不存在这样的特征。GLSL 提供的唯一东西是编译时保证readonly变量不能与imageStore (...)着色器一起使用。简而言之,GLSL 限定符是在编译时强制执行的,但绑定图像的访问策略不在运行时。

您没有看到任何性能改进这一事实并不奇怪。这是一个相当新的功能,在驱动程序对访问策略做任何深刻的事情之前,你必须给它几年时间。提供提示并没有什么坏处,只要您自己不违反它。

于 2013-10-29T21:56:27.657 回答