找回密码
 立即注册
查看: 299|回复: 0

imagination-光线追踪加速的6个等级

[复制链接]
发表于 2022-8-24 11:51 | 显示全部楼层 |阅读模式
来自imagination的白皮书-《Imagination_RayTracing-Levels_Whitepaper》
光线追踪是目前占据头条的一项技术,是图形技术的下一阶段,并且到今年年底它会被广泛应用于消费者的PC和控制台中。这篇指南将介绍光线追踪等级的概念,从而明确并不是所有的光线追踪解决方案都是相等的,并且具有更高等级的光线追踪要比低等级的光线追踪具有更好能力和更丰富的特性。由于等级是递增的,本指南将按照从等级0到等级5的顺序介绍架构变化和功能。


等级0-传统解决方案

光线追踪并不是一种渲染图形的新方法。这个概念出现的时间比今天传统主流的GPU渲染要长,并且它已经作为产品设计、建筑作品、视觉效果和电影渲染的首选渲染方法使用了相当多年。光线追踪也是游戏美术创作的基础,它通常用于离线制作用于实时游戏引擎的美术中的光影信息。但是一旦“烘烤”完成,这个光信息是静态不能改变的。
由于光线追踪已经是当前游戏内容的组成部分,所以硬件加速能够让光线追踪具有完整动态和实时性,这是许多公司长期以来的目标。事实上许多人试图做到这一点,但直到最近大多数都失败了。
通常这些光线追踪加速的早期尝试都集中于新的、非常不同的GPU架构,它们必须和新的、非标准的专有API相匹配。这种分歧是市场采用的主要障碍,例如OpenGL(或OpenGL ES, Vulkan或DirectX)的生态系统对完全不同的东西是昂贵和困难的。
IntelEmbree内核和Caustic的OpenRL是一些历史上的例子,它们提供的自定义API与占主导地位的传统图形API不易保持连续性。从很多方面来看,Caustics OpenRL是朝着正确方向迈出的第一步,因为它从看起来像OpenGL的东西开始,使用了一些已知的概念和语言,这有助于消除一些进入的障碍。但它最终仍然是一个新的、不同的API。有些光线追踪解决方案甚至不考虑API,而是提供你必须使用的完整渲染引擎,这当然是开发者采用的更大障碍。
毫无疑问这些早期的尝试为实现今天的实时光线追踪解决方案铺平了道路,但它们只是没有成功,所以是0级解决方案。


等级1-传统GPU上的软件

L0级解决方案的主要缺陷是生态系统和兼容性,过渡路线的最直观的方法是使用现有的图形和计算API实现光线追踪。事实上已经有许多软件解决方案做到了这一点,特别是在PC外接程序图形卡市场上,许多专有的效果和实现已经深深嵌入到游戏引擎中。
虽然这些解决方案中的大多数都不是真正的“API”,也绝对不是“标准API”,但这些解决方案确实拓宽了光线追踪的范围和可用性,并已广泛使用多年。但是大多数人要么专注于非常高端的低速电影渲染(考虑每小时帧数,而不是每秒帧数),要么应用于游戏引擎中非常有限和选定的效果。在许多情况下,这些效果采用了光线追踪的名称,但通常他们只是模糊地使用了概念的简化版本。
光线追踪纯软件的主要问题是光线追踪本身的计算成本很高,而且过于复杂,无法用通用的API类型来处理。这意味着它只允许很少的捷径,并且只有当你能把问题空间缩小到允许你使用很多技巧时,这些捷径才能发挥作用。但是对于通用API模型,这是不可能的。因此虽然在GPU上的软件光线追踪通常比在cpu上更快,但帧率总是很低,并且不是真正的实时。一些“光线追踪”软件解决方案提供了更高的速度——甚至是实时的——但这通常是通过偷工减料和优化特定功能子集来实现的,其中许多技术依赖于(预先计算的)查找表和结构,这些表和结构已经在算法的能力范围内进行了高度调整和优化。
软件解决方案在帮助建立功能需求方面发挥着关键作用,但这始终都不是一个长期的解决方案,因为软件在性能、能效和带宽效率方面会天生地迅速落后于专用的和调优的硬件解决方案,因此这是L1级解决方案。他们可以支持和扩展高级解决方案的生态系统,例如微软提供DXR模拟,这是一个1级解决方案。它允许内容在更广泛的平台上运行,但可能会显著降低性能和/或质量。
等级2-Ray/Box and Ray/Tri 测试电路

