opencl中的共享内存与纹理内存答案

【问题标题】：shared memory vs texture memory in openclopencl中的共享内存与纹理内存
【发布时间】：2015-07-15 17:34:59
【问题描述】：

我正在 Opencl 中编写去隔行扫描代码。我正在使用本地内存中的 read_imageui() API 读取像素。

根据我的理解，当我们使用此 API 读取像素时，我们正在从纹理内存中读取。我怀疑首先在共享内存中使用像素是否会帮助我获得任何速度，因为纹理内存已经充当缓存并提供对数据的快速访问。

谁能澄清我的疑问？

【问题讨论】：

【解决方案1】：

如果您可以在使用 read_imageui 读取数据后将所有数据放入私有内存中，那么您绝对应该这样做。请记住，如果您的内核编译 SIMD16，则每个工作项只有 256 个字节的私有内存；如果它编译 SIMD8，则每个工作项只有 512 个字节。
是否应该使用本地内存实际上取决于访问模式。事实上，Samplers 有自己的 L1 和 L2 缓存，所以如果你的数据访问总是命中缓存，你应该没问题。请记住，本地内存是存储的，因此您有 16 个存储库，一次可以从中获取 4 个字节，这意味着如果您在一个硬件线程（通常为 16 或 8其中）。因此，您可能会遇到这样一种情况，您最好先将图像数据读入本地内存，然后以有序的方式访问本地内存。这方面的一个很好的例子是像 SIFT 或 SURF 这样的算法，您以这样一种方式访问图像，即采样器缓存确实没有多大帮助（您仍然可以获得采样器插值的好处），但是您将所有这些数据放在本地内存中并重复访问它以相当规则的模式。

【讨论】：

【解决方案2】：

总的来说，这是真的。然而，即使是从纹理缓存读取可能也比从共享本地内存中读取要慢，因此对于从相邻位置进行许多重叠读取的算法来说，使用共享本地内存仍然可以在一定程度上受益。但是，这会使内核变得更加复杂，因此在许多情况下（当然在算法开发期间）只依赖缓存的纹理读取。

【讨论】：