我目前正在实施raytracer。由于光线追踪非常耗费计算量，并且无论如何我都会研究CUDA编程，因此我想知道是否有人在组合两者方面有任何经验。我无法真正确定计算模型是否匹配，我想知道期望什么。我给人的印象是，这并非天作之合，但像样的速度提升总比没有强。

解决方案

回答

当然，它可以做到，已经完成，并且是射线追踪和Cuda专家中的一个热门话题。我将从仔细阅读http://www.nvidia.com/object/cuda_home.html开始

但这基本上是一个研究问题。做得好的人会从中获得同行评审的研究论文。但是，到目前为止，最好的结果仍然是，最好的GPU / Cuda结果与CPU /多核/ SSE上的同类最佳解决方案具有相当的竞争力。因此，我认为现在使用Cuda可以加速光线追踪器还为时过早。问题在于，尽管光线跟踪"令人尴尬地平行"(如他们所说)，但不是直接映射到GPU的那种"固定输入和输出大小"问题-我们需要树，堆栈，动态数据结构等。可以使用Cuda / GPU来完成，但这很棘手。

我们对经验水平或者项目目标尚不清楚。如果这是第一个光线跟踪器，而我们只是想学习，那么我会避免使用Cuda-它会使开发时间增加10倍，并且我们可能无法获得良好的速度。如果我们是一位经验丰富的Cuda程序员，并且正在寻找一个具有挑战性的项目，并且光线跟踪绝对是一件很有趣的事情，请尝试在Cuda中进行。如果我们正在制作商业应用程序，并且希望获得具有竞争力的速度优势-好吧，这可能是个废话……我们可能会获得性能优势，但要以更困难的开发和依赖性为代价在特定的硬件上。

回顾一年，答案可能会在GPU速度，Cuda编译器开发和研究社区的经验又一代又一代之后有所不同。

回答

在CUDA中需要特别注意的一件事是，由于底层GPU硬件的结构，内核代码中的分散控制流绝对会杀死性能。 GPU通常具有海量数据并行工作负载，并具有高度一致的控制流(即，我们有数百万个像素，每个像素(或者至少其中的大片像素)将由完全相同的着色器程序进行操作，甚至采用相同的着色器程序所有分支的方向。这使它们能够进行一些硬件优化，例如对于每组32个线程仅具有单个指令高速缓存，提取单元和解码逻辑。在理想情况下(在图形中很常见)，它们可以广播在同一周期内对所有32组执行单元使用相同的指令(称为SIMD或者单指令多数据)，它们可以模拟MIMD(多指令)和SPMD(单程序)，但是在线程执行时在流式多处理器(SM)发生分歧(从分支中取出不同的代码路径)后，问题逻辑实际上逐个周期地在每个代码路径之间切换。在不同的路径上硬件利用率仅下降了32倍，有效地抵消了在CPU上通过GPU在GPU上运行所带来的任何好处，特别是考虑到与将数据集从CPU，PCIe到GPU编组相关的开销。

就是说，光线跟踪虽然在某种意义上是数据并行的，但对于适度复杂的场景，其控制流也大不相同。即使我们设法将一束彼此紧紧相邻投射的紧密间隔的光线映射到同一SM上，初始反弹所具有的数据和指令局部性也不会保持很长时间。例如，想象一下所有32个高度相干的光线从一个球面上反弹出来。弹跳后它们都将朝着完全不同的方向移动，并且很可能会撞击由不同材料，不同光照条件等制成的物体。每种材料和照明，遮挡等条件集都具有与之关联的自身指令流(以计算折射，反射，吸收等)，因此，即使在相当大的一部分上运行相同的指令流也变得非常困难SM中的线程数。使用光线跟踪代码的当前水平，此问题将GPU利用率降低了16-32倍，这可能会使应用程序无法接受性能，尤其是在实时(例如游戏)中。例如，它可能仍然优于CPU渲染农场。

在研究界中，正在出现一类新兴的MIMD或者SPMD加速器。我将它们视为软件，实时光线追踪的逻辑平台。

如果我们对所涉及的算法感兴趣并将其映射到代码，请查看POVRay。还要研究光子贴图，这是一种有趣的技术，比表示光线跟踪更接近于表示物理现实。

回答

Nvidia在今年的会议NVision上演示了CUDA中的光线示踪剂。这是他们幻灯片的链接。

http://www.nvidia.com/object/nvision08-IRT.html