使用CUDA进行光线跟踪

Question

我目前正在实施光线跟踪器。由于光线追踪的计算量非常大，而且我将继续研究CUDA编程，所以我想知道是否有人将这两者结合起来。我无法确定计算模型是否匹配，我想知道期望的结果。我得到的印象是，这不完全是在天堂制造的，但体面的速度增加总比没有好。

Answer 1

有一件事是非常谨慎的CUDA是，在你的内核代码发散的控制流绝对KILLS性能，由于底层GPU硬件的结构。 GPU通常具有高度一致的控制流程的大量数据并行工作负载（即，您拥有几百万像素，其中每个像素（或至少大部分像素）将由相同的着色器程序操作，即使采用相同的着色器程序通过所有分支的方向相同，这使得它们可以进行一些硬件优化，例如每个32个线程组只有一个指令缓存，取单元和解码逻辑，在图形中常见的理想情况下，它们可以在相同的周期内向所有32套执行单元广播相同的指令（这就是所谓的SIMD或单指令多数据），它们可以模拟 MIMD（多指令）和SPMD（单指令程序） ，但是当流式多处理器（SM）中的线程发散时（将不同的代码路径带出分支），问题逻辑实际上在每个代码路径之间切换一个循环的基础。你可以想象，在最坏的情况下，所有的线程都在不同的路径上，你的硬件利用率只降低了32倍，有效地消除了你在GPU上运行在GPU上的好处，特别是考虑到与通过PCIe将CPU中的数据集编组到GPU中相关的开销。也就是说，光线追踪虽然在某种意义上是数据并行的，但即使是适度复杂的场景，其控制流程也有很大的差异。即使你设法将一串紧密排列的光线映射到彼此相邻的同一个SM上，你在初始反弹中获得的数据和指令位置也不会持续很长时间。例如，想象所有32条高度一致的光线从一个球体反射回来。在这次反弹之后，他们将会朝不同的方向前进，并且很可能会碰到由不同材料制成的物体，以及不同的照明条件，等等。每种材料和照明，阻塞等条件的一组具有与其相关联（以计算折射，反射，吸收等等）它自己的指令流，因此它变得相当难以在甚至显著分数运行相同的指令流SM中的线程数。这个问题，与本领域中光线跟踪代码的当前状态，通过16-32的一个因素，这可能使你的应用程序的性能不可接受的，尤其是如果它的实时（例如，游戏）降低你GPU利用率。对于例如CPU，它仍可能优于CPU。一个渲染农场。

有一类新兴MIMD或SPMD加速器的研究团体正在看着现在。我会将这些视为软件的实时光线追踪的逻辑平台。

如果您有兴趣参与，并将它们映射到代码的算法，检查出的povray。同样看光子映射，这是一个有趣的技术，甚至比光线追踪更接近表示物理现实。

Answer 2

它当然可以完成，已经完成，并且是目前光线跟踪和Cuda大师中的热门话题。我会开始仔细阅读http://www.nvidia.com/object/cuda_home.html

但它基本上是一个研究问题。做得好的人会从中获得同行评议的研究论文。但以及此时仍然意味着最佳GPU/CUDA结果与CPU /多核/ SSE上的最佳解决方案大致相当。所以我认为，假设使用Cuda将加速射线追踪器有点早。问题是，虽然光线追踪是“令人尴尬的并行”（正如他们所说），但它不是那种直接映射到GPU的“固定输入和输出大小”问题 - 您需要树，堆栈，动态数据结构等它可以用Cuda/GPU来完成，但这很棘手。

你的问题不清楚你的经验水平或你的项目的目标。如果这是你的第一个射线追踪器，而你只是想学习，我会避免Cuda--它会让你延长10倍的发展速度，而且你可能无法获得好的速度。如果您是一位经验丰富的Cuda程序员，并且正在寻找一个具有挑战性的项目，并且光线追踪只是一件有趣的事情，不妨尝试在Cuda中进行尝试。如果你正在制作一个商业应用程序，并且你希望获得竞争优势 - 当然，这可能是一个糟糕的拍摄点......你可能会获得一个性能优势，但是会以更困难的开发和依赖于特定的硬件。

回头看看，一年后，答案可能会不同，GPU的速度，Cuda编译器的开发和研究社区的经验的另一代或两代。

Answer 3

Nvidia的demo'ed在CUDA的光线追踪器在今年的会议Nvision公司。这里有关于它的幻灯片的链接。

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

Answer 4

只是一个指针my open-source, portable (Windows/Linux) GPL implementation of a CUDA raytracer。