基本 GPU 应用，整数计算

Question

长话短说，我已经做了几个交互软件的原型。我现在使用 pygame（python sdl 包装器），一切都在 CPU 上完成。我现在开始将它移植到 C 中，同时寻找现有的可能性来使用一些 GPU 功能来使 CPU 摆脱冗余操作。但是，我找不到一个好的“指南”，我应该在我的情况下选择哪些确切的技术/工具。我刚刚阅读了大量的文档，它很快耗尽了我的精神力量。我不确定这是否可能，所以我很困惑。
在这里，我对我开发的典型应用程序骨架做了一个非常粗略的草图，但考虑到它现在使用 GPU（注意，我对 GPU 编程的实践知识几乎为零）。仍然重要的是必须准确保留数据类型和功能。这里是：

所以 F(A,R,P) 是一些自定义函数，例如元素替换、重复等。函数在程序生命周期中可能是恒定的，矩形的形状一般不等于 A 形状，所以它不在-地方计算。所以它们只是用我的函数生成的。 F的例子：重复A的行和列；用替换表中的值替换值；将一些图块组合成单个数组； A 值上的任何数学函数等。如上所述，所有这些都可以在 CPU 上轻松完成，但应用程序必须非常流畅。顺便说一句，在纯 Python 中，在添加了几个基于 numpy 数组的视觉功能后，它变得无法使用。 Cython 有助于制作快速的自定义函数，但源代码已经有点像沙拉了。

问题：

• 此架构是否反映了某些（标准）技术/dev.tools？

• CUDA 是我想要的吗？如果是，一些与我的应用程序结构一致的链接/示例会很棒。

我知道，这是个大问题，所以如果有帮助，我会提供更多细节。

---

更新

这是我的位图编辑器原型的两个典型计算的具体示例。因此编辑器使用索引，并且数据包括具有相应位掩码的图层。我可以确定图层的大小和蒙版的大小与图层的大小相同，例如，所有图层的大小都相同（1024^2 像素 = 4 MB，对于 32 位值）。我的调色板是 1024 个元素（32 bpp 格式为 4 KB）。
考虑一下我现在想做两件事：

第 1 步。我想将所有图层合二为一。假设 A1 是默认图层（背景），图层“A2”和“A3”具有蒙版“m2”和“m3”。在python中我会写：

from numpy import logical_not
...
Result = (A1 * logical_not(m2) + A2 * m2) * logical_not(m3) + A3 * m3

由于数据是独立的，我相信它必须与并行块的数量成正比。

第 2 步。现在我有一个数组，想用一些调色板“着色”它，所以它将是我的查找表。正如我现在所看到的，同时读取查找表元素存在问题。

但我的想法是，也许可以为所有块复制调色板，这样每个块都可以读取自己的调色板？像这样：

Answer 1

当您的代码高度并行（即处理阶段之间的数据依赖性很小或没有数据依赖性）时，您可以选择 CUDA（对同步进行更细粒度的控制）或 OpenCL（非常相似且可移植的类似 OpenGL 的 API 与用于内核处理的 GPU）。我们所做的大部分加速工作都发生在 OpenCL 中，它与 OpenGL 和 DirectX 具有出色的互操作性，但我们也有与 CUDA 相同的设置。 CUDA 和 OpenCL 之间的一大区别是，在 CUDA 中，您可以编译内核一次并在应用程序中延迟加载（和/或链接）它们，而在 OpenCL 中，编译器与 OpenCL 驱动程序堆栈配合得很好，以确保内核在应用程序启动。

如果您使用 Microsoft Visual Studio，则经常被忽视的一个替代方案是 C++AMP，它是一种 C++ 语法友好且直观的 API，适用于那些不想深入研究 OpenCL/CUDA API 的逻辑曲折的人.这里最大的优势是，如果系统中没有 GPU，代码也可以工作，但是你没有那么多选项来调整性能。尽管如此，在很多情况下，这是一种快速有效的方式来编写证明您的概念代码并稍后在 CUDA 或 OpenCL 中重新实现位和部分。

只有当您遇到同步问题和大量数据依赖项时，OpenMP 和线程构建块才是不错的选择。使用工作线程的本机线程也是一种可行的解决方案，但前提是您对如何在不同进程之间设置同步点有一个很好的了解，这样线程在争夺优先级时不会互相饿死。要做到这一点要困难得多，并且必须使用 Parallel Studio 等工具。但是，如果您正在编写 GPU 代码，那么 NVida NSight 也是如此。

