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