OpenCL image2d和image3d内存布局

将存储在主机内存中的2d图像传输到OpenCL时，它是如何读取值的？行主还是列主？让我们假设你是少校

index = row*NUM_COLS + col

存储在主机内存中的3d图像如何？我认为这是一个2D图像堆栈（假定为行主图像）。然后，OpenCL中限制（NUM_ROWS、NUM_COLS、NUM_SLICES）的像素（row、col、slice）位于：

index = slice*NUM_ROWS*NUM_COLS + row*NUM_COLS + col

但是，根据公式，3d行主索引应为：

index = slice + NUM_SLICES*(col + NUM_COLS*row) 
      = row*NUM_COLS*NUM_SLICES + col*NUM_SLICES + slices

根据同一篇文章，主要订购渠道应为：

index = row + NUM_ROWS*(col + NUM_COLS*slice)
      = slice*NUM_ROWS*NUM_COLS + col*NUM_ROWS + row

所有这些似乎都不符合OpenCL在3d案例中所做的

所以我想我真的有两个问题

如何将2d和3d图像传输到OpenCL的内存布局

为什么OpenCL在3d环境中选择了非标准内存布局

编辑

我认为维基百科的文章是一个通用的布局方案。“行”或“列”是二级标签词。无论您处理的元组（行、列、切片）限制为（NUM_行、NUM_列、NUM_切片）还是（x、y、z）（宽度、高度、深度），只要它们是一致的，就无关紧要。它只是告诉你哪个维度在内存中是连续的。在“行主维度”中，是最后一个维度-相邻的z值，在“列主维度”中是第一个维度-x

因此，我再次认为x、y、z三维图像索引的“行主”布局应该是：

index = z + DEPTH * (y + HEIGHT * x) = x * HEIGHT * DEPTH + y * HEIGHT + z

---

事实并非如此。但是，我想你可以选择你想要的任何方案。

首先，你对OpenCL布局的假设是正确的。OpenCL确实使用了您描述的布局，并且您为2D和3D案例提供的公式是正确的，一个组件接一个组件，一个像素接一个像素，一行接一行，一片接一片。我（有OpenGL背景）考虑这个很好的标准。

然而，这里有一点命名混乱，因为row-major通常的意思是维基百科所说的，第一个维度的变化频率最低，最后一个维度是连续的。然而，对于图像，行实际上不是第一维，而是y维，列是x维。因此，尽管OpenCL（至少在2D中）使用文字“行主”布局（因为行的变化不太频繁），但它通常被视为（在维基百科使用的术语中）而不是列主，因为第一个维度（x）是连续的。这可以很好地转化为3D，其中最后一个维度（z）的变化频率最低。所以你把维基百科搞错了，它实际上说的是一般的专栏专业（扩展到3D）是

考虑到

x=col

和

y=row

，这确实是

index = slice*NUM_ROWS*NUM_COLS + row*NUM_COLS + col

这正是OpenCL所使用的。因此，要回答您的实际问题：

就像你在问题的第一部分解释的那样

因为你把维基百科搞错了，混淆了基于矩阵的

（行，列）

-索引和基于图像的

（x，y）

-索引和OpenCL使用的对应于维基百科通常称之为列主

---

编辑：这种基于索引的寻址（如矩阵）和基于坐标的寻址（如图像）的混淆是造成混淆的常见原因。例如，在OpenCV（一个著名的图像处理库）中，图像以矩阵表示和寻址，因此类似于

（行，列）

，对于实际图像，这意味着

（y，x）

，感谢您的确认。我在标准中找不到关键词“row major”。

index = slice*NUM_ROWS*NUM_COLS + row*NUM_COLS + col