OpenCL "cross"-编译 x64/32 位指针 GPU

Question

我正在尝试优化我的内核功能，但遇到了一些问题。首先，这可能与 Radeon R9(夏威夷)相关，但其他 GPU 设备也应该发生这种情况。

<小时/>

对于主机，我有两个平台选择。作为 x86 程序编译并运行，或者作为 x64 程序运行。根据我选择的平台，我得到不同的编译内核。一种使用 32 位指针和指针算术，另一种使用 64 位指针。生成的 IL 代码显示了差异，第一种情况是

prog kernel &__OpenCL_execute_kernel(
  kernarg_u32 %_.global_offset_0,
  kernarg_u32 %_.global_offset_1,  
  ...

在第二种情况下是:

prog kernel &__OpenCL_execute_kernel(
  kernarg_u64 %_.global_offset_0,
  kernarg_u64 %_.global_offset_1,  
  ...

GPU 上的 64 位算术相当昂贵，并且消耗大量额外的 VGPR。就我而言，64 位指针版本需要多 8 个 VGPR，并且多大约 140 个 VALUInst，如 CodeXL 所示。在我的例子中，较慢的 64 位内核代码和较快的 32 位内核代码的总体性能大约差 37%。除了内部指针运算之外，这是完全相同的。我尝试对此进行优化，但即使使用简单的偏移量，我仍然遇到很多 ADD_U64 IL 指令，这些指令在 ISA 代码中生成两条指令:V_ADD_I32 和 V_ADDC_U32。当然，所有指针都需要双倍私有(private)内存空间(因此需要更多 VGPR)。

<小时/>

现在我的问题是:有没有办法“交叉”编译 OpenCL 内核，以便 x64 程序可以创建 32 位指针内核？我不需要解决GPU 中有那么多内存，因此寻址小于 4 GiB 的内存空间就可以了。由于我的主机还使用所有 32 个 zmm 寄存器执行 AVX-512 指令(仅在 x64 模式下可用)，因此无法选择 x86 程序。这使得整个情况有点具有挑战性。

嗯，我的后备解决方案是生成一个使用共享内存并充当编译门的 x86 子进程。但如果 OpenCL 中的简单标志或(AMD 特定)设置可以解决问题，我宁愿不这样做。

<小时/>

请不要以“为什么”的方式回复。我完全明白为什么 x64 程序和内核会这样。

Answer 1

我有几个想法，但由于不熟悉 AMD GPU OpenCL 实现的内部原理，所以我在黑暗中摸索。

1. 您可以通过图像传递数据吗(即使不是)？在 Intel GPU 上，通过采样器提供了不同的路径，即使在 64 位版本中也可以避免 64 位算术。

2. AMD 是否有允许阻止读取和写入的扩展？如果编译器证明地址是统一的(标量)，这会有所帮助。例如。类似 Intel Subgroups (启用一些 block IO)。在 Intel 上，这有助于避免在总线上传输 SIMD 的地址以进行分散/聚集(并且也节省寄存器空间)。

3. (这是一个延伸。)针对 OpenCL 1.2 或更低版本进行编译有帮助吗？即指定-cl-std=CL1.2？如果编译器知道没有使用 SVM(>=OpenCL 2.0)并且要对程序运行保守分析以证明它没有对指针算术进行疯狂的操作，那么它可以在 32 位中进行算术并隐式添加相对于所有地址的 64 位相对偏移量(使 GPU 程序认为它正在使用 32 位地址)。

再说一遍，我对 AMD 的具体情况一无所知，但我能感受到您对这个问题的痛苦。