|
|
4 回复 | 直到 17 年前
|
1
24
在CUDA中需要非常小心的一件事是,由于底层GPU硬件的结构,内核代码中的发散控制流绝对会降低性能。GPU通常具有具有高度一致的控制流的大规模数据并行工作负载(即,您有数百万像素,其中每个像素(或至少很大一部分)将由GPU操作) 准确的 相同的着色器程序,甚至在所有分支中采用相同的方向。这使他们能够进行一些硬件优化,比如只为每组32个线程提供一个指令缓存、获取单元和解码逻辑。在图形中常见的理想情况下,它们可以在同一周期内向所有32组执行单元广播相同的指令(这称为SIMD或单指令多数据)。他们可以 MIMD(多指令)和SPMD(单程序),但当流式多处理器(SM)中的线程发散(从分支中获取不同的代码路径)时,问题逻辑实际上会在每个代码路径之间逐周期切换。您可以想象,在最坏的情况下,所有线程都位于不同的路径上,您的硬件利用率下降了32倍,这实际上扼杀了通过CPU在GPU上运行所带来的任何好处,特别是考虑到通过PCIe将数据集从CPU编组到GPU的相关开销。 这就是说,光线跟踪虽然数据在某种意义上是并行的,但对于即使是稍微复杂的场景,控制流也有很大的分歧。即使您设法将一束紧挨着彼此发射的光线映射到同一个SM上,初始反弹的数据和指令位置也不会保持很长时间。例如,想象所有32条高度相干的光线从球体上反弹。在这次反弹之后,它们都会朝着完全不同的方向运动,可能会撞击到由不同材料制成的物体,以及具有不同照明条件的物体,等等。每个材质和照明、遮挡等条件集都有自己的指令流(用于计算折射、反射、吸收等),因此即使在SM中的大部分线程上运行相同的指令流也非常困难。在光线跟踪代码的当前技术水平下,此问题会将GPU利用率降低16-32倍,这可能会使应用程序无法接受性能,特别是在实时(例如游戏)的情况下。对于渲染场等,它可能仍优于CPU。 目前研究界正在研究一类新兴的MIMD或SPMD加速器。我会把它们看作是软件、实时光线跟踪的逻辑平台。 如果您对所涉及的算法和将它们映射到代码感兴趣,请查看POVRay。再看看光子映射,它是一种有趣的技术,甚至比光线追踪更接近于表示物理现实。 |
|
|
2
9
http://www.nvidia.com/object/cuda_home.html 但这基本上是一个研究问题。做得好的人会从中得到同行评议的研究论文。但是 在这一点上,仍然意味着最好的GPU/Cuda结果与CPU/multi-core/SSE上的同类最佳解决方案大致相当。所以我认为现在假设使用Cuda将加速光线跟踪器还为时过早。问题是,尽管光线跟踪是“令人尴尬的并行”(正如他们所说),但它并不是那种直接映射到GPU的“固定输入和输出大小”问题——你需要树、堆栈、动态数据结构等。这可以用Cuda/GPU来完成,但很棘手。
|
|
|
3
6
|
|
|
4
4
Nvidia在今年的NVision会议上在CUDA演示了一款光线跟踪器。这里有一个链接到他们关于它的幻灯片。 |
