当矩阵大小变得太大时，在OpenCL中写入的矩阵乘法内核不起作用

Question

我写了一个OpenCL矩阵乘法内核，它将对两个平方矩阵进行乘法运算。 内核代码是

void kernel product(global const float* A, global const float* B, global float* C, int n){
  size_t kx=get_global_id(0);
  size_t ky=get_global_id(1);
  for(int i=0; i<n; i++){
     C[n*kx+ky]=C[n*kx+ky]+A[n*kx+i]*B[n*i+ky];
  } 
}

启动内核的主机代码是

  // create buffer on the context
  int n=1000;
  cl::Buffer buffer_A(context,CL_MEM_READ_ONLY,sizeof(float)*(n*n));
  cl::Buffer buffer_B(context,CL_MEM_READ_ONLY,sizeof(float)*(n*n));
  cl::Buffer buffer_C(context,CL_MEM_READ_WRITE,sizeof(float)*(n*n));

  float* A=new float[n*n];
  float* B=new float[n*n];
  float* C=new float[n*n];

  for (int i=0; i<n; i++) {
    for (int j=0; j<n; j++) {
      A[n*i+j]=2.0;
      B[n*i+j]=2.0;
    }
  }

  //create the kernel, and set the buffer argument  
  cl::Kernel kernel(program,"product");
  kernel.setArg(0, buffer_A);
  kernel.setArg(1, buffer_B);
  kernel.setArg(2, buffer_C);
  kernel.setArg(3, n);

  //build the queue
  cl::Device device_use=all_devices[0];
  cl::CommandQueue queue(context,device_use);

  // queue manipulation: step 1: write the input buffer
  queue.enqueueWriteBuffer(buffer_A, CL_TRUE, 0, sizeof(float)*(n*n), A);
  queue.finish();
  queue.enqueueWriteBuffer(buffer_B, CL_TRUE, 0, sizeof(float)*(n*n), B);
  queue.finish(); 
  // queue manipulation: Step 2 run kernel
  queue.enqueueNDRangeKernel(kernel, cl::NullRange, cl::NDRange(n,n), cl::NullRange);
  queue.finish();

注意，A，B，C是尺寸为n * n的方形矩阵。 我试图在Macbook pro上的Intel Iris显卡上运行这个内核。 当n很小时，它很有效。 但是，当n为2000或更大时，它将给出错误的结果。 此gpu的最大全局工作大小为（512,512,512）。 所以2000 * 2000肯定不会超过最大值。 当我尝试在cpu上运行内核时，无论n多大，我总能得到正确的结果。 内核应该是正确的。 发生了什么事吗？

Answer 1

看来这里有几个问题。 我会尝试解决所有这些问题（有些问题可能已在我的评论中解决）。

OpenCL不保证全局内存的正确初始化。 有些设备可以初始化为零，但有些设备不会。 但是你的代码依赖于它，因为你在写入单个值之前从全局内存中读取： C[n*kx+ky]=C[n*kx+ky]+A[n*kx+i]*B[n*i+ky]; 。 此外，您不必要地访问全局内存。 您不应将中间结果保存在全局内存中，而应保存在快速专用内存中（请参阅改进的内核代码，该代码还处理C未初始化的事实）。

您似乎很不清楚如何处理OpenCL本地和全局工作规模，所以我将稍微谈谈这一点。

工作规模限制（您的工作规模必须满足所有这些要求）：

• CL_DEVICE_MAX_WORK_ITEM_SIZES返回每个维度的最大本地工作大小。 因此，本地工作大小的每个维度必须等于或小于相应的值。 示例： CL_DEVICE_MAX_WORK_ITEM_SIZES返回[512,512,512]，因此本地工作大小[512,2,1]是合法的，[2,512,1]也是如此。 但是[1024,1,1]是违法的，因为它违反了第一个维度的最大大小。

• CL_DEVICE_MAX_WORK_GROUP_SIZE返回设备支持的每个工作组的最大工作项数，即本地工作大小中的最大工作项数。 如果CL_DEVICE_MAX_WORK_GROUP_SIZE返回1024，[512,2,1]是合法的，[1024,1,1]也是合法的，但[1024,2,1]是非法的，因为1024 * 2> 1024。

• CL_KERNEL_WORK_GROUP_SIZE返回设备为此特定内核支持的每个工作组的最大工作项数。 这通常与CL_DEVICE_MAX_WORK_GROUP_SIZE相同，但对于使用大量私有和/或本地内存的内核，它可能会更低。

• 您的全球工作规模必须是当地工作规模的倍数。 如果矩阵的大小是[2000,2000]，这似乎是微不足道的。 您选择的全局大小相同，OpenCL会为您计算本地工作大小。 我可能会[16,16]，因为那些是2000年最大的除数，仍然产生一个低于512的局部工作尺寸。但请考虑一下：你的矩阵大小为[905,905]。 OpenCL必须选择[1,1]的本地工作大小，这是性能方面最糟糕的情况（除非你的设备足够智能以弥补这种糟糕的工作规模）。 905不能平均除以1以外的任何整数。注意我可能错了，但在阅读了很多关于OpenCL之后我怀疑这是“必须”计算工作大小的方法。 因此，为了获得高性能，工作组通常不应小于64，但在现代设备上256是非常好的价值。 因此，您应该根据这些值计算全局工作大小并调整内核，以便它可以处理比需要处理的元素更多的工作项。 示例：您需要一个大小为[16,16] = 256的工作组，但您的矩阵有1000行和列。 因此，您的全局工作大小应为[1024,1024]，并且您的内核应丢弃所有不需要的工作项。 如果您仍希望OpenCL选择本地工作大小，只需将全局工作大小更改为128或256的倍数，以避免退化本地工作组大小。

内核代码：

void kernel product(global const float* A, global const float* B, global float* C, int n)
{
    size_t kx=get_global_id(0);
    size_t ky=get_global_id(1);

    // Discard work-items that are not needed.
    if(kx >= n || ky >= n)
        return;

    float result = 0.f;

    int idxC = n*kx+ky;

    for(int i=0; i<n; ++i)
    {
        int idxA = n*kx+i;
        int idxB = n*i+ky;

        result += A[idxA]*B[idxB];
    } 

    C[idxC] = result;
}

内核代码结束

Answer 2

我和我的同事一样，在我自己的Macbook Pro上经常遇到与英特尔集成显卡相同的问题。 这可能是由于内核执行时间过长而被驱动程序杀死，以便释放GPU以执行其他任务（例如渲染到显示器）。 或者，它可能只是Apple的OpenCL实现中的一个错误（在我们的经验中一直非常不稳定）。