当我们着眼于软件中GPU上的光线追踪处理时,我们很快就会发现大部分的节拍都投入到了处理光线盒和光线三角形的交点上。
本质上,使用可编程GPU逻辑做光线盒相交测试,本质上是融合乘加(FMA),它需要比提供相同功能的固定功能块多44倍的硅面积。在2014年的GDC上,Imagination以一种有效的视觉方式展示了这一点(见下文)。
毫无疑问使用一个更小的固定函数块会更强大,更节省带宽,也释放了很多ALU周期,可以用于其他着色器处理。
光线三角形测试也有类似的好处,因此将这两种类型的固定功能添加到GPU中可以显著加快GPU的光线追踪能力。这种最简单的形式是实时光线追踪成为可能的基础。这些固定功能的操作可以暴露为着色程序中的新指令,这种方法形成了在2020年推出的PC和控制台图形解决方案中添加光线跟踪加速的基线,我们将其描述为2级解决方案。


等级3-基于硬件的BVH处理

等级2的解决方案有盒和三角形测试电路,但所有其他处理仍然在着色器代码中。具体来说剩下的就是层次包围盒(BVH)的遍历。
BVH是一个包围盒的层次结构(概念上通常是立方体),它细分场景,目的是通过快速剔除大部分的盒和三角形层次来减少计算相交工作的数量。BVH意味着我们可以避免在场景中的每个三角形中测试每条光线,这是过度计算的。相反地我们构建了一个层次结构的盒,它被细分成更小的盒,最终包含三角形,这是所有GPU渲染的标准原语。通过处理光线与这个层次结构,我们可以快速剔除大量的工作,因为如果我们没有触及包围盒,我们也可以剔除其中更小盒和三角形的完整层次结构。
用于此目的的遍历代码不太适合GPU的并行处理特性。当光线在BVH数据结构中被追踪时,代码必须在这个过程中做出很多决定(分支/发散)—例如你从顶部开始做一个方框检查,基于这个检查你触发更多的方框检查,直到最终你到达三角形级别的检查。从着色器代码中做出这些决定和触发指令是可能的,但不是有效的。最终它没有很好地利用有价值的着色器处理能力,而且也不太适合GPU的SIMD特性,因为它本身充满了分支和决策,这从来不适合并行处理架构。
因此,一个合乎逻辑的下一步是扩展光线跟踪硬件来处理完整的光线BVH处理工作流,从而将着色器代码更多的时钟周期卸载到专用的调优硬件上。在这种情况下,每条光线穿过BVH现在完全由专用逻辑管理,其中包括使用等级2中的硬件光线盒和光线三角形测试电路。除了从ALU上卸载更多的工作之外,这还增加了一个好处,即缓存和数据流可以得到更优化,并且通过在BVH结构中同时处理更多光线可以实现更大的并行效率。


内联光线追踪vs全光线追踪

虽然这篇入门文章关注的是硬件架构层面,但在软件层面光线追踪API功能的两个不同层面也存在差异。第一个也是更简单的层次是“内联光线追踪”,也被称为“光线查询”。从根本上说顾名思义这种光线追踪的方法设置了带有关联状态的光线,然后继续进行光线查询:光线通过BVH进行追踪,并将报告其结果。本质上,这正是第2级和第3级解决方案在硬件上所做的--循环通过盒测试和最终光线三角形测试,然后报告所需的结果,这被简化为命中或错过。一个简单的例子是发送一个光线查询到一个光源;如果光线照射到不透明的物体,我们就知道自己处于阴影中,但是如果光线照射到光源,我们就知道像素被照亮了,因此基于这个简单的光线查询,我们现在实现了光线追踪阴影:
Setup Ray (myRay)
AnyHit = RayQuery (myRay)
If (AnyHit = TRUE)
Execute Shadow code
Else
Execute Lit code虽然上面的例子很简单,但并不是大多数人所认识到的光线追踪——也就是说,光线在环境中来回反射,从而产生复杂的光线反射效果。这种更复杂的光线追踪形式被称为"全光线追踪"并且它确实做到了;当光线命中/错过对象时,它会创建新的着色程序并执行。
光线从一个着色程序中发射出来,照射到另一个物体,这个物体又会启动另一个着色程序,而这个着色程序又会启动另一条光线,光线又会启动另一个着色程序,以此类推,这就是所谓的递归。递归的结果是一个着色器程序的堆栈,这个过程会一直持续下去,直到你的光线在某个地方停止反弹,然后你将堆栈倒回,收集在场景周围跟踪光线的所有处理阶段。
从概念上看,它是这样的:
EmitRay (Ray1)
  Hit Object which EmitRay (Ray2)
     Hit Object which EmitRay (Ray3)
        Hit Object – execute shader program
     Execute shader program which takes previous hit data into account
  Execute shader program taking both the previous two hits data into account
