OpenCL"；十字“-编译x64/32位指针GPU

我试图优化我的内核函数，但遇到了一点问题。首先，这可能与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位算法相当昂贵，并且会消耗大量额外的VGRP。在我的例子中，64位指针版本需要8 VGPRs以上，并且有大约140个值以上，如CodeXL所示。在我的例子中，在较慢的64位内核代码和较快的32位内核代码之间，总体性能大约差37%。除了内部指针算法，它是完全相同的。我已经尝试过对此进行优化，但即使使用普通偏移量，我仍然会遇到很多ADD_U64 IL指令，它们在ISA代码中生成两条指令：V_ADD_I32和V_ADDC_U32。当然，所有指针都需要两倍的专用内存空间（因此需要更多的VGRP）

---

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

我的备用解决方案是生成一个x86子进程，它使用共享内存并充当编译门。但如果OpenCL中的一个简单标志或（AMD特定的）设置起作用，我宁愿不这样做

---

---

请不要用“为什么”回答。我完全明白x64程序和内核为何会这样运行。

我有一些想法，但不熟悉AMD GPU OpenCL实现的细节，我只是在暗中摸索

你能通过图像传递数据吗（即使不是）？在英特尔GPU上，通过采样器提供了不同的路径，即使在64位版本中也可以避免64位算术

AMD是否有允许您阻止读写的扩展？如果编译器证明地址是统一的（标量），这会有所帮助。例如，类似（启用某些块IO）的内容。在Intel上，这有助于避免在总线上为分散/聚集传输SIMD值的地址（并节省寄存器空间）

（这是一个延伸。）为OpenCL1.2或更低版本编译有帮助吗？也就是说，指定

-cl std=CL1.2

？如果编译器知道SVM没有被使用（>=OpenCL 2.0），并且要对程序进行保守分析，以证明它没有使用指针算法，那么它可以以32位的方式进行运算，并隐式地向所有地址添加64位的相对偏移量（使GPU程序认为它使用的是32位地址）

---

同样，我对AMD的细节一无所知，但我感觉到了您在这个问题上的痛苦。

出于好奇，您使用什么作为支持AVX-512的主机CPU？这是Intel Xeon Phi 7230（骑士登陆）OpenCL内核（在GPU内）运行完全相同的代码，不管主机是64/32。您不能仅仅通过使用64位来降低37%的性能。而且数据类型完全清楚指针的大小。您确定没有为缓冲区使用一些松散定义的数据类型吗？从而使它们在64位的情况下更大？只是猜测不。当主机是x64时，则kernel使用带有64位指针的平坦内存指令（平坦加载字节）[参见ISA指令手册第9章]。当主机为x86时，内核使用缓冲内存指令（缓冲加载字节）。您可以检查CodeXL静态代码分析与“32位GPU构建”与“64位GPU构建”的差异.性能损失是由于所需的VGRP更多，最大波数减少（8到6）。当然还有更多ALU指令。感谢您的回复。1.我使用图像而不是缓冲区进行了测试。这会对性能造成严重影响，我的内核时间从0.7000微秒增加到1.1000微秒。我必须研究一下这一点，寄存器压力更小。可能这是解决方案的一部分。2.没有找到扩展或选项。3.没有效果任何其他编译器选项，无论是AMD特定的还是通用的，都没有任何效果。我向AMD提出了一个支持请求，他们对此进行了调查。我现在使用一个编译器门，生成了一个执行OpenCL编译和处理的x86进程。目前它运行得非常好。