我的 OpenCL 内核在较快的硬件上速度较慢。但是为什么呢？

Question

当我完成多核编程课程的项目编码时，我发现了一些非常奇怪的事情，我想与您讨论。

我们被要求创建任何能够在多核平台编程方面显示出显着改进的程序。我决定尝试在 GPU 上编写一些代码来尝试 OpenCL。我选择了矩阵卷积问题，因为我非常熟悉它（我之前已经使用 open_mpi 对其进行了并行化，对于大图像来说具有很大的加速）。

所以在这里，我选择一个大的 GIF 文件 (2.5 MB) [2816X2112]，然后运行顺序版本（原始代码），平均时间为 15.3 秒。

然后，我运行我刚刚在 MBP 集成 GeForce 9400M 上编写的新 OpenCL 版本，平均时间为 1.26 秒。到目前为止，一切顺利，加速了 12 倍！

但现在我进入节能面板打开“图形性能模式”，该模式会关闭 GeForce 9400M 并打开我系统上的 Geforce 9600M GT。苹果称该卡的速度是集成卡的两倍。

你猜怎么着，我使用强大显卡的平均时间是 3.2 秒……我的 9600M GT 似乎比 9400M 慢两倍多……

对于那些倾向于 OpenCL 的人，我将所有数据复制到远程缓冲区在开始之前，因此实际计算不需要往返主内存。另外，我让 OpenCL 确定最佳本地工作大小，因为我读到他们在计算该参数方面做了相当好的实现。

有人有线索吗？

编辑：此处包含 makefile 的完整源代码 http://www.mathieusavard.info/volving.zip

cd gimage
make
cd ../clconvolute
make
put a large input.gif in clconvolute and run it to see results

Answer 1

9400M 集成到您的内存控制器，而 9600M GT 是一个独立卡，通过 PCI-e 总线连接到您的内存控制器。这意味着当您将内存转移到 9400M 时，它只是将其分配到系统 RAM 中。另一方面，9600M 通过 PCI-e 将数据发送到卡上的专用图形内存。这种传输使您的基准测试看起来更慢。

如果您想比较两个显卡的性能，您应该使用 OpenCL 分析函数而不是当前使用的时钟函数。

cl_int clGetEventProfilingInfo（cl_event 事件，cl_profiling_info param_name，
size_t param_value_size, void *param_value, size_t *param_value_size_ret)

将您将内核排队时创建的事件传递给函数，并将第二个参数的 CL_PROFILING_COMMAND_START 传递给它，以获取内核的起点（以纳秒为单位）和 CL_PROFILING_COMMAND_END获取内核的终点。确保在内核执行完成后使用此命令（事件会保留其值，直到超出范围。）您还可以通过将此函数应用于事件来获取将数据传输到设备所花费的时间来自缓冲区的排队。这是一个示例：

        TRACE("Invoking the Kernel")
    cl::vector<cl::Event> matMultiplyEvent;
    cl::NDRange gIndex(32,64);
    cl::NDRange lIndex(16,16);

    err = queueList["GPU"]->enqueueNDRangeKernel(
                                                 matrixMultiplicationKernel, 
                                                 NULL, 
                                                 gIndex, 
                                                 lIndex, 
                                                 &bufferEvent,
                                                 matMultiplyEvent);
    checkErr(err, "Invoke Kernel");


    TRACE("Reading device data into array");
    err = queueList["GPU"]->enqueueReadBuffer(thirdBuff, 
                                              CL_TRUE,
                                              0,
                                              (matSize)*sizeof(float),
                                              testC,
                                              &matMultiplyEvent,
                                              bufferEvent);
    checkErr(err, "Read Buffer");
    matMultiplyEvent[0].wait();
    for (int i = 0; i < matSize; i++) {
        if (i%64 == 0) {
            std::cout << "\n";
        }
        std::cout << testC[i] << "\t";
    }
    long transferBackStart = bufferEvent[0].getProfilingInfo<CL_PROFILING_COMMAND_START>();
    long transferBackEnd = bufferEvent[0].getProfilingInfo<CL_PROFILING_COMMAND_END>();
    double transferBackSeconds = 1.0e-9 * (double)(transferBackEnd- transferBackStart);

    long matrixStart = matMultiplyEvent[0].getProfilingInfo<CL_PROFILING_COMMAND_START>();
    long matrixEnd = matMultiplyEvent[0].getProfilingInfo<CL_PROFILING_COMMAND_END>();
    double dSeconds = 1.0e-9 * (double)(matrixEnd - matrixStart);

