glsl memoryBarrierShared用處

Question

我想知道memoryBarrierShared的用處。

事實上，當我在尋找屏障功能的文檔：我讀：

對於計算着色器屏障的任何給定的靜態實例，一個工作組內的所有調用必須進入它之前的任何有允許繼續超越它。這可以確保在一個給定的屏障靜態實例之前，通過一次調用寫入的值可以在調用相同的靜態屏障實例後由其他調用安全地讀取。由於調用可能會在這些屏障調用之間以未定義的順序執行，因此在許多情況下，每個頂點或每個補丁輸出變量或任何共享變量的值都將不確定。

所以，如果我們可以安全地使用屏障後讀取值，爲什麼我們看到在一些代碼

memoryBarrierShared(); 
barrier(); 

或有毛病像

barrier(); 
memoryBarrierShared(); 

所以，我的問題是：什麼是memoryBarrier {Shared，...}的目的，如果使用障礙足夠了嗎？

對於memoryBarrierBuffer /圖片我可以理解，如果我們使用多級，但共享，我沒有任何想法...

Answer 1

這實際上是在爭目前。

GLSL 4.50清楚地表明顯式記憶障礙是不必要的。計算着色器中的barrier包含所有內存障礙。

然而，GLSL ES 3.20使它同樣十分清楚，barrier不包括任何種類的存儲器障礙：

對於計算着色器，一個屏障僅影響控制流和由本身不確實同步內存訪問。特別是，它不能確保在給定靜態實例barrier()之前，通過一個調用寫入的值可以在調用相同靜態實例barrier()之後由其他調用安全地讀取。要實現這一點，需要同時使用 barrier()和內存屏障。

值得注意的是，離線glslang編譯器將總是使用GLSL ES措辭。因此，如果您要生成SPIR-V來支持Vulkan，那麼您必須在此處遵循ES的規則。那麼，until they get that fixed, one way or another。

這就是說，ES的措辭使得更多的意義，作爲全部內存障礙一切是相當昂貴的。特別是如果你想要做的就是同步對共享變量的訪問。

我會建議使用barrier調用旁邊的內存屏障。這樣，即使在某些實現中它可能稍微慢一點，你的着色器也是正確的。但是，如果您打算使用內存屏障以及barrier調用，則內存屏障必須先到達。同步執行後執行內存屏障不正確。