amd吧 关注:782,087贴子:17,932,547

【魔法光线目录】RDNA2即将在下个月发布,来谈谈光线追踪吧

只看楼主收藏回复

对于如今的PC游戏,光线追踪已经不再是一个遥不可及的稀罕事物。安培显卡拉低了前代的价格,下个月RDNA2也将正式发布,XSS仅仅4T算力的GPU部分以及Intel的独立显卡也引入了光线追踪,甚至未来APU也将很快使用RDNA2架构,这宣布着这一技术在ANI三个阵营,从高端到低端都将会迅速普及。支持硬件坐标光源转换标志着GPU的真正诞生,而统一渲染架构则融合了传统意义上的顶点和像素单元,这是20年来GPU史上的两次最大变革。光线追踪的引入,则吹响了第三次变革的号角。
从本文你可以了解到如下问题:
★光线追踪有什么优势?
★什么是硬件光追,什么是软件光追?
★为什么帕斯卡、RDNA1 GPU执行光线追踪效率低下?
★什么是BVH?什么是光线求交?
★RDNA2是否支持的是硬件光线追踪?
★RDNA2与Turing、Ampere架构,在实现光线追踪上有什么区别?
★RDNA2与Ampere架构,在光线追踪上各自有什么优势?
★RTX与DXR的关系?
现在的光线追踪效果为何不明显?为何局限于镜面反射特效?
传统光栅化游戏中的光影效果,是开发人员凭借现实中的经验进行拟合,利用各种方法进行逼近。例如物体的反射,阴影效果,其本质不是换了形状、颜色的贴图而已。其深浅、粗糙程度并非严格计算得出,自然只能达到近似而不是完全准确的光照,更不用说是折射等更高级的特效。举个例子,孤岛危机1中纳米战斗装有个隐形模式,开启后整个人都会变成透明,但你会发现地面上你的影子还清晰可见,并且和没开启时没有任何区别。这正是“模拟”影子的弊端。现有的图形技术也许可以做到在这种情况下把影子抹除掉,甚至可以为影子加上一个由深变浅的效果,但只能靠近似与模拟。如果单独为每个影子都模拟这种效果,则势必会极大地增加开发的难度和工作量。再比如,目前的游戏中很难做出光源叠加的效果,多个光源形成的本影、半影效果在现今游戏中几乎无法见到,而红光加绿光叠加成黄色光,听起来则更是无法实现。你当然可以设定一套规则,让游戏中这样颜色的光束照在某一区域时,设定那片区域为黄色,但正如前面所说,设定越多,漏洞越大,而工作量也急剧增加。
而光线追踪则严格遵循光线的传播、反弹甚至是吸收规律,因此在计算此类效果时可以做到逼近现实的效果,并且是不需要过多人工干涉的,你需要做的只是正确设定光源亮度及衰减,以及设定正确的材质参数,光线追踪的原理就是让计算为你正确生成一切。


