存储缓冲区-[y][x]使用的int数组比[x][y]快3倍？

作为一个测试项目，我使用计算着色器（Vulkan）编写了Consway基本的生活游戏。基本上：

“板”存储在存储缓冲区内部的int数组中。

#define WIDTH 800
#define HEIGHT 600
#define WORKGROUP_SIZE 32

layout (local_size_x = WORKGROUP_SIZE, local_size_y = WORKGROUP_SIZE, local_size_z = 1) in;

layout(binding = 0) readonly buffer buf1 {
   int data[WIDTH][HEIGHT];
} previousBoard;

layout(binding = 1) buffer buf2 {
   int data[WIDTH][HEIGHT];
} nextBoard;

然后，计算着色器每帧更新一次（每个像素调用一次）。

我随机进行了一些更改，并且我注意到，如果使用data[y][x]（from gl_GlobalInvocationID.xy）访问阵列，我的程序比使用（至少在我的计算机（intel UHD 620）上）进行的普通访问要快3倍。data[x][y] [x] [y]为500 fps，而[y] [x]为1700 fps）。

我花了几个小时来隔离这种行为，以确保这不是副作用。我什至反汇编了Spir-v代码，但发现没有什么有趣的东西可以帮助我理解。这里是着色器的差异（带有[x] [y]和[y] [x]）：https : //www.diffchecker.com/vFlkEsQp。

我远远不了解这里会发生什么。是否有任何原因可以解释这种性能差异？

我对使用[y] [x]不太满意（或者应该？），那么我还有另一种方法可以使[x] [y]达到类似的效果吗？

几乎可以肯定，这是缓存一致性的问题。在GLSL中，an int[WIDTH][HEIGHT]是的HEIGHT1D数组的数组WIDTH int。那是主要的。因此，如果你取previousBoard.data[0][0]，你获取包括第一也许行的接下来的7层的元件，并且高速缓存行（假定32个字节）无第二行的。

您的着色器本身是在2D模型中执行的，在工作组内具有32x32的调用。如果GPU同时执行第一行的调用（0,0到31,0），则仅需要执行4次实际的内存提取。现在，当然，要对所有这些条目执行算法，您将同样需要上一行和下一行，并在右边添加一条用于存储地址的缓存行。

因此，总共需要15次内存提取。听起来可能很多。

但是，让我们检查一下GPU执行第一列调用的情况：0,0到0.31。那么，您需要多少次提取？您需要33（底部下方的行为+1），是数字的两倍。请记住：高速缓存行主要是行，而不是列。

当然，您将需要进行同样多的缓存行写操作。

就是说，列第一调用的顺序应该能够提高性能，因为第二列的调用应该获得与第一列相同的缓存行。但这假设实现将在同一时间执行第二列的调用。如果它决定用更多工作组填充其执行单元（即，它执行列0，列32，列64，列96等），那么您可能还没有缓存。

相比之下，行优先顺序保持合理的缓存一致性，而与执行顺序无关。

您无法更改GPU处理调用的顺序。因此，相反，您应该努力使算法尽可能少地关心该顺序。

首先，由于工作组之间的调用之间没有依赖关系，因此不应将其设为local_size二维。您可以使用确切的数字来找到正确的硬件值，但是16x1或32x1可能会起作用。无法保证调用顺序，但是工作组中适合波前的项目往往会一起执行。因此，这将鼓励它以行为主的方式工作，执行0,0; 1,0; 等在同一时间。

其次，请减少您使用的空间量。生命游戏的一个细胞恰好具有两种状态。但是您正在使用32位来存储这两个状态。即使您希望避免进行严重的位操作的麻烦，也可以至少将uintbe的每个字节都作为一个单独的单元。从a中提取第N个字节uint是一个非常简单的过程。

棘手的部分将是编写此类数据，因为您有不同的调用来编写单独的数据。但是，如果我们假设您在启动之前已将内存清除为零，则可以使用它atomicOr来写入值。

第三，对数据进行细化处理。也就是说，与其将其存储为行和列，不如将其存储在块中。您遇到的主要问题是因为缓存偏向第一个坐标，但是GPU执行时偏向第二个坐标。

不混乱的数据将（0，0）放在字节0，将（1，0）放在字节4，将（0，1）放在字节（4 * WIDTH）。使用swizzling时，您要做的是将四个字节0​​,0放进去；1,0; 0,1和1,1都在同一高速缓存行上。也就是说，（0，1）位于字节8，而（1，1）位于字节12。这样，如果获取（1，1），则可以确保在同一缓存行中获得所有4个值。 。

您可以使用旋转模式的大小来获得最佳性能。

除此之外，您甚至还可以使自己陷入困境gl_InvocationID。不必依赖调度的2D性质来获取调用的源位置，而是可以使调度成为一维的，并xy通过复杂矩阵来计算调用的位置。因此，调用0将是（0，0），调用1将是（1，0），调用2将是（0，1），调用3将是（1，1），依此类推。

如果您进行工作以尽可能地获得最佳的数据存储，并进行细化处理，则每个缓存行可以代表一个8x8的数据块。这意味着任何连续执行的调用组最多只需要4条缓存行值的数据（在4个块的角落）。此外，这还有助于解决编写问题，因为您可以通过原子操作将数据构建为shared变量，并在最后简单地写出值。您可以安排事情，以使来自不同工作组的两次调用都无需写入相同的值。

那将使一切几乎都独立于GPU执行。