OpenCL（内核中）可调用 SVD kernel 代码？

Question

我正在研究如何在 GPU 上卸载一些相当繁重的计算。 虽然在我的机器上我有一个NVIDIA RTX GPU ，但我想避免使用 CUDA 来开发在其他 GPU 上也可以移植的东西（至少在它的核心）。

因而选择了OpenCL。

现在，我目前最大的担忧是，在适合卸载的内核中，我大量使用了LAPACK SVD实现。 但是，在 OpenCL 中，kernel 代码不能：

1. 链接到外部库。 有一个使用clEnqueueNativeKernel()的“workaraound”，但这似乎不适用于这种情况（在 kernel 本身内调用）（更不用说这不是很便携，因为它需要设备支持CL_EXEC_NATIVE_KERNEL功能）；
2. 接受 function 指针作为 kernel arguments。

那么，有谁知道 OpenCL kernel SVD 开源实现的存在，然后可以在父 OpenCL kernel 中调用它？

我用谷歌搜索，找到了 GPU 卸载的几个 SVD 库/实现，但我看不到如何将它们“嵌入”到 OpenCL kernel 中（它们似乎都是从主机代码启动的实现）。 如果我错了，请纠正我。 任何帮助都非常受欢迎。

Answer 1

仅使用原子函数在主机和 kernel 之间实现事件回调 API，这样：

void callExternalLib(__global int * ptr)
{
     atomic_inc(ptr,1);

     // if clWaitForEvents not supported in kernel
     while(atomic_inc(ptr,0) == 1)
     {
           // somehow wait until signal 0 is received
     }
     dynamicParallelismLaunchRestOfTheAlgorithm();
}

__kernel void test(__global int * communication, __global int * data)
{
   callExternalLib(communication);
}

// at the same time on host with a dedicated event-thread:
// if opencl-events do not work between gpu and host
while(ptr.load()==0)
{
   std::this_thread::yield();
}
if(ptr.load()==CALL_SVD)
{
    clMagmaCopyToGraphicsCard(); // not required if buffer handle can be shared
    clMagmaComputeOnGPU();
    clMagmaCopyToHost(); // not required if buffer handle can be shared
    copyToYourOpenCLBuffer(); // not required if buffer handle can be shared
    ptr--; // inform kernel's threads that clmagma function has been called
}

来自https://man.opencl.org/atomic_store.html ：

使用细粒度系统 SVM，共享发生在主机 memory 中任何位置的单个加载和存储的粒度上。Memory 一致性始终在同步点得到保证，但为了获得对一致性的更精细控制，可以使用 OpenCL 原子函数来确保一个执行单元对单个数据值的更新对其他执行单元是可见的。 特别是，当主机线程需要对与一个或多个 OpenCL 设备共享的 memory 的一致性进行精细控制时，它必须使用与 C11 原子操作兼容的原子和栅栏操作。

不知道你的显卡/驱动是否支持这个。 并非所有 GPU 都完全支持 OpenCL 2.0。

要使主机端库直接在 GPU 上运行，您需要手动转换一些部分：

• 拨款
• 数学函数的实现，如 sqrt、cos、sin、exp
• 内在函数（GPU 不能运行 AVX 也许除了 Intel 的 XeonPhi？）
• 结构对齐，arrays
• 对其他库的依赖
• 甚至可以调用约定？ （有些 GPU 没有真正的调用堆栈）

如果工作繁重，仅原子触发的 GPU 库调用的延迟应该可以忽略不计，但当 GPU 端需要每个时钟周期时，它就不适合了。 所以它不适合处理小矩阵。