去年，NVIDIA 基于?Ada Lovelace 微架構(gòu)的?RTX 40 系列顯卡發(fā)布，它的光線追蹤和 DLSS 性能大幅提高。附帶的 Tech Demo 有 Racer RTX（未發(fā)布）以及被更多人關(guān)注的 Portal RTX.?

因為配置需求問題（注意：我說的不是“優(yōu)化”而是“配置需求”）所以被口誅筆伐，包括我：

我們來看這樣一組資料，這是 NVIDIA 官方給出的 Portal RTX 顯卡要求：

要想滿足 1080p 60幀，你至少需要一塊 RTX 3080（并且是開啟了 DLSS），這是非常令人憤怒的配置要求，NVIDIA 似乎是在對待仇人一樣推出了 Portal RTX.

不過，一味抨擊只會讓自己不快樂。我們不如坐下來思考，這是怎么會是呢？

接下來就是文章的重點了：

Portal RTX 并不優(yōu)化差，相反地，優(yōu)化比較好。

絕大多數(shù)玩家沒有學習過實時渲染，不知道光線追蹤對性能開銷的影響具體是什么樣的。尤其是像 Portal RTX 這類大規(guī)模使用光線追蹤算法的游戲，很容易直接被打入渣優(yōu)化范圍。

光線追蹤，現(xiàn)在更為廣泛的做法叫“路徑跟蹤”，本質(zhì)上是以一種無偏估計方法求解渲染方程。這里只放出模型表達式，推導(dǎo)什么的說了您也懶得看。

您會發(fā)現(xiàn)每個著色點我都要考慮一大坨定積分以及雙向反射分布，這樣的計算量是極其龐大的。相比 Portal 小打小鬧的 Blinn-Phong 模型，就算是您連求和符號都看不懂，都能看出這計算量的差異。

比這個更要命的是可見度計算。傳統(tǒng)光柵化渲染管線使用 Z-Buffer 算法計算可見度，這是一種很簡單的算法，而光線追蹤需要通過生成大量光線與場景包圍盒以及三角形進行求交計算。

因為這個流程比較固定，AMD 和 NVIDIA 各自在他們的光追單元上加入了求交加速器。

這里，學術(shù)界已經(jīng)提出了很多加速算法，例如 BVH（層次包圍體積）結(jié)構(gòu)，一般我們選擇采用軸對齊包圍盒（AABB）來包圍場景。這樣一通操作下來可以讓時間復(fù)雜度從 O(n) 降低至 O(logn). 但是就算是這樣，對于目前的 GPU 算力來說，還是太難了。

而 Portal RTX 的問題在于，它的光線追蹤有點太純了。

還有一種說法是使用了 4 次反彈造成的，實際上這是錯的。因為你可以自己調(diào)整，然而就算是調(diào)整到 2 次反彈，性能還是沒法看。

以往的光線追蹤游戲，一般使用使用 DDGI 等方法記錄輻照度信息，直接光照甚至直接使用傳統(tǒng)渲染模型?；蛘咧话l(fā)射用于陰影計算的 shadow rays，預(yù)計算全局光信息利用球諧函數(shù)來解碼輻照度。

而 Portal RTX 從可見度計算到輻照度信息計算都是通過光線追蹤完成的。但是這樣的例子也不是很罕見，比如 Quake 2 RTX 與 Minecraft RTX 等。

問題是，為了保證降噪 input data 的數(shù)據(jù)質(zhì)量，NVIDIA 在 Portal RTX 上應(yīng)用了一種基于空間重要性重采樣的全局光照技術(shù)。

這是一篇發(fā)表于 2021 年 Eurographics 的論文里截的概述：

就算是看不懂，您也能看出一些端倪：

這是一篇 2021 年的論文，這意味著這項技術(shù)從學術(shù)界落地到工業(yè)界僅僅只用了兩年不到。

所以某種程度上您可以直接得出結(jié)論了，Portal RTX 根本不是游戲，這是一個面向大眾的研究成果展示。

不過從另一方面思考，在這么短的時間內(nèi)落地，對開發(fā)者的要求是很高的。加上要把 Portal RTX 這樣大規(guī)模使用光線追蹤做出來，已經(jīng)很了不起了。

所以，在此我向 NVIDIA Lightspeed Studio 的所有工程師們致以最崇高的敬意。

最后，

So, NVIDIA fxxk you.