深入探讨Apple M1的光线追踪性能

Warning: Can only detect less than 5000 characters

熟悉Metal的人可能会知道以前的Metal Performance Shaders射线相交。通过允许渲染器完全移动到GPU，在线射线跟踪的新支持对此有所改进。先前的射线相交是通过捕捉射线，在场景中找到相交并将这些结果写回内存来进行的。需要分派多个计算着色器以跟踪主光线并创建阴影和辅助光线，然后跟踪阴影光线并继续辅助光线，同时过滤出终止的路径，这需要大量的内存流量和计算分派，从而给渲染器带来了开销。这种方法也不太适合使用光线跟踪效果来增强传统的栅格化管道。基于跟踪和分类光线以及相交信息以提取相干性的方法对于复杂的胶片渲染器很有价值，并且也可以使用在线射线跟踪有效地实现。迪士尼的Hyperion渲染器广泛地使用了排序和批处理功能，以从光线原本不连续且发散的分布中提取出一致的工作量，此外还有一段精彩的高级视频介绍了该工作原理。

Metal光线跟踪API可以很好地使用，它与其他光线跟踪API有很多相似之处，但是经过简化以使其更易于使用。例如，比较在DirectXor Vulkanwith中构建和压缩BVH所需的代码Metal.OptiX的API提供了类似的简化，这是OptiX中的BVH构建以供参考。使用着色器语言具有模板和C ++样式功能也很好，Metal与OptiX共享此功能，后者使用CUDA作为设备侧代码。

这种简单性也有一些缺点。例如，在DirectX，Vulkan和OptiX中，您可以控制加速结构内存的分配位置，而金属可以为您进行分配。因此，您无法在MTLHeap上分配加速结构，因此要确保它们可用于渲染管道，必须单独将它们标记为循环使用，而不是单个useHeap调用。

//使用我们的顶级加速结构[command_encoder setAccelerationStructure：bvh-＆gt; bvh atBufferIndex：1]; //并标记所有使用的网格加速结构，因为它们被//顶层高层间接引用了（auto＆amp; mesh：bvh-＆gt; meshes）{[command_encoder useResource：mesh-＆gt; bvh用法：MTLResourceUsageRead]; }

如果您有很多底层BVH，这会增加一些开销，例如在具有许多实例的场景中。能够在堆上分配加速结构，并用单个[command_encoder useHeap：data_heap-＆gt; heap];

通过实现自定义几何图形或遍历过程中需要进行的其他操作（例如，alpha剪切），不包括光线跟踪管道，仅要求使用着色器绑定表式结构即可显着简化该API。DirectX中用于管理SBT设置的代码， Vulkan和OptiX在每个后端中占了我帮助程序代码的很大一部分，很高兴在不实现自定义几何体或alpha剪切纹理的Metal后端中跳过此步骤，但是在SBT模型中，GPU可以组调用或重新排序函数调用以减少发散，但是对于无法向驱动程序提供此信息的行内光线跟踪，这几乎是不可能的。对于DirectX，Vulkan和OptiX的当前驱动程序，实际上是否这样做对于驱动程序团队来说是个问题，但是最后，您可能会发现自己实现了一些类似于SBT的功能，但在argum中为场景中的原始/网格/实例查找正确的数据要简单一些ent缓冲区，就像我在ChameleonRT中所做的那样；并且需要实现遍历过程中发生的操作（自定义几何图形，alpha剪切透明度）。总体而言，我对可能会更好的东西的评论很少。

我对AnandTech的CineBenchresults最感兴趣的是CineBench实际上使用了Embreefor光线追踪，这是由Intel开发的库！Embree是CPU光线追踪库，它提供了优化的加速结构遍历和原始的交叉核，满足了对CPU的类似需求新的GPU光线跟踪API在GPU上执行。 Embree于2011年首次发布，现已在电影，科学可视化及其他领域得到广泛采用。

ChameleonRT还实现了Embree后端，该后端使用Embree进行快速射线遍历和原始相交，使用ISPC进行SIMD编程，并使用TBB进行多线程。使此后端在M1 Arm上运行实际上比我预期的要容易一些。 Syoyo Fujita已经维护了Embree的AArch64 / NEON端口Embree-aarch64，该端口已从Apple Developer Ecosystem Engineering团队获得了一些更新，以便在NEON后端上添加AVX2。 Embree已针对8宽SIMD进行了非常优化，因此即使需要使用2个NEON矢量作为一个AVX2矢量，它也可以提供比NEON 4宽后端更好的性能。

ISPC是我最担心的运行依赖性。ISPC是用于CPU上SIMD编程的编译器，您可以在其中编写标量程序，该标量程序可以在CPU的SIMD通道上并行运行，每个向量通道一个程序实例。每个程序并行处理不同的数据，并在SIMD中执行。这有点像GLSL或HLSL在CPU上运行，其中使用SIMD并行执行标量查找程序，但是事实证明，ISPC已经提供了对NEON和AArch64的支持，并且启用了amacOS + AArch64 / NEON目标就像使目标OS和ISA标志的组合不会出错一样容易。我开放了PR，可以将此支持合并回ISPC。

最后，虽然TBB是用于多线程的Intel库，但它与特定的CPU架构没有任何关系。这里所需要做的就是从针对AArch64的源代码构建TBB。

ChameleonRT现在可以在M1的CPU和GPU上运行了，我们可以做一些基准测试，看看M1在光线穿越性能上的表现如何！我在一些可以访问的不同系统上运行了这些测试。在XPS 13中有一个i7-1165G7（在这里温度可能是个问题），在较旧的台式机中有一个i7-4790K，在Ubuntu工作站中有一个i9-9920X。在GPU方面，我有一个RTX 2070。在Mac Mini中具有16GB RAM的M1。在开始之前，这是CineBench编号，这些编号让我感兴趣地检查了M1：