Original program which takes the whole ray data flow into account这种类型的递归是复杂的,因为正如您从上面看到的,阶段堆栈在开始之前有一个未知的深度,因为您不知道射线会或不会击中什么对象。这使得它成为一个非常动态和多阶段的过程,每个阶段都需要存储和资源。这就是所谓的“全光线追踪”,比光线查询功能更强大,但也更复杂。Imagination Technologies作为光线追踪的先驱之一,开发出了一种既支持内联光线追踪(光线查询)又支持全光线追踪的架构。
等级4-基于硬件相关分类的BVH处理

虽然光线追踪在本质上是“令人尴尬的平行”,但实时光线追踪花了这么长时间才成为现实的原因之一是并行性是存在的,但它在本质上经常是发散的和非相干的。这可以从下面的插图中理解。
在现实世界中,材料有不同的属性—有些是光滑的,但大多数是粗糙的——因此,对于真实的表面,光线不会以完全相同的路径反射,而是会向不同的方向反射。这导致了发散;例如,光线从一个像素跳到下一个像素会导致光线走向非常不同的方向。因此光线将沿着不同的路径穿过BVH盒—从而导致不同的内存访问——并且从逻辑上讲,沿着不同方向传播的光线也将与不同的三角形相交,触发不同的着色程序——从而在着色器执行中导致分散。
对于GPU来说,分散是件坏事,因为尽管GPU非常擅长处理高度并行的工作负载,但只有当这些工作负载一致且相似时,它们的SIMD架构才有意义。如果每个像素都想做一些不同的事情,GPU所依赖的高执行和带宽效率的技巧就会失效。这意味着最终将使用蛮力方法(即使用大量ALU和光线追踪单元),需要补偿处理流努力有效地使用它们(即理论上的高峰值吞吐量,但在实际使用中利用率较低,因此低吞吐量数字)。
现在虽然从一个像素到下一个像素的光线可能是发散的,但这并不意味着在四处弹跳的光线组中没有“相关性”。同样这在下一页的图片中得到了最好的说明。


下面的反射形状显示了从这个物体反射的光线中隐藏的相干性,例如,你可以看到穿黄色衣服的人被反射了很多次,这意味着这些光线走向相同的方向,确实是相干的。更重要的是,如果我们能够对这些光线进行分组,它们将遵循通过BVH的类似路径,为我们提供较高的缓存命中率和数据重用率。它们也将最终与相同的三角形碰撞和相交,并可能也会执行相同或类似的着色程序,从而实现了传统并行的高效GPU ALU流水线。


因此我们需要的是一种捕获这种“隐藏的”一致性的方法,以处理这种效率改进。Imagination在2014年的PowerVR Wizard GPU架构就做到了这一点,开创了实时光线追踪的现代GPU架构,并引入了混合渲染(混合传统渲染和光线追踪渲染)等概念,并引入了相关分类引擎。
在创新方面,相关引擎在很多方面都是基于贴图渲染的翻版,Imagination在20世纪90年代后期开发了PowerVR GPU,现在所有的现代GPU架构都采用了PowerVR GPU。
基于贴图的渲染也做了一个相干排序:在几何/顶点着色处理之后,三角形被分类到贴图中,这之后确保每个三角形的像素在每个贴图的相干像素组中处理。这意味着所有的处理都可以停留在芯片上的贴图内存中,从而减少带宽并提高效率。
光线的相干引擎实现了同样的功能,将能够共享内存访问的光线分类成的相干束,从而有效地保证完美的缓存命中并使用更少的带宽。当然这也有助于提高能效,因为数据移动需要消耗大量的功耗。硬件相干收集器和SIMD引擎一样还有助于实现更高的性能效率,并得到更高的执行效率,因为这些束将命中类似的三角形/对象。正是这种效率上的巨大飞跃使这种架构成为第四级光线追踪解决方案。
MIMD架构

