[gdc15]《命運》的多線程渲染框架

更多文章可以看csdn的安柏霖遊戲開發的專欄

原文鏈接

gdc15（原名《Destiny』s Multi-threaded Renderer Architecture》），業界老兵娜姐（Natalya Tatarchuk）帶來。

232頁的ppt，真是給跪了。

sum

頗為欣賞的一個presentation，在《destiny》中把render architecture提升了一步，對比《halo:reach》更加的job化和data driven。

最後能在四個複雜平台（ps3,ps4,xbox360,xbox1）上高質量的發布，以及擁有良好的擴展性，其戰鬥力可見一斑。

也是行業里為數不多的，深入詳細講解渲染pipeline設計的好文章。

傳統的渲染架構

這個應該說是大部分的遊戲引擎的渲染框架，在bungie，其《halo：reach》就是這樣做的。

在多線程架構上面，這個圖示出來這樣的：

這個主要的問題就是比較死板，對於靈活的情況缺乏適應性，包括：

• 跨平台，各個平台上面很不一樣
• 沙盒遊戲的多種遊戲情況，一會人多，一會特效多，一會場景物件多
  想要有一個架構，能適應各種情況下，就需要升個級了。

模塊化的渲染架構

傳統的流水線可以使用「固化」來形容，destiny的是以模塊化的方式來形容。

典型就是樂高的組織方式。

實際中這種模塊化的組織方式或者說視角，在近幾年的cinematic, animation以及現在這個渲染pipeline設計中都出現了這樣的情況。

處理的方式很像pc主板上的模塊化方法，圍繞「標準化」來進行。

渲染數據模塊化

對於一個個render object來說，destiny定義了幾個標準化介面和階段包括

- extract

- prepare

- publish

- submit

等階段（介面），在其中實現各自的功能。

以cloth為例

這個render object隸屬於一個角色（game object），

- extract：這個階段就是抽取最小的渲染需要的數據集輸送給渲染模塊，在主線程

- 會在extract階段做visibility test

- 所謂的抽取，是一個copy的過程，可以使用ring buffer等來管理

- prepare等就是一些準備工作，可以自己定義一些事情，這裡已經在渲染線程了，可以和下一幀的計算並行起來。

- 後面的publish和submit都是一些既定的介面，可以讓數據模塊和具體的和渲染pipeline的模塊交互結合。

pipeline模塊化

整體渲染模塊分了這麼幾級：

- frame–整個一幀

- view–玩家視角，shadow視角等等

- stage–一個view中不同的渲染過程，比如玩家視角有gbuffer，lighting，postfx階段

- featured renderer–具體的一個renderer，比如渲染decal，terrain等等

在featured renderer這個層面，就可以以job的方式做組織和多線程執行了。

render obj和render pipeline的結合

兩個都是模塊化的，結合的過程就是一個註冊，然後介面調用的過程，非常的靈活方便。

然後在featured renderer這個級別去job化。

這個job，可以是cpu上的多線程，也可以在ps3上這種去spu做，比較小的力度，取捨以及跨平台都提供了良好的基礎。

pipeline sum

其實要說這套有多麼革命性，就完全談不上，在我看來，的確是把概念理得更清晰了。

destiny能把如此複雜的遊戲，在4平台上弄好，這個真心厲害。

反向推之，面對這樣的平台差異性和遊戲多樣性，這樣的設計才是合理的。

再說回來，遊戲沒那麼複雜，以及平台跨度沒那麼大，使用簡單的pipeline也是完全合理的，job系統概念很酷炫，但是對於問題定位等都設定了很高的門檻。

優化

作為業界老兵，可以說所有的優化套路都用到了。

- 非常清晰的運行視圖，這個放在第一條，在我看來，是比所有優化方法都重要的呈現方式，程序員對於整體有足夠清晰的概念是最重要的

- 先做visibility test在做數據抽取，這個和常規遊戲在渲染線程，對於render object合集（統稱scene graph）要更給力一些。

- 一些基本原則

- minimal data&cache friendly

- 渲染數據和邏輯數據分離

- data driven的數據和pipeline模塊設計概念

- 宏觀視圖，防止cpu和gpu的idle（starvation）

- 靜態數據（比如場景物件）和動態數據（比如角色）使用不同的處理方法
推薦閱讀：