我目前正在实施光线跟踪器。由于光线追踪的计算量非常大，而且无论如何我都要研究CUDA编程，我想知道是否有人有任何将这两者结合起来的经验。我无法确定计算模型是否匹配，我想知道会发生什么。我得到的印象是它不是天堂般的匹配，但是一个体面的速度增加会比没有好。
答案 0 :(得分：21)
在CUDA中要特别警惕的一点是，由于底层GPU硬件的结构，内核代码中的不同控制流程绝对会导致KILLS性能下降。 GPU通常具有大规模数据并行工作负载，具有高度一致的控制流（即，您有几百万个像素，每个像素（或至少大块）将由精确操作shader程序，甚至在所有分支中采用相同的方向。这使他们能够进行一些硬件优化，例如每组32个线程只有一个指令缓存，获取单元和解码逻辑。在理想情况下，这是在图形中常见的是，它们可以在同一周期内向所有32组执行单元广播相同的指令（这称为SIMD或单指令多数据）。它们可以模拟 MIMD（多个） -Instruction）和SPMD（单程序），但是当流式多处理器（SM）中的线程发散（从分支中取出不同的代码路径）时，问题逻辑实际上在逐个周期的基础上在每个代码路径之间切换你可以想象，在最坏的情况下，所有线程都在s上相同的路径，您的硬件利用率下降了32倍，有效地消除了通过CPU在GPU上运行所带来的任何好处，特别是考虑到从CPU，通过PCIe到数据集编组相关的开销。 GPU。
也就是说，光线跟踪虽然在某种意义上是数据并行的，但对于即使是适度复杂的场景也具有广泛分歧的控制流。即使你设法将一堆紧密间隔的光线映射到彼此相邻的SM上，你对初始反弹的数据和指令局部也不会持续很长时间。例如，想象所有32条高度相干的光线从球体反射回来。在弹跳之后，它们将全部朝向相反的方向，并且可能会击中由不同材料制成的物体，具有不同的照明条件，等等。每种材料和一组照明，遮挡等条件都有自己的指令流（计算折射，反射，吸收等），因此即使很大一部分运行相同的指令流也变得非常困难SM中的线程数。使用光线跟踪代码中的当前最新技术，此问题会使您的GPU利用率降低16-32倍，这可能会使您的应用程序无法接受性能，特别是如果它是实时的（例如游戏）。它仍然可能优于CPU，例如一个渲染农场。
现在研究界正在研究一种新兴的MIMD或SPMD加速器。我将这些视为软件的实时光线追踪的逻辑平台。
如果您对所涉及的算法感兴趣并将其映射到代码，请查看POVRay。同时研究光子映射，它是一种有趣的技术，甚至比光线追踪更接近于表示物理现实。
答案 1 :(得分：9)
它当然可以完成，已经完成，并且是目前在光线追踪和Cuda大师中的一个热门话题。我首先要仔细阅读http://www.nvidia.com/object/cuda_home.html
但这基本上是一个研究问题。做得好的人正在从中获得经过同行评审的研究论文。但是 well 在这一点上仍然意味着最好的GPU / Cuda结果与CPU /多核/ SSE上的最佳解决方案大致相当。因此，我认为使用Cuda将加速光线跟踪器还为时尚早。问题是虽然光线跟踪“令人尴尬地平行”（正如他们所说），但它并不是那种直接映射到GPU的“固定输入和输出大小”问题 - 您需要树，堆栈，动态数据结构等它可以用Cuda / GPU完成，但它很棘手。
您的问题并不清楚您的经验水平或项目目标。如果这是你的第一个光线追踪器并且你只是想学习，我会避免使用Cuda - 它会花费你10倍的时间来开发，你可能不会获得良好的速度。如果你是一位经验丰富的Cuda程序员并且正在寻找一个具有挑战性的项目，光线跟踪只是一个有趣的事情，无论如何都要尝试在Cuda中进行。如果你正在制作一个商业应用程序并且你希望获得竞争速度优势 - 那么，这可能是一个垃圾射击......你可能会获得性能优势，但代价是更难开发和依赖于特定的硬件。
回顾一年后，在GPU速度，Cuda编译器开发和研究社区经验的另一代或两代之后，答案可能会有所不同。
答案 2 :(得分：6)
答案 3 :(得分：4)
Nvidia今年在他们的NVision会议上演示了CUDA中的光线跟踪器。这是他们幻灯片的链接。