梗概

SALVIA 0.5.2 的優(yōu)化經(jīng)歷是一個(gè)“跌宕起伏”的過程。這個(gè)過程的結(jié)果很簡單：

在Core 2 Duo T5800(2.0GHz x 2)上，Sponza的性能提升了60%，ComplexMesh性能提升了26%。

背景

SALVIA的整個(gè)渲染流程主要是以下幾部分：

• 根據(jù)Index Buffer獲得需要進(jìn)行變換的頂點(diǎn)；
• 將頂點(diǎn)利用Vertex Shader進(jìn)行變換；
• 將變換后的頂點(diǎn)，輸出成若干個(gè)float4；
• 將三角形光柵化。SALVIA的光柵化是將三角形拆分成4x4的像素塊若干，不滿的塊有掩碼來處理；
• 將像素進(jìn)行插值；
• 插完值后把像素送到Pixel Shader中處理一趟；
• 處理完的結(jié)果用Blend Shader塞到Back buffer里面去。

用于測試的場景：

• Sponza 26萬個(gè)面，20個(gè)左右的Diffuse紋理（1024x1024）；
• PartOfSponza 約200個(gè)面，4個(gè)Diffuse紋理（1024x1024）；
• ComplexMesh 兩萬個(gè)面，無紋理，有個(gè)能量保守的光照。

最初的版本（V1231）中，性能的主要瓶頸在插值階段，各種耗時(shí)林林總總占了一半以上（50% - 70%）。

相比之下其他階段對性能的影響要么有限，要么沒有多少優(yōu)化空間。所以最近一周的優(yōu)化，就都集中在了“插值”上。

插值算法

線性的插值算法常見的實(shí)現(xiàn)有兩種，

第一種是拿UV插值，第二種是用ddx和ddy累積。

UV是先計(jì)算像素的u和v（基本方法是用面積比，不記得就復(fù)習(xí)一下中學(xué)幾何吧），然后用插值公式：

pixel = v0 * u + v1 * v + v2 * (1-u-v)

后者的步驟是選一個(gè)主頂點(diǎn)，然后計(jì)算這個(gè)頂點(diǎn)的ddx和ddy，最后用

pixel = v0 + ddx * offset_x + ddy * offset_y

計(jì)算出相應(yīng)頂點(diǎn)。

但是在圖形學(xué)中，我們還需要對插值進(jìn)行透視修正，獲得在3D空間中線性的插值結(jié)果。

我們將步驟修正到透視空間：

先將v0，v1，v2弄到透視空間中，變成projected_v0, projected_v1, projected_v2

對于UV的插值是

pixel = ( projected_v0*u + projected_v1*v + projected_v2 * (1-u-v) ) / pixel_w

對于用ddx和ddy的累積公式是：

pixel = ( projected_v0 + projected_ddx * offset_x + projected_ddy * offset_y ) / pixel_w

插值算法的選擇

何詠（Graphixer）大神之前也寫了一個(gè)渲染器，比我快許多（大概是4-6倍），用的是UV；

gameKnife大神兩個(gè)禮拜寫成的渲染器，速度比我用五年寫出來的半成品要快7倍，用的辦法是Lerp到Scanline上，再Lerp到像素。

SALVIA采用了累積法：

struct transformed_vertex { float4 attributes[MAX_ATTRIBUTE_COUNT]; };

transformed_vertex projected_corner;

// 計(jì)算角點(diǎn)的坐標(biāo)
projected_scanline_start = projected_v0 + projected_ddx * offset_x + projected_ddy * offset_y; 

// 像素的透視修正值
float inv_w; 

// 最終輸出的4x4個(gè)像素
pixel_input px_in[4][4];

for(int i = 0; i < 4; ++i)
{
  projected_pixel = projected_scanline_start;
  for(int j = 0; j < 4; ++j)
  {
      // 透視空間轉(zhuǎn)換到線性空間并輸出到px_in中
      px_in[i][j] = unproject( projected_pixel );
     // 累加x方向上的值（透視空間）
      projected_pixel += projected_ddx;
  }
  // 累加y方向上的值（透視空間）
  projected_scanline_start += projected_ddy;
}

本輪優(yōu)化之前對插值算法的優(yōu)化嘗試

注意那個(gè)MAX_ATTRIBUTE_COUNT，這個(gè)值通常比較大，在v1231中，它是32。

不過，顯然我們不需要對所有的屬性進(jìn)行計(jì)算。敏敏在這里運(yùn)用了一點(diǎn)小小的技巧進(jìn)行了優(yōu)化：只計(jì)算必要的屬性。同時(shí)，為了減少分支的使用，他甚至用

template <int N>
void sub_n(out, v0, v1 )
{
    for(int i = 0; i < N; ++i) {
       out.attributes[i] = v0.attributes[i] – v1.attributes[i];
    }
}

并配合函數(shù)指針的方法，以促使編譯器展開循環(huán)，減少分支。

不過從實(shí)際生成的匯編來看，這個(gè)部分并沒有被展開到期望的形式，可能是編譯器認(rèn)為x86的Branch Predication性能已經(jīng)足夠高了吧。

這個(gè)“優(yōu)化”在v1231中就已經(jīng)具備了。

首輪優(yōu)化：unproject函數(shù)，operator += 與 operator =

第一個(gè)Profiling是用BenchmarkPartOfSponza和Sponza跑的；unproject，operator +=和operator = 加在一起大約占用了15-20%的時(shí)間。單獨(dú)的unproject

最初的實(shí)現(xiàn)就是普通的標(biāo)量。既不要求對齊，也沒有使用SIMD。

所以當(dāng)然會(huì)以為用了SIMD后，優(yōu)化效果會(huì)很好。于是在v1232中，中間頂點(diǎn)和像素輸入的分配都以16字節(jié)對齊，unproj，+=和=也都使用了SSE進(jìn)行了重寫。