附录：

一个名为 Quasar (http://quasar.ugent.be/blog/) 的新平台正在开发中，它使您能够以与 Matlab 非常相似的语法编写数学问题，但完全支持 c/c++/c# 或 java 集成，并且可以跨- 将您的“内核”代码编译（LLVM、CLANG）到任何底层硬件配置。它生成 CUDA ptx 文件，或在 openCL 上运行，甚至在您的 CPU 上使用 TBB 或它们的混合物。使用一些名字，您可以修饰算法，以便底层编译器可以推断类型（您也可以显式使用严格类型），因此您可以将类型繁重的东西完全留给编译器。公平地说，在撰写本文时，该系统仍处于 w.i.p.第一个 OpenCL 编译程序正在测试中，但最重要的好处是快速原型设计，与优化的 cuda 相比具有几乎相同的性能。

Answer 2

您要做的是使用高频分派非常快速地将值发送到 GPU，然后显示一个函数的结果，该函数基本上是纹理查找和一些参数。

我想说这个问题只有在满足两个条件的情况下才值得在 GPU 上解决：

1. A[] 的大小经过优化，使传输时间变得无关紧要（看，http://blog.theincredibleholk.org/blog/2012/11/29/a-look-at-gpu-memory-transfer/）。

2. 查找表不是太大和/或查找值的组织方式可以最大限度地利用缓存，一般而言，GPU 上的随机查找可能会很慢，理想情况下您可以预加载A[] 缓冲区的每个元素在共享内存缓冲区中的 R[] 值。

如果您当时可以肯定地回答这两个问题，然后才考虑尝试使用 GPU 来解决您的问题，否则这两个因素将压倒 GPU 可以为您提供的计算速度。

您可以看看的另一件事是尽可能重叠传输和计算时间，以尽可能隐藏 CPU->GPU 数据的缓慢传输速率。

关于您的F(A, R, P) 函数，您需要确保您不需要知道F(A, R, P)[0] 的值才能知道F(A, R, P)[1] 的值是什么，因为如果您知道，那么您需要重写@987654329 @ 使用一些并行化技术来解决这个问题。如果您的 F() 函数数量有限，则可以通过编写每个 F() 函数的并行版本供 GPU 使用来解决此问题，但如果 F() 是用户定义的，那么您的问题就会变得有点棘手。

我希望这些信息足以对您是否应该使用 GPU 来解决您的问题做出明智的猜测。

编辑

阅读您的编辑后，我会说是的。调色板可以放入共享内存（请参阅GPU shared memory size is very small - what can I do about it?），这非常快，如果您有多个调色板，则可以容纳 16KB（大多数卡上共享内存的大小）/每个调色板 4KB = 每个线程块 4 个调色板.

最后一个警告，整数运算在 GPU 上并不是最快的，如果需要，请在实现算法后考虑使用浮点数，并且它可以作为一种廉价的优化。

Answer 3

OpenCL/CUDA 之间没有太大区别，因此请选择更适合您的。请记住，CUDA 将限制您使用 NVidia GPU。

如果我正确理解您的问题，内核（在 GPU 上执行的函数）应该很简单。它应该遵循这个伪代码：

kernel main(shared A, shared outA, const struct R, const struct P, const int maxOut, const int sizeA)
  int index := getIndex() // get offset in input array
  if(sizeA >= index) return // GPU often works better when n of threads is 2^n
  int outIndex := index*maxOut // to get offset in output array
  outA[outIndex] := F(A[index], R, P)
end

函数 F 应该是内联的，你可以使用 switch 或 if 来实现不同的函数。由于 F 的输出大小未知，因此您必须使用更多内存。每个内核实例必须知道正确的内存写入和读取的位置，因此必须有一些最大大小（如果没有，那么这一切都是无用的，您必须使用 CPU！）。如果不同的大小是稀疏的，那么我会在将数组返回 RAM 并用 CPU 计算这几个后使用类似计算这些不同大小的方法，同时用一些零或指示值填充 A。

数组的大小显然是 length(A) * maxOut = length(outA)。

我忘了提到，如果在大多数情况下（相同的源代码）F 的执行不一样，那么 GPU 会序列化它。 GPU 多处理器有几个核心连接到同一个指令缓存中，因此它必须对代码进行序列化，这对所有核心都不一样！对于此类问题，OpenMP 或线程是更好的选择！