shader LOD快速生成具體是種怎樣的技術？

A System for Rapid, Automatic Shader Level-of-Detail 添加評論  分享 按投票排序 按時間排序

4 個回答

贊同55 反對，不會顯示你的姓名

Yong He ， CS PhD student 翟佳龍、王宇翔、知乎使用者  等人贊同 謝邀。關于shader程式自動簡化并不是什麼新鮮的事情，之前已經有一些系統做到，例如Wang等人的Siggraph Asia 2014 paper " Automatic Shader Simplification Using Surface Signal Approximation". 

我的這篇文章試圖解決的一個問題是如何快速地簡化一個shader, 并且決定要在什麼時候（以及是否值得）用某個簡化過的shader。為什麼要強調快速？因為遊戲開發的時候一個artist或者developer要建立大量的shader，你自動生成了一堆簡化的版本，開發人員總要看一下是否合适并且以此疊代開發。在此之前所有類似的系統都采用了幾乎是暴力搜尋的方法來發現可以簡化的地方，是以編譯時間非常長（簡化一個shader需要花費幾個小時的時間）。

是以我的這個work主要要實作的目标是實作一個編譯器以很快地自動簡化shader，并且作為一個開發人員你能夠認同編譯器自動實作的簡化（也就是編譯器産生的簡化後的shader跟人肉産生的差不多）。

為了實作這個目标，我們首先必須要讓編譯器可以做更多的事情。之前的文章提到了可以把shader code在vertex shader和fragment shader之間移動。但這其實還不夠。我們引入了一個叫做Parameter Shader的東西，這是一個在CPU上執行的shader階段。這樣一來我就可以在執行draw call之前，在CPU上先算好一些東西直接傳給GPU而不用在GPU上算。為什麼需要這個額外的階段呢？比如說你現在有一個很複雜的shader在fragment shader裡面計算各種細節，然而這些細節到了遠處就都看不到了，是以一個很自然地優化是去掉這些細節并且把它替換成一個常數。但是究竟替換成什麼常數呢？在編譯期間并不能确定，是以就搞一個parameter shader的東西，在運作的時候一旦shader的各項參數确定了，我就運作一下把這些可以變成常數的量算出來當作uniform 傳給後面的GPU階段。此外編譯器還實作了一種新的code優化，叫做Approximate Common Sub-Expression Elimination，具體細節不說了，意思就是如果編譯器發現兩個expression算出來的值很接近，不管他們是不是真的symbolically equivalent，仍然考慮将一個表達式替換為另外一個表達式。

有了這些編譯器可以執行的簡化操作，剩下的就是如何快速的發現可以apply的簡化操作。之前的文章都是使用一些stochastic search或者genetic programming的方法，這些都是很慢的。這篇文章講了一個基于profile和heuristic based的貪心政策直接發現簡化操作，這樣編譯器就能在一分鐘之内完成并生成出很好的結果，而不需要運作幾個小時。

時間比較緊，現在還在準備兩周後的SIGGRAPH Asia Talk, 是以就隻寫這麼多了。 編輯于 2015-10-23  1 條評論  感謝  分享   收藏  •  沒有幫助  •  舉報   •  作者保留權利 贊同9 反對，不會顯示你的姓名

大薩比 ， SE遊戲引擎工程師 Charlie、Juude、羊肉泡  等人贊同 正好在現場聽了這個講座。前天siggrapg asia 2015的course，今天剛回來。

這個研究是nvidia，bungie贊助和協同研發的。起因是現在的遊戲shader數量龐大至十幾萬¹個(尤其是node based shader系統)。人工做lod幾乎不可能，于是提出了自動優化工具。

比如：

x=a+b 簡化成 x=a

x=sin(a) 簡化成 x=a

texture sampling 簡化成 constant

簡化是基于profile，對每條指令進行評估，最後通過評價最終性能和誤差決定簡化政策是否有用。

具體實作手法看paper， @Yong He 本人也有解釋。

私貨感想：在應用和工程的角度看耗費如此人力物力開發這種自動化工具是否合算有待商榷。罪魁禍首是把shader的控制權交給artist的錯，node base的弊端在此顯現。如果從一開始shader是程式員可控的話不需要如此繁雜。另外現在的遊戲計算最複雜的是光照系統，簡化了十幾萬個shader也就提升了gbuffer的渲染時間和部分forward渲染。反而又增加了幾十萬shader，記憶體，加載時間，編譯時間(開發效率)，QA怎麼辦？技術本身沒錯，離實際應用還是有距離的吧。

¹Destiny:16000個shader 編輯于 2015-11-06  1 條評論  感謝  分享   收藏  •  沒有幫助  •  舉報   •  禁止轉載 贊同5 反對，不會顯示你的姓名

錢康來 ， 五道口技工學院 c++苦手 rendering磨練中 高歌、Charlie、知乎使用者  等人贊同 上周剛讀了這篇文章，當時第一反應是想到了sa2011的一篇  virginia.edu 的頁面

還有一篇  Automatic Shader Simplification Using Surface Signal Approximation (話說我有寫郵件聯系過作者，看看能不能要到可執行程式，不過...TAT)

最常見的LOD政策是簡化模型，但這篇文章提供了簡化shader的技術，從另一個層面降低消耗~

從最廣義的來說，思路和别的程式自動優化一樣(評估函數+程式變體政策)，但針對Shader又和普通的代碼有所不同。這個文章提出的新變體政策很有意思~ 

擺碗坐等ing

其實你可以  @Yong He 來着... 編輯于 2015-10-22  添加評論  感謝  分享   收藏  •  沒有幫助  •  舉報   •  作者保留權利 贊同4 反對，不會顯示你的姓名

叛逆者 ， GPU Gems 2譯者，圖形專家 高歌、知乎使用者、知乎使用者  等人贊同 @Yong He 的大作，當然應該問  @Yong He 了。

我還沒看paper，隻是看了video。基本上，就是個shader簡化系統。随着lod的增加，自動去掉shader裡的進階渲染功能，達到降低遠處物體計算量的目的。順序是，height/normal texture->roughness texture->abedo texture->constant color。