表1：在测试的系统上的CineBench R23得分。 * i9-9920X系统正在运行Ubuntu，但无法使用CineBench。该分数是从CGDirector.com报告的。

对于ChameleonRT中的基准测试，我们将使用以下两个场景：Sponza和San Miguel.Sponza是一个具有262K三角形的小场景，San Miguel是一个用于9.99M三角形的交互式光线追踪的不错的大小。两个都被视为三角形汤由BVH构建器表示，这意味着将构建一个包含场景中所有三角形的单个底层加速结构，这将为BVH构建器提供有关几何分布的尽可能多的信息，以便它可以构建高质量的加速结构。由于ChameleonRT不支持每个三角形的材质，因此从Morgan McGuire的``网格''页面中导出并重新导出到Blender中以使用OBJ材质组而不是每个三角形的材质。基准运行渲染1280x720图像并运行约200帧，此后平均帧速率（FPS）和每秒追踪的百万条光线（MRay / s）。

图1：基准测试中使用的测试场景。 Sponza（左）有262K三角形，San Miguel（右）有996万

公平的比较是与使用Embree CPU后端的其他移动CPU，我的XPS 13中的i7-1165G7进行的比较，实际上有点支持M1，因为在基准测试期间XPS 13在散热方面会有些挣扎在这个比较中，我还包括了我的旧台式机CPU i7-4790K，因为它的分数与CineBench上的i7-1165G7相似。当运行ChameleonRT的Embree后端以缩短突发时间时，XPS 13实际上可以跑赢我的台式机，尽管速度较慢加热后下降。

在这些基准测试中，我展示了针对Intel CPU的最快SIMD配置。i7-1165G7具有AVX512，允许ISPC并行运行16个“线程”，而Emble可使用多达AVX512。 i7-4790K支持AVX2，允许ISPC并行运行8个“线程”。在M1上，可以使用ISPC编译双泵NEON目标，即在4宽NEON寄存器上执行8宽SIMD，但是我发现ISPC的4级目标表现最好。由于Embree已针对8宽SIMD进行了优化，因此将M1上的Embree配置为在NEON上使用AVX2。

为了进行极其不公平的比较，我们将M1上的Metal GPU光线追踪后端与RTX 2070上的DirectX光线追踪以及i9-9920X的Embree CPU后端进行了比较。这些比较是由我自己的好奇心驱动的。由于这些是我可以使用的最高端CPU和GPU系统，因此很有趣的看到M1排列在哪里，但是我不希望M1在这些任务上提供比这些系统更高的性能.RTX 2070的TDP为175W和硬件加速光线跟踪，而整个M1芯片估计约为20-24W，并且不具备加速光线跟踪的硬件。i9-9920X的TDP为165W，并支持AVX512（16宽SIMD）和AVX2（ 8宽SIMD）。从以前的基准测试中可以看出，旧的i7-4790K对更宽的SIMD（AVX2）的支持仍然使其与M1竞争激烈。在这些基准测试中，我发现i9-9920X在仅使用AVX2时表现最佳。 Travis Downs，在某些CPU上使用AVX512可能会导致时钟下降，这取决于工作负载对SIMD的友好程度，实际上可能会在更窄的SIMD宽度上以更高的时钟获得更好的性能。 i7-1165G7，AVX512的性能略优于AVX2。

总结一下，我们可以回顾一下CineBench得分和CPU公平基准上的性能差异.M1的得分比CineBench上的i7-1165G7高1.93倍，但在ChameleonRT的Emble后端我们发现它仅为1.16倍同样，在测试的两个场景中，M1的得分比CineBench上的i7-4790K高出1.70倍，但实际上在两个场景中，其平均得分却要低1.05倍。这是怎么回事？

请务必记住，ChameleonRT并未测试与CineBench相同的功能。在像CineBench这样的生产渲染器上进行的工作要比在ChameleonRT这样的最小化工作上进行的工作多得多，而其他任务（例如与更昂贵的几何图形相交，评估更复杂的材质模型等）则可能占到总执行时间的很大一部分。另一方面，ChameleonRT却没有这些，实际上只是基准光线穿越性能。因此，如果我们在M1上使用Embree获得类似的光线穿越性能，但是CineBench中的其他功能更快，我们可以在中获得更高的相对得分CineBench比我们仅在遍历性能上要好。

总体而言，M1非常出色。在过去的两周左右的时间里，我一直在使用Mac Mini作为日常计算机，并且对性能和完全静音感到满意。对于一台几乎无声的计算机，我确实有话要说。听到风扇运行这组基准测试或并行构建LLVM来构建ISPC时，我真的很高兴看到未来的M *芯片将支持8宽SIMD和硬件加速射线追踪。在基准测试设置上，我在每台仅支持SSE4（4宽SIMD）的计算机上运行Embree后端，发现它比使用AVX2（8宽SIMD）运行时慢1.6-1.8倍。即使假设仅获得1.6倍在具有8宽SIMD的M1上速度更快时，这将使Embree CPU后端在Sponza上约为〜2.75FPS，在San Miguel上约为〜2.06 FPS.GPU上对硬件加速光线追踪的支持也将有助于改善GPU光线追踪性能。我不再需要非RTXGPU来进行粗略的性能比较，但是我希望有相当大的提速（超过2倍）。即使目前的性能水平对于轻量级芯片来说也令人印象深刻，因为它没有达到它具有与XPS 13相同的散热问题，并且在SIMD宽度为1/4（4与16）的情况下可以在CPU上提供更好的性能，并具有GPU光线跟踪API，在这些基准测试中，其CPU速度比CPU快1.6-2倍。看看苹果为高端产品计划了什么样的硬件将会很有趣。