研究了乙個多星期的gpgpu,學了arb(gpu assembly language)和glsl,遇到不少bug和糾結的問題.現在總結一下.
1.gpu的計算速度很快,如果你需要的數值可以通過少量計算求出來,那千萬不要預先把它們存在紋理裡讀取,哪怕它們需要被重複利用n多次.一次紋理取樣所耗費的時間遠遠大於你做10次甚至20次浮點計算的時間,尤其是在三維紋理中,效率就更低了.
gpu gems2的第32.1.2節中所講的,當我們的片段程式從紋理中讀取乙個資料的時候,這個過程交給紋理子系統來完成,為了掩蓋這段時間(或者延遲),gpu會開始處理下乙個片段,直到資料讀取回來之後再繼續處理原來的片段.如果要讓我們的程式的效能取決於我們的計算而不是視訊記憶體的話,我們的片段程式就必須包含足夠的計算來掩蓋紋理讀取的時間.
2.對於乙個紋理,gl_texture_min_filter和gl_texture_mag_filter的設定,對取樣速度有很大影響.gl_nearest的速度是gl_linear的兩倍以上.是否需要線性插值就看程式的需要了.還是那句話,能算則算,不要在紋理上取樣.
3.不知道在gpu的其他通用平台(如cuda和opencl)上是什麼情況,在使用opengl做gpgpu程式設計的時候,我發現乙個有趣的現象,無論使用arb還是glsl,compiler都會自動忽略對輸出結果無影響的語句.雖然這個結論是我自己的猜想,不一定對.我學習gpgpu的時間還不夠長,資料也沒看很多,不知道有沒有什麼資料上有講到這個問題.這個結論可以從下面的glsl**體現出來.
example 1:
for(coord.x=0.0;coord.x上面注釋掉的兩行**,實際執行的時候我只注釋其中一條.兩者的計算時間相差了8倍之多.
for迴圈裡面的**不動,如果返回結果用第一條語句,"force"和"fpos"的值實際上都關係到了fresult的取值.而第二條語句,返回的是fpos的值,只和"off"還有第一條取樣語句有關.
當我執行下面的**的時候,本以為沒有了force的取樣和fresult的加法,會更快.結果卻得到了同樣的計算時間,6秒.
example 2:
for(coord.x=0.0;coord.x所以我只能是這麼理解.在example 1裡, 與fpos無關的兩條語句實際上並沒有執行,否則為什麼example 1裡兩個返回語句的效率相差那麼多呢?
以上純屬猜測,還要去請教高手才知道為什麼了.
不過這個情況也只出現在測試中啦..一般也不會有人寫無關的語句進去..但是這個問題依然很有趣..
至於真正要返回fresult的速度為什麼那麼慢,主要原因還是在取樣上,尤其是在兩個不同的紋理上取樣,第乙個紋理的取樣值用於計算第二個紋理取樣的座標.這個地方很耗費時間.
4.我用的n卡,n卡的驅動上有監視狗,會檢測每個shader的執行時間,避免有些shader進入死迴圈.當shader的執行時間過長,也會被它強制關閉,然後系統會出現短暫黑屏,之後恢復正常,nv驅動提示停止響應並已恢復正常.所以如果乙個shader需要執行很長時間的話,只能把它分割成幾個shader來跑,中間結果就必須想辦法儲存咯,比如pre output/next input.
不知道a卡上是什麼樣子.改天拿塊試試.
5.arb的效率明顯比glsl快~^0^這是彙編的好處~~估計也會比cuda和opencl快點..就好比cpu上程式設計用彙編會比c++高效.
以上是乙個星期來糾結過的問題,尤其是取樣這個問題上對我的程式影響極大.只能怪自己對gpu了解還太淺,要熟練掌握gpgpu還要繼續好好花點功夫了~^_^~
android學習小小心得
今天開始學了一點點intent，在button.setonclicklistener時出現了乙個問題就是函式引數總是對不著，原本自己已經建立了乙個listener物件，但是偏偏不行。後來才發現自己import的是content.dialoginte ce.onclicklistener，而實際應該i...
vim編輯C 的小小心得
emmmmmmm已經讓linux吸了幾天灰感覺不太好。所以先把vim環境給搭建起來吧。遲遲沒有搭建的原因是因為害怕等到考試來搭建會不會gg。想起kpm用了半小時搭建環境真是瑟瑟發抖 然而早晚還是要搭的。感謝趙dalao的資瓷 首先是配置 vimrc vimrc set nu 顯示 行號 set ci...
紅黑樹的小小心得 插入
剛剛學了二叉樹，突然又蹦出來乙個 紅黑樹 這裡就是學習紅黑樹的一些小心得。紅黑樹，從名字就可以看出來，這種數是由紅和黑兩種顏色來表示的。首先需要了解紅黑樹的五個重要性質。1.每乙個節點要麼是黑色要麼就是紅色 2.根節點一定是黑色 3.每乙個葉子節點一定是黑色 4.如果乙個節點是紅色，那麼它的兩個子節...