Haskell 中的并行图形处理

Question

图形是那些“令人尴尬的并行”问题之一。 Haskell 应该非常非常适合并行处理。所以我的问题是：

1. 在渲染问题上投入尽可能多的 CPU 内核的最佳方法是什么？

2. 是否可以让 GPU 代替执行任务？

“渲染问题”是指以下问题：

• 每个像素的颜色都是其坐标的纯函数。

• 我们从现有的“输入”图像开始，每个“输出”像素的颜色都是相应输入像素的纯函数，或者可能是此类像素的一个小邻域。

---

关于#1：这看起来很简单，但实际上并非如此。有几种可能的数据结构选择来存储计算的像素（这会影响您访问它的方式，以及将结果转储到磁盘或屏幕上的难易程度）。有几种方法可以在多个内核上执行。以此类推。

在我看来，Data Parallel Haskell 将是这类事情的理想选择。但是，上次我检查时，DPH 还没有工作。就是这样。即使假设它确实有效，您也可能会创建一个并行数组来保存像素，然后您必须复制像素以将它们显示在屏幕上或将它们写入磁盘。

我会尝试激发每个像素，但这可能过于精细。我可以将像素设为列表并使用其中一种并行列表策略。或者我可以将其设为（未装箱？）不可变数组并编写一些手动代码来启动火花。或者我可以使用显式线程和可变数组。或者我可以有一堆工作线程，它们通过通道将像素值流式传输到主线程，主线程将结果放到正确的位置。或者……

总而言之，这里有很多令人惊讶的可能性，我不确定哪个是最好的。

---

关于#2：显然，这类问题是全部原因，GPU 最初存在。显然，GPU 非常适合解决这类问题。我的问题更多的是“从 Haskell 中很难做到这一点吗？”

Answer 1

如果您愿意混合多种语言，那么 OpenCL 的用途非常广泛。尽管 OpenCL 语言非常接近于 C 语言（所以绝对不是 Haskell），您可以以或多或少的函数式风格编写内核代码，并将其视为将该内核映射到空间坐标上。使用像 OpenCL 这样的主流并行编程框架做事的一个优势是，您可以依靠 HPC 和图形人员多年来在许多应用程序领域积累的不断增长的知识。 CPU 和 GPU 之间的重定向几乎没有问题，但您需要注意有关数据类型的注意事项（例如，某些 GPU 不支持双精度）。

我写了a tutorial on calling into OpenCL from Haskell。它依赖于相对较新的 OpenCL 绑定（hackage 上有几个 OpenCL 绑定，我无法证明它们的相对质量）。

Answer 2

有raw OpenCL bindings，但如果您想要一些可以帮助您在今天的 GPU 上运行高级代码（折叠、拉链和地图等）的东西，请查看accelerate（CUDA 后端）和@ 987654323@（OpenGL 后端，用于图形工作；不幸的是，现在有点烂）。

就表示渲染图像的结构而言，未装箱的数组可能是您最好的选择：它最适合硬件，而且您通常不会对渲染进行纯粹的“增量”更新。

Answer 3

在没有更多细节的情况下，对问题 1 的简短回答是：

1. 使用向量或数组处理库照常编写代码。

2. 如果该库尚未为您执行此操作，请插入适当的“par”调用或基于它的组合器，以将计算分配到多个 CPU。