IP属地:江苏1楼2020-09-29 02:10回复
    例如上文所提到的光线叠加效果,可以用基于光线追踪的Vray渲染器轻松实现。
    如图所示,红、绿、蓝三个方块。我们知道,物体所固有的颜色是它所能反射的颜色,在白光照射下三个方块的固有色为紅、绿、蓝,代表着它们分别能反射紅、绿、蓝三种颜色。


    IP属地:江苏2楼2020-09-29 02:10
    回复
      当用红色光照射时,红色方块仍然可以反射红色,而绿、蓝方块由于无法反射红色光,所以呈现出黑色。

      用绿色、蓝色光照射时,亦是同理。


      如果用黄色光来照射,由于黄色光为红色光+绿色光的混合,在这种情况下,红色方块能反射出黄色光的红色部分,而绿色光则能反射黄色光中的绿色部分,因此它们正确呈现为红色和绿色,而蓝色方块无法反射黄色光中的任何一种色光,所以仍然为黑色。


      IP属地:江苏3楼2020-09-29 02:12
      回复
        当设定两个光源时,一个光源为红色,一个光源为绿色,地面上一些区域甚至能呈现出两种光叠加后的效果,也就是黄色。
        这种叠加效果在当今光栅化渲染游戏中,无法实现。


        IP属地:江苏4楼2020-09-29 02:13
        回复
          这,便是光线追踪的魔法。通过严格而精确的光线追踪计算,设定正确的光照与材质,我们将得到足以乱真的光照效果。比如我在家里装修时制作的用于参考的效果图。




          IP属地:江苏5楼2020-09-29 02:14
          回复
            甚至,部分物理渲染器可以将光视为电磁波,在渲染白光通过三棱镜等透明物体折射的场景时,可以正确呈现出因为折射率不同而产生色散的现象

            光线追踪有如此美好的优点,但为此付出的代价则是惨重的。室内设计中很有限场景的效果图,也需要几小时甚至几十小时的渲染。这种速度根本无法用于游戏。
            如果我们要把这个速度提高到在当前游戏中可用的程度,则势必要在各方面进行加速,甚至要进行大幅度的缩水和妥协。


            IP属地:江苏6楼2020-09-29 02:14
            收起回复
              一个场景中的光线是各种方向的,并不是所有光线都能到达我们的眼睛。如果逐个计算,那计算量则趋于无穷无尽。幸而,在这些光线中,我们只须考虑最终进入眼睛(摄像机)的光线。而由于光线是可逆的,因此,我们可以从摄像机向场景中投射出数目众多的光线,并且计算其和每个表面的作用。这种思路叫做逆向光线追踪,目前所有的光线追踪算法都是基于逆向光线追踪原理。
              光计算一次和表面的作用还不够,光线是有反弹和吸收的,因此我们还要计算出光线碰撞到某一点后衍生的次生光线的效果,这本来也是无穷无尽的计算,但幸运的是,现实中的表面大多数为粗糙的表面,光线的强度如此容易衰减,以至于大多数时候只需要考虑计算2次反弹,就可以达到逼真的效果。Vray渲染器的设置选项中,便有关于首次反弹和二次反弹的参数设置。
              另外,由于算力的限制,我们还要对从摄像机发出光线的数量进行缩水。例如支持光线追踪的游戏战地5中,根据nvidia所描述,每个像素为1束光线。这大大低于效果图中的值。前文的效果图,我使用的细分程度为1000,代表向屏幕上的每像素发射1000束光线。但依然可以留意到墙上较暗处的一些黑斑或者说噪点,那正是光线数量不足带来的影响。1000光线/像素尚且如此,1光线/像素的话,画面基本上是没办法入眼的。这时候人们便开发了各种降噪算法。目前游戏中的实时光线追踪降噪主要依靠流处理器进行,所以极度依赖FP32计算能力。本代安培架构的GPU,正如我之前所预测的那样,Rtcore数量并没有暴力扩充,旗舰3090只不过是82个,而3080和2080ti的数量相同,为68个。但是综合性能领先2080ti 30%的3080,限定在光线追踪的游戏里优势则扩大到了40%。Rtcore数量相同,但光线追踪之所以变得更强,原因就是FP32性能提升所致。关于目前光线追踪游戏到底是用FP32单元还是tensor core去噪,请参考我的贴子。https://tieba.baidu.com/p/6965646957
              以下是去噪前后的画面对比:

              因为现在实时光线追踪光线细分度严重不足,极其依赖降噪处理,所以在呈现反射,特别是模糊表面的反射特效时,有一种怪怪的感觉。

              这也是现今游戏画面光追效果还不够绚丽,甚至不够明显的根本原因。那就是,极低的光线采样,即使加上降噪,也很难实现更高级的材质、光线效果。


              IP属地:江苏7楼2020-09-29 02:19
              回复
                除此之外,我们必须还需要进行其他一些步骤来加速光线追踪的计算。光线追踪的原理,决定了我们要进行三个步骤。第一,需要有能力生成光线。第二,要能快速判定光线和场景里的哪一部分甚至哪一点发生作用。第三,进行计算并在相应的点着色。经过研究,第二个步骤是最为复杂耗时的。甚至可以说,它是当今GPU的阿克琉斯之踵。为什么呢?
                我们知道,当今GPU普遍采用SIMD体系。顾名思义,就是单指令多数据流。在GPU的一个SIMD单元里,运行相同的指令来处理多个数据。比如,图形流水线里顶点步骤的坐标转换,需要把众多数据通过相同的方式计算(相乘,相加),GPU的体系结构决定了它非常擅长处理这种情况,或者说GPU本来就是为了能在这种场景下大显身手,才演变成现在的样子。但是,GPU非常不擅长应付有分支的情况。很多计算机图形学的教程提到优化GPU的使用效率时,都格外强调要避免分支。因为GPU在SIMD单元运行相同指令的特性,导致它遇到分支需要把每种情况都运行一遍。例如一个控制语句
                if(A)
                {
                … //分支A
                }
                else
                {
                … //分支B
                }
                由于GPU的每个SIMD单元执行的指令是相同的,所以GPU线程的最小块(nv:warp amd:wavefront)里包含的指令也是相同的。那么这条控制语句就需要执行两次,第一次SIMD单元前半部分执行分支A,后半部分空操作,第二次后半部分执行分支B,前半部分空操作。这不但会导致拖慢处理速度,还会导致计算单元的闲置。


                IP属地:江苏8楼2020-09-29 02:20
                回复
                  光线碰撞(求交)的计算,恰恰需要对大量分支进行处理。这是由于在光线追踪的求交检测上,引入了BVH数据层级来进行加速。何谓BVH?BVH就是Bounding Volume Hierarchy的缩写,它是一种数据结构,直接翻译叫做边界体积层次。这里我用sketchup模型中的组件来说明一下。如图是一个客厅的模型,它由一个个组件构成:沙发,茶几,餐边柜,餐桌椅等等,每个组件都有相应的边界,也就是一个个大的盒子。比如沙发是一个大的盒子组件,茶几是一个大的盒子组件,餐桌是一个大的盒子组件,餐边柜也是一个大的盒子组件。






                  IP属地:江苏9楼2020-09-29 02:21
                  回复
                    每个大的盒子组件又由很多小的盒子组件组成,比如茶几这个大盒子,由茶几本体、花、书本等小盒子组成。而花这个盒子,又是由花瓶、花本体等更小的盒子组成。这种分类方法形成的数据结构,就叫做BVH。目前光线追踪渲染器大部分都使用BVH数据结构加快对光线的求交检测,除此之外还有kdtree等数据结构,则是对场景不断用二分法进行细分,最终也追查到最小单位,此处就不再赘述了。
                    运用BVH数据结构加速光线求交检测的过程大致如下:一束光线,如果没有碰撞到餐桌的大盒子,那它就更不会碰撞到餐桌桌面、餐凳等这些小盒子。如果没有碰到沙发的大盒子,那也不需要去研究它和沙发腿、沙发面等小盒子的关系。毫无疑问,这比直接对每个表面逐个排查,要节省掉大量计算量。




                    如果光线碰到了茶几这个大盒子,那我们就要继续深究,它是碰到了花瓶的小盒子,还是碰到了书本的小盒子。这样一步步追查下去,追查的盒子不断变小,细分,直到我们确定,这束光线最终碰撞到了某个花瓣表面,从而得出求交结果。这样就结束了一个完整的遍历过程。


                    IP属地:江苏10楼2020-09-29 02:22
                    回复
                      如此看来,BVH的作用就如同一个目录,通过检索它,可以以比以前快得多的速度判定光线的碰撞。


                      IP属地:江苏12楼2020-09-29 02:29
                      收起回复
                        同时分析整个流程,不难看出,每次BVH遍历涉及到大量分支情况,这是难以使用GPU的计算单元(SM,CU)的场合。所以必须要在GPU上引入专门的BVH加速单元来进行处理。在nVIDIA的GPU中,执行这项任务的单元叫做RTcore(Ray Tracing Core)。在AMD的GPU中,它的名字暂时被称为Ray Accelerator(暂定)。
                        在刚才遍历的过程中,我们经过多次盒子层级的判定,以及一次表面层级判定,最终确定光线碰撞到花瓣表面。所以BVH数据层级里主要分为box层级和triangle层级,也就是盒子层级和多边形层级。一般来说,一束光线都要经过多次盒子层级的求交判定,以及1次多边形层级判定,才能完成一次遍历过程。所以我们BVH单元中,也相应要设置有多个BOX求交单元以及1个三角形求交单元。在图灵RTcore、RDNA2光线加速器中,这个比例为4:1,也就是经过nv、AMD研究人员总结,认为4次box判定和1次三角形判定是较为普遍适用的情况,也就是最为效率的组织形式。在安培的RTcore中,则额外设置了一个三角形求交单元,也就是4:2。多出来的这个单元主要用于在运动模糊场景的光线追踪。通过首尾两次插值计算,得出中间过程中光线和三角形的求交结果,而无需在过程中每次进行box求交,加快了处理速度。目前在渲染软件中发挥了一些作用,在游戏中则尚无用武之地。所以仍然可以视作4:1来看待。
                        有了光线追踪单元的硬件比例,结合时钟频率以及单元数量,我们就可以得出光线追踪的求交速度,也就等同于光线追踪的计算能力。与此相关的科普可以在求秒的贴子里有详细论述。
                        《光追时代 光追加速器的性能参数解析》
                        https://tieba.baidu.com/p/6934323913


                        IP属地:江苏13楼2020-09-29 02:31
                        回复
                          可以看出,RDNA2架构旗舰Navi21在光线求交box层级计算能力遥遥领先,如果考虑到ampere额外增加的三角形求交单元在游戏中无法使用,那么就是Navi21 box、三角形求交计算能力均高于GA102。但安培亦有自己的独到优势,一方面在未来的游戏中可能会引入对插值计算运动模糊光线追踪的支持,另一方面更为强悍的FP32性能可以在光线追踪中发挥相当大作用。
                          所谓的软光追、硬光追就很容易理解了。帕斯卡、RDNA1等GPU,由于没有BVH加速单元,在进行光线求交检测的时候,只能对场景里的所有多边形逐个进行遍历。速度毫无疑问是非常慢的,这就是所谓“软”光追。而反之,像图灵、安培、RDNA2等具有BVH加速单元的GPU,则称之为“硬”光追。
                          但严格说起来,根据AMD在光线追踪专利中的描述,AMD和nvidia实现的这种光线追踪,其实都是“混合”方式的光线追踪。由于BVH加速单元的引入,那么势必在GPU上要有一块缓存区存储BVH数据。AMD和nvidia都使用纹理单元的寄存器和缓存来存储BVH数据,所以我们查看架构图,可以发现无论AMD还是nvidia,光线加速单元设置的位置都往往是和纹理单元绑定在一起的。在BVH单元求交的同时,计算单元依然能并行执行其他图形线程。而所谓的“硬”光追,则是不借用现有的任何GPU资源,额外为BVH单独设置缓存甚至是计算单元,这将大大增加现有GPU面积和晶体管,臃肿而低效,完全不会有人这么实现。所以目前的硬光追,已经等同于前文所述的混合式光线追踪。以后遇到相关概念争论,对此要有清晰的认识。


                          IP属地:江苏14楼2020-09-29 02:32
                          回复


                            光线加速单元与纹理单元临近放置。


                            IP属地:江苏15楼2020-09-29 02:35
                            回复
                              MD和nVIDIA在实现光线追踪上都选择了引入BVH加速单元的路子,这并不是什么巧合,其根本原因在于,DXR API中集成了相关命令规范,而AMD和nvidia则需要创建相应的符合规范而且能够执行这些命令的硬件。事实上,目前可以把DXR当作是曲面细分那样的东西,比如基于DX11的曲面细分应该包括Vertex shader、hull shader、Tesselation unit、Domain shade、Geometry shader,所谓shader就是可编程的硬件。AN都必须遵循这个规范,否则你设计出的细分单元将无法执行DX11 API的游戏中曲面细分效果。同时实现顺序也要严格按照这个流程来。NV的曲面细分相关组件叫做polymorph engine,A的曲面细分相关组件我也不知道叫什么,但无论有名字没名字,都要遵循规矩。
                              对于DXR亦是如此。https://microsoft.github.io/DirectX-Specs/d3d/Raytracing.html#ray-generation-shaders微软给出了实现DXR所需要的各种组件,也限定了加速结构为BVH。

                              由流程图我们还知道DXR规定了intersection shader、any hit shader、miss shader、cloest hit shader等,那么AMD、NV就都要根据这个规范做出相应的硬件来实现流程图上这一套东西,这就导致了AMD和nvidia最终用殊途同归的方式实现了光线追踪。


                              IP属地:江苏16楼2020-09-29 02:35
                              回复