由xBRZ filter淺談平行處理問題

xBRz是目前我用過在cpu cost與畫質上cp值頗高的影像放大濾鏡演算法
https://sourceforge.net/projects/xbrz
原始版本是C++ , 有人移植到C# ,我再接手進行一些效率優化的處理以及把一些最新xBRZ C++官方版本的最新功能加入,至少套用在電玩畫面的高效率輸出,即使用C#來寫效率也是OK的 .

但這演算法有一套很可惜的地方,導致移植到平行處理的方式會有問題,只能用某些折中的方式來進行平行多核處理.

首先這套演算法有每一條平行線與平行線之間的計算順序上的前後相依性,而且目前我還沒辦法找到方式去改寫這塊,因為這似乎就是xBrz演算法其中必須的核心精神要項之一,要拆除順序相依的問題,可能得自己研發變種版xBRZ.

因為這種相依性,平行計算下去,在計算順序無法控制預期的狀況下,出來的結果就是亂七八糟的.

目前找到兩套解法各有優缺點.

1.把畫面切成4大塊,4大概各自平行處理,效率滿好的,缺點只有兩個,一個是四塊區域銜接的邊界其實運算結果有可能是錯誤的,但因為其實原始只佔一pixl的誤差,一般沒很刻意去注意和比較根本不可能查覺,二是目前有太多電腦cpu核心數量其實超過4核,把整個運算切成4份,其實還浪費掉其他閒置率高的cpu.

2.跟線與線有關的順序性結果先算好出來,這部分沒平行加速幫忙,因為也幫不上忙,剩下再用平行的處理方式下去跑 (高的長度處理迴圈用parallel) , 缺點當然是有部分的計算是單核跑,且跟第一個方法比起來,context switch的cost當然也高不少(這還有改善空間就是,未必要以高度數量來當工作數量),優點來說的話就至少算出來的畫面是沒有瑕疵的,且cpu核心至少在處理高度迴圈時是有整個盡用的.

像這種順序相依問題一但拆解不掉,拿到GPU去跑一樣無法,甚至更慘,以前曾想過拿GPU來算一些結果,特別是畫面的計算這塊,但後來發現結果沒比CPU好,好壞結果真的很難論,最後未必有絕對性的優勢下,考慮利弊拿捏,最後沒往那方向走.

先撇開相依性的問題不談,假設一個龐大的計算工作,可以同時拆解成很多小任務丟給GPU跑,光是把計算資料COPY到GPU記憶體,和把GPU算好結果COPY回一般記憶體這段這段COST就把優勢佔光了....還不包括GPU計算初始化時間....這種問題,比較新的opencl加特定條件的硬體環境,似乎可以改善,總之大概就是這樣,平行處理並不是萬能仙丹,滿多問題會導致無法使用這種計算方式,即使可以算很多因素也未必說效率就一定會提高,應該是特定問題的處理適用.

至於透過網路來分散平行處理,更不用說...網路傳輸cost成本必定得計算在內.