用CUDA进行光线追踪

我目前正在实施光线跟踪器.由于光线追踪的计算量非常大,而且无论如何我都要研究CUDA编程,我想知道是否有人有任何将这两者结合起来的经验.我无法确定计算模型是否匹配,我想知道会发生什么.我得到的印象是它不是天堂般的匹配,但是一个体面的速度增加会比没有好.

在CUDA中要特别警惕的一件事是,由于底层GPU硬件的结构,内核代码中的不同控制流绝对会导致KILLS性能下降.GPU通常具有大规模数据并行工作负载,具有高度一致的控制流(即,您有几百万像素,其中每个像素(或至少大块)将由精确操作相同的着色器程序,甚至在所有分支中采用相同的方向.这使他们能够进行一些硬件优化,例如每组32个线程只有一个指令缓存,获取单元和解码逻辑.在图形中常见的理想情况下,它们可以在同一周期中向所有32组执行单元广播相同的指令(这被称为SIMD或单指令多数据).他们可以效仿MIMD(多指令)和SPMD(单程序),但是当流式多处理器(SM)中的线程发散(从分支中取出不同的代码路径)时,问题逻辑实际上在循环中的每个代码路径之间切换 - 循环基础.你可以想象,在最糟糕的情况下,所有线程都在不同的路径上,你的硬件利用率下降了32倍,有效地杀死了你在CPU上运行GPU所带来的任何好处,特别是考虑到与通过PCIe将数据集编组到GPU相关联的开销.

也就是说,光线跟踪虽然在某种意义上是数据并行的,但对于即使是适度复杂的场景也具有广泛分歧的控制流.即使你设法将一堆紧密间隔的光线映射到彼此相邻的SM上,你对初始反弹的数据和指令局部也不会持续很长时间.例如,想象所有32条高度相干的光线从球体反射回来.在弹跳之后,它们将全部朝向相反的方向,并且可能会击中由不同材料制成的物体,具有不同的照明条件,等等.每种材料和一组照明,遮挡等条件都有自己的指令流(计算折射,反射,吸收等),因此,即使在SM中的大部分线程上运行相同的指令流也变得非常困难.使用光线跟踪代码中的当前最新技术,这个问题会使您的GPU利用率降低16-32倍,这可能会使您的应用程序无法接受性能,特别是如果它是实时的(例如游戏).它仍然可能优于CPU,例如渲染农场.

目前在研究界正在研究一种新兴的MIMD或SPMD加速器.我将这些视为软件,实时光线跟踪的逻辑平台.

如果您对所涉及的算法感兴趣并将它们映射到代码,请查看POVRay.同时研究光子映射,它是一种有趣的技术,甚至比光线追踪更接近于表示物理现实.

它当然可以完成,已经完成,并且是目前在光线追踪和Cuda大师中的热门话题.我首先阅读http://www.nvidia.com/object/cuda_home.html

但这基本上是一个研究问题.做得好的人正在从中获得经过同行评审的研究论文.但是,还有在这一点上仍然意味着最好的GPU/Cuda的结果是与CPU /多核/ SSE最佳的一流的解决方案大致有竞争力的.因此,我认为使用Cuda将加速光线跟踪器还为时尚早.问题是虽然光线跟踪"令人尴尬地平行"(正如他们所说),但它并不是那种直接映射到GPU的"固定输入和输出大小"问题 - 您需要树,堆栈,动态数据结构等它可以用Cuda/GPU完成,但它很棘手.

您的问题并不清楚您的经验水平或项目目标.如果这是你的第一个光线追踪器并且你只是想学习,我会避免使用Cuda - 它会花费你10倍的时间来开发,你可能不会获得良好的速度.如果你是一位经验丰富的Cuda程序员并且正在寻找一个具有挑战性的项目,光线跟踪只是一个有趣的事情,无论如何都要尝试在Cuda中进行.如果你正在制作一个商业应用程序,并且你希望获得竞争速度优势 - 那么,这可能是一个废话拍摄......你可能会获得性能优势,但代价是更难开发和依赖于特定的硬件.

在一年后回来看,答案可能会在GPU速度,Cuda编译器开发和研究社区经验的另一代或两代之后有所不同.

只是指向我的CUDA光线跟踪器的开源,可移植(Windows/Linux)GPL实现的指针.