历史上更奇特的光线追踪“解决方案”是基于MIMD(多指令/多数据)架构,他们声称这解决了光线追踪的相干性问题。但是MIMD并不是真正的解决方案—它是一种接受失败的形式,即处理中没有相干性,并调整ALU以更有效地执行这种分散的工作负载。MIMD的问题,以及它作为一种处理解决方案普遍缺乏成功,是硅的复杂性和尺寸昂贵。使用MIMD需要生成所有能够执行不同指令的ALU,并且不与任何其他ALU共享数据。这类似于创建一个单线程的GPU,其中每个ALU携带所有开销来执行具有唯一数据获取的唯一指令。
因此MIMD不是一个优雅的解决方案,它是一个缺乏相干性的非常昂贵的处理方式。此外虽然MIMD方法可以处理执行中的分散,但它并没有解决数据仍然是分散的事实,而是现在分散的问题已经从ALU转移到了内存子系统。虽然现代存储技术发展非常快,并能维持非常高的数据速率,但它们同样只在获取的数据是相干的时才能做到这一点;比如你读取连续数据。当它是随机的(按照MIMD)时,从内存中获取数据的速度要慢几个数量级。因此MIMD并不是实时光线追踪的真正解决方案。
等级5-基于场景层次生成器的硬件相干BVH处理

到目前为止,我们大部分的注意力都集中在加速追踪光线通过BVH结构,但我们忽略了BVH本身的实际创建。关于如何创建这种结构的实际方法和决定是多种多样的:例如层次结构有多深,何时进一步分割或细分等等。
过程和决策甚至可以是动态的,以及可以是基于从工作负载中获得的启发式方法。此外带宽消耗和结构的准确性可以相互权衡。在等级4之前,这个结构的创建是在软件中完成的,这意味着它要么使用CPU,要么使用GPU的计算路径。 在等级5的解决方案中,我们将BVH的创建过程转移到专用硬件中,并同时使用在第3级和第4级解决方案中支持的BVH遍历方法。
通过使用专用硬件构建BVH,我们正在进一步卸载着色器的核心工作,并使用更强大的能力和处理高效的逻辑来执行这项工作。此外,对于PowerVR架构,场景层次生成器(SHG)集成在GPU内部,这意味着数据流可以直接从传统的顶点和几何处理阶段进入SHG块,在内存中生成BVH。这个过程甚至可以与传统的几何输出相结合,比如用于基于贴图渲染的贴图指针列表,从而以最有效的方式实现混合渲染。
一个专门的细粒度调节块是快速和有效的,这意味着这个等级的光线追踪加速器可以处理更多的动态几何图形,从而达到更高的场景复杂性,包括许多复杂的动画高度详细的对象的全动态场景。
这个BVH硬件生成器,比如imagination场景层次生成模块,理论上可以被添加到低效的光线追踪等级中。如果这样做了,就等级而言,将会有一个“加号”来表示。在这种情况下,一个在硬件中带有BVH生成器的2级光线追踪解决方案,将是一个“2级+”解决方案,当然不是一个5级解决方案。


小结

虽然光线追踪还处于早期阶段,但它所提供的现实主义和它所带来的开发效率意味着最终将会增加图形处理的百分比。它肯定会彻底改变多个领域,从建筑可视化和工程原型到电视和电影动画,当然还有游戏。这个技术甚至被宣传用于除传统图形之外的其他用途,比如碰撞检测、物理加速、声音处理或体渲染。
然而事实是摩尔定律即将终结,游戏行业再也不能依赖于硬件每两年就变得更加强大的模式。因此为了继续推进光线追踪技术,特别是在power受限的移动平台上,高效设计固定功能加速器的解决方案将变得越来越重要。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

×
懒得打字嘛,点击右侧快捷回复 【右侧内容,后台自定义】
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

小黑屋|手机版|Unity开发者联盟 ( 粤ICP备20003399号 )

GMT+8, 2025-2-23 02:46 , Processed in 0.119880 second(s), 26 queries .

Powered by Discuz! X3.5 Licensed

© 2001-2024 Discuz! Team.

快速回复 返回顶部 返回列表