Mat*_*hid 9 parallel-processing graphics haskell
图形是那些"令人尴尬的并行"问题之一.Haskell应该真的非常适合并行处理.所以我的问题是:
在渲染问题上抛出尽可能多的CPU内核的最佳方法是什么？
是否有可能让GPU完成任务？
通过"渲染问题",我指的是诸如以下问题:
每个像素的颜色都是其坐标的纯函数.
我们从现有的"输入"图像开始,并且每个"输出"像素的颜色是相应输入像素的纯函数,或者可能是这种像素的小邻域.
关于#1:这看起来很简单,但事实并非如此.有几种可能的数据结构选择来存储计算出的像素(这会影响您如何访问它,以及您可以轻松地将结果转储到磁盘或屏幕上).有多种方法可以在多个核上执行.等等.
在我看来,Data Parallel Haskell将是这类事物的理想选择.但是,上次我检查时,DPH还没有工作.就是这样.即使假设它确实有效,你可能会创建一个并行数组来保存像素,然后你必须复制像素以在屏幕上显示它们或将它们写入磁盘.
我会尝试引发每一个像素,但这可能太精细了.我可以将像素作为列表并使用其中一个并行列表策略.或者我可以使它成为一个(未装箱？)不可变数组并编写一些手动代码来启动火花.或者我可以使用显式线程和可变数组.或者我可以拥有一堆工作线程,它们通过通道将像素值传输到主线程,将结果放到正确的位置.要么...
总之,这里有很多可能性,我不确定哪个是最好的.
关于#2:显然,这类问题是GPU首先存在的全部原因.显然,GPU非常适合攻击这些类型的问题.我的问题是"从哈斯克尔那里做这件事难吗？"
如果您喜欢混合语言,那么OpenCL非常通用.虽然OpenCL语言非常接近C(所以绝对不是 Haskell),但您可以用或多或少的函数式编写内核代码,并将其视为将内核映射到空间坐标上.使用OpenCL等主流并行编程框架进行操作的一个优点是,您可以依赖于HPC和图形人员多年来在许多应用程序领域积累的不断增长的知识量.在CPU和GPU之间重新定位几乎没有任何意义,但您需要了解有关数据类型的注意事项(例如,某些GPU不支持双精度).
我写了一篇关于从Haskell调用OpenCL的教程.它取决于相对较新的OpenCL绑定(在hackage上有几个OpenCL绑定,我无法证明它们的相对质量).
有原始的OpenCL绑定,但如果你想要的东西可以帮助你运行高级代码 - 折叠和拉链和地图等 - 今天在GPU上,看看加速(CUDA后端)和GPipe(OpenGL后端,为图形工作;不幸的是,现在有点苦涩).
就表示渲染图像的结构而言,未装箱的阵列可能是您最好的选择:它最适合硬件,并且您通常不会在渲染上执行纯粹的"增量"更新.
| 归档时间： |
|
| 查看次数： |
2300 次 |
| 最近记录： |