2013-04-07 59 views
0

我探索相對較新的功能GL_ARB_separate_program_object.What我瞭解我必須建立一個管道對象應包含從中通過 glUseProgramStagesOpenGL的獨立程序階段

映射到那裏階段着色器這讓我想想2使用多個着色器的可能性:

1.創建具有變體的多個管道Vertex/Fragment着色器將來自一次映射到每個管道的耦合(現在不使用其他着色器類型)。

2.創建一個管道,在運行時切換使用

glUseProgramStages 

我最關注的performance.Which的選擇是更明智的性能映射到不同的着色器?

+0

你有沒有測量過?另外,我認爲你應該存儲管道對象,因爲它們相對便宜,不是嗎? – 2013-04-07 11:17:25

+0

我今天實現了這個系統,看到沒有性能下降。但需要了解頻繁更新管道對象是否會產生影響 – 2013-04-07 21:05:13

回答

1

你的問題不能真正回答,因爲它會隨着驅動程序的實現等而變化。然而,功能的事實和歷史應該是信息性的。

EXT_separate_shader_objects是此功能的第一個化身。它們之間最大的區別是:你不能在EXT版本中使用用戶定義的變化。你必須使用舊的兼容性輸入/輸出,如gl_TexCoord

Issue #2 in the EXT_separate_shader_objects specification 試圖證明這種難以理解的監督 解釋這樣做的理由如下:

這是從性能的角度不良企圖「按名稱交會」以支持,因爲單獨的任意單獨着色器着色器將不會自然編譯,以便在沒有特殊鏈接步驟的情況下匹配其相同名稱的不同輸入和輸出。這種特殊的鏈接會引入額外的驗證開銷來綁定單獨的着色器。鏈接本身必須被推遲到glBegin時間,因爲當從一組一致的着色器轉換到另一個着色器時,單獨的着色器不匹配。當輸入和輸出變化名稱匹配但它們的類型不匹配時,此特殊鏈接仍會產生錯誤或未定義的行爲。

這表明理由不依靠名字匹配 ,除了無能, 是性能相關的(如果你不能告訴,我不覺得很高EXT_SSO的)。 「按名稱集合」的表現來自於每次平局時都必須做到,而不是隻能做一次。

ARB_separate_shader_objects將程序集合封裝在一個對象中。因此,該對象可以存儲所有的「集合點」數據。第一次繪製調用可能會比較慢,但只要您不附加新程序,相同PPO的後續使用將會很快。

因此,我會以此爲證據,證明PPO應該在其上設置程序,然後單獨留下。一般來說,應儘可能避免修改附件對象。這就是爲什麼你被鼓勵不去添加或刪除FBO的紋理/渲染緩衝區的原因。

+1

因此,用簡單的話說 - 「根據需要創建管線,並在這些管線之間切換,而不是每次需要更改新的着色器組合時都進行更改」。是什麼意思? – 2013-04-07 14:29:00