去年年底的軟體綠色聯盟開發者大會上，華為EMUI和網易宣佈在遊戲《遇見逆水寒》中實現光線追蹤渲染，也就是在手機遊戲上做到實時光線追蹤(ray tracing)運算。這聽起來是件大事，雖然光線追蹤的硬體實現早在上世紀90年代就有了，而且在現在的3D動畫作品與遊戲CG中也常見，但實時(real time)的光線追蹤在桌面PC平臺尚且剛剛開始，手機現在竟然也有了?
遊戲《遇見逆水寒》光線追蹤開啟前後的對比
我們在去年的Imagination新品釋出會報道中曾經提過[1]，Imagination預計將會在2020年的B-Series GPU中加入光線追蹤架構。至少就商業應用來看，GPU的實時光線追蹤在移動平臺的應用還並不能算是眼下的事情。比較有趣的是，2020年伊始，Imagination宣佈蘋果再度與其簽署多年的授權協議，雖然具體獲取的是哪方面的IP我們並不清楚。國外有分析師認為，蘋果可能是對Imagination的光線追蹤技術感興趣。
蘋果A系列晶片的GPU是個黑匣子，我們也無從探究其GPU從硬體層面對光線追蹤支援做到何種程度。在去年的WWDC 2019開發者大會上，蘋果曾經做過一個名為Metal for Accelerating Ray Tracing的主題演講[2]，表明在軟體層面，蘋果已經在做針對光線追蹤的籌備。這個演講的簡介提到，“Metal Performance Shaders利用GPU的大規模並行能力，為當代光線追蹤與光線投射(ray casting)技術計算做加速。”從這樣的描述合理猜測，蘋果的GPU尚未在硬體層面針對光線追蹤做出特別的支援。
那麼《遇見逆水寒》這款遊戲的光線追蹤又是怎麼做到的?是否海思Kirin SoC已經從硬體層面實現了光線追蹤?這是我們期望去理解的問題。由於文章篇幅比較長，非技術愛好者可略過本文的第二、三部分，而僅閱讀第一與第四部分。
光線追蹤有什麼用?
消費電子市場上，推實時光線追蹤技術比較積極的無非就是英偉達(Nvidia)和Imagination兩家公司，分別對應PC端與移動端。這也就成為我們能夠更清晰地理解當代光線追蹤技術發展到何種程度，及其趨勢的視窗。不過在此之前，還是花點筆墨回顧一下，究竟什麼是光線追蹤。
從這種技術能做什麼的角度來說，有了光線追蹤，相對狹義的講，在遊戲或圖形計算相關的動畫中，我們就能看到各種更真實的光線反射、折射、陰影等光影關係。這些反射、折射、陰影需要的因素很多，比如圖形物件的材質，不同材質對光的吸收、反射都是不一樣的，鏡子能夠反射出實物，而大理石地面雖然也有光線反射，但程度與方式有異。另外，光線從光源發出被反射後碰到新的物件還會再次反射或折射、吸收，其複雜程度可見一斑。
就現實生活來看，這似乎是理所應當的。但在過往的3D圖形世界裡，它在外顯方面就只是一種模擬現實世界的特效。而要實現這些效果，是從硬體到軟體中間層，及開發共同努力才可達成的。舉兩個簡單的例子：
來源：Nvidia，遊戲《古墓麗影：暗影(Shadow of the Tomb Raider)》截圖
在上面這個來自英偉達的例子中，光線追蹤(英偉達將自家的光線追蹤技術稱為RTX)關閉與開啟後的區別，這兩張圖的主要差異在陰影的呈現上。在人物腳下，及身體各部位考慮光影關係時，這個場景才顯得自然;如果陰影計算不完整，則人物就像漂浮在畫面中一樣。
來源：Nvidia，遊戲《戰地5(BattleField V)》截圖
如上圖這樣的反射，區別相當顯著，也就不需要多談了。不過實際上，傳統的rasterization(光柵化)方案仍然可以做出反射效果，只是其開發複雜度會明顯更高，且經常會出現缺失，包括處在畫面外的反射並不會加入進來。上面這個場景中，一旦火焰處在螢幕顯示以外的區域，rasterization通常都不會再將其顯現在汽車外面的反射效果中。
在這個問題上比較有趣的一個設想是，玩如主視角射擊競技遊戲時，藉由光線追蹤，如果有敵方在窗戶下方潛行，玩家躲藏在角落位置，從某些視角依然能夠從窗戶玻璃中看到潛行的敵人——這也算是遊戲的技術外掛吧。
來源：Imagination
而在上圖的Imagination示例中，左邊通過常規rasterization方式計算得到的陰影似乎已經算是比較到位了——實際由於rasterization方案流程問題，造就的陰影經常出現各種失真(比如鋸齒)。再加上計算陰影邊緣模糊的效果——這種所謂的半影(penumbra)效果對rasterization來講已經很難。而像右圖這樣陰影的半透明化對rasterization而言又是個難點，但對光線追蹤來說就簡單很多。
用比較簡單的話來說，光線追蹤就是在生成某個3D場景時在某個階段所採用的一種技術，這種技術能夠模擬現實世界中光的行為。而利用光線追蹤，就需要為開發者提供開發工具，並且生產更具真實感的視覺效果。
光線追蹤在電影行業的應用已經非常廣泛了，而電影所需的光線追蹤會用上專業圖形計算工作站，可能花幾個月時間把最終畫面給渲染出來。這對於實時的電子遊戲來說是不現實的，一方面是因為遊戲需要實時地生成每秒至少30幀畫面;另一方面光線追蹤對於圖形計算效能要求也是瘋狂的，過去是不可能用一塊顯示卡就搞定3D遊戲實時光線追蹤的。
如果我們僅從“光線追蹤”字面理解，處理器需要追蹤所有光源發射的光線，並且場景中不同物件表面還會對光源的光進行反射、吸收、折射，而且不同材料表面實現這些效果的特性還不同，成千上萬的光線需要計算。一個ray tracer效能度量因此就要達到每秒數百萬、千萬光線的計算能力，相當於GPU畫素填充率的GPixels/sec級別，以及算力的GFLOPs級別[3]。
這個量級是Imagination在自家有關光線追蹤的白皮書中提到的，它或許還不夠具體。幾年前三星尖端技術研究院(SAMSUNG Advanced Institute of Technology)和幾所南韓、美國的高校曾聯合發表過一篇題為《SGRT: A Mobile GPU Architecture for Real-Time Ray Tracing(為實時光線追蹤設計的一種移動GPU架構)》的paper[4]，其中提到“在720p解析度下，實時光線追蹤(30fps)的實際應用，要求的效能至少是300Mrays/s(單精度要求大約1-2TFLOPs)。”現在的手機GPU即便全速跑，與此都還有比較大的差距。
這個資料當然可能並不絕對，而且並沒有標明更具體的計算環境和要達成的目標。但似乎要讓現在的手機GPU硬跑光線追蹤，難度還實在是頗大的。
如果我們拋開光線追蹤對算力的貪婪需求不談，光線追蹤能夠實現的特性並不僅限於遊戲，更高階的應用是AR(現實增強)。比如像上面這張圖片，原場景是用攝像頭實拍的，AR則在場景中加入了一輛汽車。要讓這輛汽車更真實，就必須讓汽車在光影方面融入到場景中去。當然這種應用的要求就比較高階了，因為相機需要分析場景的光分佈，考量各種光線因素後加入到虛擬汽車的渲染中去。
除此之外，可暢想有關光線追蹤的應用也與汽車電子相關——環視攝像頭收集資料所呈現的畫面，將光影也考慮進去，那麼中控板顯示的畫面不僅更真實，而且也易於進行障礙物距離的估計和判斷。
主流的光線追蹤實現
相對硬核的3A大作玩家應該很清楚，前文提到的這些反光、陰影、折射等效果，並不是光線追蹤特有的。前面提到的rasterization(光柵化)有時也能達到這樣的效果。那麼我們就不妨簡單地談一談，什麼是rasterization，以及光線追蹤又是怎麼回事。
Rasterization光柵渲染的過程，本質上也是一種將3D物件在2D螢幕上顯示出來的技術。3D物件就是一堆三角形或多邊形，構建起的不同形狀、大小。三角形的角或者頂點，包含了很多資訊，包括它在空間中的位置、色彩、貼圖、法線等。而3D模型的這些三角形，要顯示到螢幕上，則最終都需要將其轉化為畫素。這就是rasterization的過程。每個畫素都會分配一個初始色彩值——這個值來自於三角形頂點中儲存的資料。畫素隨後還會得到進一步的處理或者shading(著色)，比如說基於場景中的光源來改變其色彩，並且應用一個或更多貼圖，最終生成畫素色彩。[5]
這是比較簡單的一個形容方式。Rasterization如果只從GPU渲染所處的階段來看，它位於比較靠後的位置。而這個大步驟還可以分成很多細緻的處理階段，包括三角形設定、三角形遍歷，以及畫素著色、輸出合併。
實現最後一步輸出合併(Output Merging)的功能單元叫ROP(Raster Operation Units，光柵化處理單元)。這一階段根據z-buffer(深度buffer，z座標的深度值)存放的深度資訊，判斷是否需要更新色彩buffer中的色彩值——說白了就是判斷場景中物件的可視性(visibility)，比如某個物件是否被另一個物件遮擋(在畫素級別)，以此判斷是否需要更新當前畫素的buffer，以及再去計算相應圖元(primitive)的色彩，並更新buffer作畫素著色。[6][7]
為達成更加逼真的效果，對畫素進行著色是需要考慮其“上下文”或者說所處的具體環境的。比如說光來自哪裡，光是否被其他表面遮擋或反射等等。Rasterization方案的問題在於，它並不擅長去做這種上下文考量，而是孤立地去計算每個三角形，於是很難達成錯綜複雜的光影效果。所以rasterization本身還需要搭配更多複雜的方案來實現模擬現實世界的高階效果。
來源：Nvidia
左上圖是rasterization應用傳統陰影貼圖後的效果，看起來似乎還不錯，但它對陰影邊緣的模糊處理過於一致，其contact hardening實際上是有問題的;而後面幾張光線追蹤達成的陰影不需要應用陰影貼圖，可模擬更自然的陰影contact hardening，這幾張應用了不同的錐角
比如對陰影的處理，就rasterization來看，需要從每個光源的視角作渲染，再儲存到紋理(texture)中，然後在lighting階段(應該是幾何處理的頂點著色階段)將其再投射到場景自身。絕大部分光柵化過程還需要支援某些特定的陰影貼圖型別，比如說針對全向光的立方體貼圖陰影(cubemapped shadows)，針對大型戶外場景的層疊陰影(cascaded shadows)[8]。為消除陰影的接觸硬化(contact hardening)問題，raterization還需要應用PCSS(Percentage Closer Soft Shadows)和Distance Field Shadows這樣的技術，但這些技術同樣存在應用場景的侷限性，如PCSS不僅算力需求很大，而且無法針對任意區域光生成完全正確的陰影。
這些附加的方案不僅對算力、頻寬、功耗都提出了更高的要求，而且增加延遲。更重要的是，它們極大增加了複雜性，效果還並不見得很理想。這其實是在光線追蹤同樣對算力要求很高的情況下，讓rasterization越來越失去吸引力的一些原因。光線追蹤對開發者而言也會明顯更友好和簡單。
那麼光線追蹤又是怎麼一回事呢?籠統地說，就是以遵循自然規則的方式，模擬場景及物件光照，正確渲染反射、折射、陰影及間接光照等。不過現在比較主流的光線追蹤演算法並不是從光源的視角出發，去“追蹤”每一縷光線的，而是完全逆向的，從我們的觀察視角出發。
假想有一臺攝像機在對著3D場景拍攝，發射出一條ray(線)，這條ray首先從這臺攝像機出發，通過2D視覺平面(也就是螢幕對應的畫素平面 )，進入到3D場景中，這條ray會打到場景中的物件表面，最終能夠追溯光源。
在這個過程裡，ray可能從一個物件反射到另一個物件，則形成反射;或者被某個物件阻擋，則形成陰影;也可能穿過透明或半透明物件，就形成折射。物件表面與ray相交的點就有了相應的色彩、照明資訊，這樣一來ray穿過的畫素也就有了色彩和亮度等級資訊。
這種“逆向追蹤”的方案要比從光源多角度正向追蹤高效很多。即便如此，它對算力的需求也是非常貪婪的，這與進入場景中的ray數量有很大的關係，而且還要考慮反射、折射生成更多的ray(所謂的衍生ray)。至於要向場景中“發射”多少ray，則需要考量光線追蹤物件的型別數量、GPU的處理能力、螢幕解析度，以及發射通過每個畫素的ray有多少個。
在具體實現上當然還有不同的技術和優化方案，用於加速ray與圖元相交的檢測，以及儘可能減少ray的數量。因為如果真的考察場景中每個ray與每個圖元的相交，現有技術的硬體資源還是不允許的。所以就誕生了像是Bounding Volume Hierarchy(BVH，包圍盒層次)這樣的加速結構。
這裡簡單地談一談這種BVH技術。BVH是一種樹形結構，包括了很多層級結構的包圍盒子。這些盒子自身包圍、或者環繞著不同量的場景幾何體。越往外部的包圍盒，也就包含更多的圖元;更小的包圍盒則包含更少量的幾何體。上面這張圖展示的就是BVH結構，更大的包圍盒在樹形結構中就是更高層級的節點，再向下遍歷更小的盒子。每個節點都被一個包圍盒包圍，它們自身又包圍很多子節點及其包圍盒。
每個ray都應用BVH結構——整個流程首先是針對這條ray，檢測根節點包圍盒(root node bounding box)，從上圖來看就是兔子頭，用一個比較大的包圍盒根節點套住的;隨後按照樹形結構檢測子節點，也就是後續哪些包圍盒與受測的ray存在相交關係。
採用這種方案進行ray與圖元相交檢測，能夠極大減少工作量。不需要檢測ray與場景中每個圖元的相交，而僅需檢測明顯更少量的、樹形結構中每個層級的包圍盒，直到相應的ray最終抵達末端節點(包含三角形圖元)。
另外在首次渲染場景之前，就需要構建BVH結構(BVH building)。很多情況下，畫面這一幀與下一幀的變化並不會特別大，那麼基於這些變化修改現有BVH結構(BVH refitting)，也不需要構建全新的BVH結構——就能節約計算資源。[9]
鑑於篇幅的關係，這裡不再介紹有關光線追蹤的更多技術。實際上，從英偉達和Imagination介紹光線追蹤的白皮書來看，仍有另外一些比較重要的配套技術也在光線追蹤的實現中起到重要作用，例如Denoising Filtering(去噪過濾)——大幅提升噪聲比較重的畫面的畫質，尤其著眼於減少光線追蹤影像渲染的時間。
那麼GPU是怎麼做的?
英偉達是在2018年3月宣佈推出自家的RTX實時光線追蹤技術的[10]：除了為Volta及後續GPU提供光線追蹤加速，還有針對開發者的光線追蹤加速工具，尤其是配合微軟的DXR(DirectX Raytracing)API支援(後續也有了Vulkan支援)。實際在更早的時間英偉達就有類似Iray外掛、OptiX光線追蹤引擎之類的工具提供光線加速渲染——不過那是非實時的。
去年3月，英偉達又宣佈通過驅動升級，已經在市場上銷售的部分GTX系列顯示卡(Pascal架構)也能獲得實時光線追蹤技術支援[11]。這至少表明，即便沒有Volta架構的張量核心，以及現在專為RTX技術及顯示卡打造的RT光線追蹤核心，實時光線追蹤效果依然可以在過去的老顯示卡中得到實現，只要GPU的通用計算單元夠強。
只不過實時光線追蹤怎麼說都還是對算力要求十分飢渴的技術，所以這種“軟體”實現方案會受到諸多限制，比如針對支援光線追蹤的遊戲，更早的GTX顯示卡能夠以比較低配的方式支援《戰地5》的反射效果，但無法支援《Metro Exodus》遊戲中更復雜的全域性照明(global illumination)。所以更復雜的光線追蹤特效，仍然是需要最新的Turing架構(RTX系列顯示卡)才行的。
那麼像Turing這種特別針對光線追蹤技術做加持的架構，在硬體層面有什麼特別呢?實際從英偉達和Imagination兩家的實施方案來看，目前已有實時光線追蹤的硬體實現還是比較相似的。
當某種技術實現起來，對計算、存取要求很高，而且對這種技術的使用很頻繁時，通常就應該考慮專有加速硬體或單元，以實現算力與效率的雙重快速提升。英偉達針對Turing的光線追蹤加速，引入了一種名為RT核心的專用硬體單元，每個SM(Streaming Multiprocessor)都包含有RT核心。它的作用就是加速前文提到的BVH遍歷，ray和三角形的相交檢測運算，以及去噪過濾等。
RT核心會自動去遍歷BVH盒子;包括BVH building, refitting一類函式都由驅動去處理;ray的生成和著色(shading)工作則通過shader單元來完成。
在沒有專用加速硬體的情況下(比如GTX顯示卡)，BVH遍歷的過程主要就是shader操作執行的，針對每個ray都要承載上千個指令slot，對包圍盒相交做檢測直到最終獲得畫素色彩值。所以如果是一個完整的場景的話，僅是這樣的光線追蹤工作，就已經讓一般的GPU算力資源無力招架了。
Turing架構的RT核心則是專門幹這活兒的，這種專用核心包含了2個單元，其中一個進行包圍盒檢測，另一個則執行ray與三角形相交檢測，那麼SM的其他硬體就能用於其他圖形計算任務了。
英偉達自己對比兩種方案的算力時提及，較老的Pascal“軟體模擬”方案達到的效能水平是大約1.1 Giga Rays/Sec(每秒十億ray)或者10 TFLOPs/Giga Ray(每十億個ray的每秒浮點運算次數);而Turing有了RT核心，則能夠達到10+ Giga Rays/Sec，在光線追蹤方面快10倍。這兩個值具體對比的是GTX 1080Ti和RTX 2080Ti顯示卡。
Imagination光線追蹤專用的RTU單元
Imagination的光線追蹤專用硬體實現似乎還要早，可以追溯到PowerVR Series6時代，那會兒的GPU架構名為Wizard。Imagination好像在2014年或者更早就開始著眼光線追蹤了[12]。當時的PowerVR GPU就已經包含了一個專門用於光線加速追蹤的RTU單元(Ray Tracing Unit)。而且當時Imagination也針對遊戲開發者，著眼在了OpenGL ES擴充套件;不過似乎在那個時候，實時光線追蹤還太過超前，尤其對於移動平臺而言。
RTU內部包含一個SHG(Scene Hierarchy Generator)，用於生成BVH資料結構。這個硬體單元似乎是Imagination獨有的，英偉達則並未在Turing的白皮書中提及BVH資料結構生成由誰完成。按照Imagination的說法，SHG也因此對於動態幾何體的光線追蹤，有了更為高效的支援——結合前文對於BVH結構構建的內容，似乎的確如此。另外，我們猜測這也可能與PowerVR著力於移動低功耗市場有很大關係。
此外，從上面的圖中還能看到一個可選的“Ray Coherency Engine”引擎。一般ray在打到3D場景中的絕大部分型別材質上時，就會隨機散射開。它們分散前往不同的方向，與不同的三角形相交。Imagination認為，這對於儲存訪問的效率不利，所以Coherency Engine是要發現ray之間的共性，並將其分組，以提升效率。這可能也是在移動平臺降低功耗的一種方式。
Imagination在宣傳資料中說，早年的Wizard SoC執行功耗僅2W，而當時的demo板也就10W，頻率為600MHz，峰值算力為300MRays/Sec。看起來在算力上與英偉達的桌面GPU仍然是有量級差距的，不過Imagination在效率上還是有優勢，畢竟兩者的定位是不同的。
這部分的最後值得一提的是，就目前的算力水平來看，rasterization與光線追蹤還不是相互替代的關係。至少英偉達與Imagination的策略都是讓這兩者在GPU計算中並存，名為“混合渲染管線”，畢竟光線追蹤的算力要求還是太高了。Rasterization在判斷物件可視性方面，利用z-buffer仍然很快，另外還能承擔光線追蹤流程中的一些工作階段(primary ray casting stage);而光線追蹤則用於發射secondary ray，用於實現正確的反射、折射和陰影。
似乎rasterization仍然是構成場景的主要組成部分，所以並不能說光柵渲染已經要淘汰。
所以《遇見逆水寒》的光線追蹤是?
就我們查閱的資料來看，除了英偉達和Imagination之外，其他主要的市場參與者還沒有或者說尚未完全在硬體層面對實時光線追蹤做專門的支援，包括AMD、Arm等，高通的Adreno在PBR支援上似有在最新的產品中初露端倪。這可能與不同GPU廠商的發展策略，及其GPU渲染架構本身的特性也有關。
至少在海思Kirin SoC的Mali GPU，以及近代Arm的Bifrost架構中，並沒有看到特別針對光線追蹤的專用硬體加速單元出現。就英偉達與Imagination指出“軟體模擬”的光線追蹤方案，利用shader進行計算，猜測就是華為在《遇見逆水寒》中實現光線追蹤特效的方案。它能夠部分應用光線追蹤來模擬陰影、反射、折射等特效，但考慮到移動平臺的功耗與算力限制，加上又是GPU的通用計算單元執行的，效果應該會相對簡單。
所以實際的聯合釋出方是華為EMUI，與海思和Kirin晶片、Mali GPU大概是沒有什麼關係的。不過即便是軟體層面，即具體應用的推進，對於光線追蹤技術的發展也有相當大的作用。
Imagination已經在對外提供光線追蹤相關的IP授權;去年的GTC China大會上，黃仁勳還演示了光線追蹤版的《我的世界》，相比原版的確提供了更加美輪美奐的遊戲畫面[13]。大概實時光線追蹤在民用圖形計算世界的普及也只是時間問題了。
[1]剖析Imagination的A-Series GPU新架構：和高通Adreno和Arm Mali比比 - EE Times China
[2]Ray Tracing with Metal - Apple Developer
[3]Shinig a Light on ray tracing - Imagination
[4]SGRT: A Mobile GPU Architecture for Real-Time Ray Tracing
[5]Ray Tracing - Nvidia
[6]移動圖形晶片的故事（上）GPU是什麼鬼？ - Evolife.cn
[7]GPU Rendering Pipeline——GPU渲染流水線簡介 - Computer Arch
[8]Hybrid rendering for real-time lighting: ray tracing vs rasterization - Imagination
[9]NVIDIA TURING GPU ARCHITECTURE - Nvidia
[10]NVIDIA Annouces RTX Technology: Real Time Ray Tracing Acceleration for Volta GPUs and Later - AnandTech
[11]Nvidia bringing new ray tracing tech to GTX graphics cards - Polygon
[12]PowerVR GR6500: ray tracing is the future… and the future is now - Imagination
[13]NVIDIA的5年黃金時光，這“不是一家晶片公司” - EE Times China
責編：Luffy Liu