此示例使用 C++ 包装器，但概念应该是相同的。

希望这有帮助。

Answer 2

我得到了相同的结果，但我不确定为什么。我的内核涉及非常少的复制（我为所有内核调用提供所有需要的数据，并且仅返回 512x512 图像）。它是一个光线跟踪器，因此内核工作远远超过了复制回来的工作（400+ms 到 10ms）。尽管如此，9600M GT 仍慢了约 1.5 倍至 2 倍。

根据 nVidia 的列表，9600M GT 应该有 32 个 SP（是 9400M 数量的两倍）。估计它的时钟也更高。

9600M GT 在某些情况下确实看起来更快，例如游戏。请参阅这些链接：
http://www.videocardbenchmark.net/video_lookup.php?cpu= GeForce+9600M+GT
http://www.videocardbenchmark.net/video_lookup.php?cpu= GeForce+9600M+GT

根据ars 技术：

此外，早期测试揭示了有关 Snow Leopard 实现的一个有趣的花絮。尽管 Snow Leopard 似乎无法为使用 NVIDIA GeForce 9400M 芯片组的机器启用双 GPU 或即时 GPU 切换（这是 Leopard 遗留下来的限制），但操作系统似乎可以同时将两者用作 OpenCL 资源。因此，即使您在 MacBook Pro 上启用了 9600M GT，如果在应用程序中遇到 OpenCL 代码，Snow Leopard 也可以将该代码发送给 9400M 中几乎处于休眠状态的 16 个 GPU 核心进行处理。但反之则不然，当运行仅启用 9400M 的 MacBook Pro 时，9600M GT 会完全关闭以节省电量，并且不能用作 OpenCL 资源。

这似乎与我们所看到的相反。另外，我一次只在一台设备上显式设置 CL 上下文。

ars 论坛中有一些建议认为 9600M GT也不支持双打，这可以解释这个问题。我可能会尝试编写一个综合基准来测试这个假设。

Answer 3

当我在 MacBook 上测试 OpenCL 时，我遇到了同样的问题。我相信这是因为 GeForce 9400M 的主内存总线速度比 Geforce 9600M GT 更高。因此，尽管 Geforce 9600M GT 的性能比 GeForce 9400M 强大得多，但将内存复制到 GPU 所需的时间太长，无法看出更强大的 GPU 对您的情况带来的好处。这也可能是由于工人组规模不适当造成的。

我还发现这个网站对我的 OpenCL 体验非常有帮助。

http://www.macresearch.org/opencl

Answer 4

性能并不是 GeForce 9400M 和 Geforce 9600M GT 之间的唯一区别。一大问题是它是一个离散 GPU。随之而来的是一系列差异，其中以下因素可能会产生影响：

• 驱动程序批量处理更多命令的趋势
• 内存并不统一。 GPU一般只访问自己的内存，驱动程序通过PCI-E总线来回移动内存。

我确信我错过了一些...

这里有一些您可以尝试的想法：

• 避免调用 clFinish。在内存加载和执行之间调用它的方式会迫使驱动程序执行不必要的工作。它会导致 GPU 停顿。
• 分析您的代码以查看什么花费了时间。我还不知道对 CL 性能分析的支持，但是通过您的 clFinish 调用，它可以通过简单地测量 CPU 端来为您提供一阶估计。请注意，通常很难区分什么是延迟造成的，什么是吞吐量造成的。

Answer 5

我是 OpenCL 的新手，所以我可能有点天真，但我怀疑您需要进入节能面板来切换 OpenCL 计算设备。我相信您在代码中设置 OpenCL 上下文时选择了设备。

我的假设：1) 当您在不首先禁用集成 GPU 的情况下运行代码时，OpenCL 会选择您的独立 GPU 作为计算设备。您的代码在（快速）独立 GPU 上运行。 2) 当您首先禁用集成 GPU 时，您会将运行 OS X GUI 的负载强制转移到独立卡上。当您运行代码时，它会在独立 GPU 上运行，但会与 GUI 争夺资源。

这个答案是在问题提出 11 个月后给出的，但希望它对某人有用......