[gdc15]《命運》的多線程渲染框架
01-26
更多文章可以看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》就是這樣做的。 在多線程架構上面,這個圖示出來這樣的: 這個主要的問題就是比較死板,對於靈活的情況缺乏適應性,包括:- 跨平台,各個平台上面很不一樣
- 沙盒遊戲的多種遊戲情況,一會人多,一會特效多,一會場景物件多 想要有一個架構,能適應各種情況下,就需要升個級了。
模塊化的渲染架構
渲染數據模塊化
對於一個個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) - 靜態數據(比如場景物件)和動態數據(比如角色)使用不同的處理方法推薦閱讀:
※VRay for SketchUp工業產品表現之煤油燈
※VRay for SketchUp環境阻光(AO)的簡介與應用
※##譯## The Comprehensive PBR Guide by Allegorithmic — Vol.2
※支持導入任意貼圖的maya工具——材質管理器