從跑分來看，PartOfSponza性能提升了20%。但是，在測試ComplexMesh和Sponza時(shí)，并未發(fā)現(xiàn)幀率有顯著提升。

其實(shí)在進(jìn)行優(yōu)化之前，何詠就告誡過我，因?yàn)楝F(xiàn)代CPU的一些技術(shù)，比方說超標(biāo)量啥的，四個(gè)數(shù)據(jù)寬度的SSE和標(biāo)量運(yùn)算相比，就只有50%的性能差距。

并且這些函數(shù)的指令已經(jīng)極為簡單，瓶頸也很明確的落在計(jì)算指令上。例如Unproject優(yōu)化后，性能焦點(diǎn)就落在_mm_mul_ps上（3.7%），幾無優(yōu)化余地。

二輪優(yōu)化：插值算法的調(diào)整

在進(jìn)行第二輪優(yōu)化之前同樣運(yùn)行了一次Profiling。因?yàn)閷artOfSponza性能基本滿意，因此這次優(yōu)化的目標(biāo)主要在Sponza上。

排名前幾位的小函數(shù)，分別是sub_n，unproj，+= 和tex2D。對sub_n例行優(yōu)化后，性能沒什么變化。當(dāng)然，這也是意料之中的事情了。

因此，第二輪優(yōu)化便著重考慮在插值算法本身上。

在優(yōu)化之前，我嘗試對代碼成本做個(gè)粗略的評估：

在現(xiàn)有算法下，假設(shè)每個(gè)像素有N個(gè)需要插值的屬性，則平均每個(gè)像素有

（corner）3N/16個(gè)讀 + 2N/16個(gè)乘法 + 2N/16個(gè)加法 + N/16個(gè)寫

（x：+=）2N個(gè)讀 + N個(gè)加法 + N個(gè)寫

（x：*）  N個(gè)讀 + 1個(gè)標(biāo)量除法 + N個(gè)乘法 + N個(gè)寫

（y：+=）2N/4個(gè)讀 + N/4個(gè)加法 + N/4個(gè)寫

（y：=） N/4個(gè)讀 + N/4個(gè)寫

因?yàn)槊總€(gè)都是函數(shù)指針，所以這些都是優(yōu)化不掉的。因此首先將一些操作合并了一下，比如把+= 和*合并以減少一下讀寫操作。只可惜效果也不是很明顯。

第二刀就砍到算法的頭上。因?yàn)槔奂颖旧硎菫榱藴p少乘法的運(yùn)用，但是這可能帶來了多余的存取開銷。

因此直接套用公式：

pixel = ( projected_v0 + projected_ddx * offset_x + projected_ddy * offset_y ) / pixel_w

這樣就有：3N讀，2N乘法，2N加法，N個(gè)乘法和N個(gè)寫（假設(shè)寄存器夠用的話）。不算Corner的計(jì)算成本，這樣比較一下，就等于是3N/4個(gè)讀，N/2+N個(gè)寫，N/4個(gè)加法來換取2N個(gè)乘法的時(shí)間。本來以為作為IO瓶頸的應(yīng)用，這樣可以提高一些性能。不過結(jié)果證實(shí)這個(gè)買賣實(shí)在是很不劃算，整體性能不增反減。

三輪優(yōu)化：減少內(nèi)存占用，柳暗花明

雖然所有的操作只針對已使用的屬性，但是空間上還是浪費(fèi)了許多。

考慮到內(nèi)存占用較大也會(huì)導(dǎo)致一些性能損失，于是將MAX_ATTRIBUTE_COUNT從32下調(diào)到了8。

結(jié)果令人大跌眼鏡。性能瞬間提升了20-30%之多。

再加上SSE也不知道為什么開始發(fā)力了，使用上之后性能大約又有了10-15%的提升。

我猜測可能是因?yàn)閾Q頁頻率下降，以及Cache的命中率提升。不過手上沒有VTune這種工具，所以也不太好驗(yàn)證。

四輪優(yōu)化：精度敏感性下降的額外紅利

在這輪優(yōu)化之后，PartOfSponza出現(xiàn)了精度問題。因?yàn)橐曞F體的上下左右四個(gè)面都沒有Clip，所以可能會(huì)出現(xiàn)非常大的三角形。這樣累積的時(shí)候一旦起始點(diǎn)選擇的不好，就會(huì)出現(xiàn)比較大的誤差。在之前版本中，使用/fp: precise來減少這一問題出現(xiàn)的機(jī)會(huì)。但是因?yàn)槭褂昧薙SE，也讓這個(gè)問題再難解決。因此我選用了一些辦法，來改善精度問題。在大問題都修正以后，換用/fp: fast來編譯整個(gè)SALVIA，最終也獲得了0-10%左右的性能收益。

結(jié)論

對于運(yùn)算和IO都密集的程序來說，優(yōu)化真可能是牽一發(fā)而動(dòng)全身的問題。比如在我的例子中，所有猜測是性能瓶頸的地方，都沒有得到預(yù)想中的改善。

倒是在內(nèi)存占用這個(gè)地方無心插柳，才得以柳暗花明，而且還讓別的優(yōu)化方案體現(xiàn)了價(jià)值。所以如果你不像qiaojie大牛那樣對x86了如指掌，還是要習(xí)慣于從多方面猜測，例如內(nèi)存占用，對齊或緊縮，計(jì)算強(qiáng)度，訪存密度，并行度等多個(gè)角度進(jìn)行設(shè)想并用實(shí)踐去驗(yàn)證。盡管可能會(huì)遇到很多挫折，但是，只要是直覺上有優(yōu)化的余地，一般都可以找到合適的方案。