背景與工程定位

背景

項(xiàng)目組基于深度學(xué)習(xí)實(shí)現(xiàn)了視頻風(fēng)格化和人像摳圖的功能，但這是在PC/服務(wù)端上跑的，現(xiàn)在需要移植到移動(dòng)端，因此需要一個(gè)移動(dòng)端的深度學(xué)習(xí)的計(jì)算框架。

公司主營(yíng)業(yè)務(wù)：成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)公司是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來(lái)的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來(lái)驚喜。成都創(chuàng)新互聯(lián)公司推出光山免費(fèi)做網(wǎng)站回饋大家。

同類型的庫(kù)

caffe-Android-lib 目前應(yīng)該是最便于集成使用的深度學(xué)習(xí)框架庫(kù)。 
tensorflow和mxnet據(jù)說(shuō)也有對(duì)應(yīng)的android庫(kù)，因時(shí)間原因暫未測(cè)試。 
CNNdroid，網(wǎng)址https://zhuanlan.zhihu.com/p/25259452，這個(gè)是用 
renderscript 作優(yōu)化的深度學(xué)習(xí)框架，不過就代碼實(shí)現(xiàn)和實(shí)際測(cè)試結(jié)果來(lái)看，性能一般。

工程定位

實(shí)現(xiàn)可實(shí)時(shí)、體積小、通用的深度學(xué)習(xí)預(yù)測(cè)框架。

可實(shí)時(shí)

跟PC或服務(wù)器不同，移動(dòng)設(shè)備上的GPU可不一定有CPU強(qiáng)悍（多線程+neon/vfp），但在需要實(shí)時(shí)計(jì)算的場(chǎng)景（主要是相機(jī)預(yù)覽和視頻播放），往往都是基于OpenGL渲染環(huán)境的。 
實(shí)時(shí)的情況下，深度學(xué)習(xí)框架的輸入和輸出都在GPU端，使用CPU進(jìn)行計(jì)算往往需要拷貝圖像出來(lái)，算好后再傳到GPU端，因此基于GPU實(shí)現(xiàn)的深度學(xué)習(xí)的庫(kù)能持平CPU版本的效率就有足夠優(yōu)勢(shì)了。

對(duì)每一幀相機(jī)預(yù)覽產(chǎn)生的數(shù)據(jù)，系統(tǒng)將其映射為opengl 的一個(gè)external texture，然后需要 計(jì)算出一個(gè) mask texture，與原先的texture作混合，顯示出來(lái)。如果mask texture 的計(jì)算在cpu上進(jìn)行，則需要每幀先把 graphicbuffer 的數(shù)據(jù)拷貝出來(lái)，計(jì)算出mask后上傳到 mask texture 去，產(chǎn)生一來(lái)一回兩次額外拷貝。

通用

本工程需要支持 caffe 產(chǎn)出的模型文件，支持常見的網(wǎng)絡(luò)如lenet、ResNet等等。這個(gè)工作量包括編寫相應(yīng)層的算子，設(shè)計(jì)網(wǎng)絡(luò)結(jié)構(gòu)，解析caffe模型的參數(shù)等。 
所幸的是，目前在移動(dòng)端做好深度學(xué)習(xí)的預(yù)測(cè)就足夠了，相比于兼顧訓(xùn)練的結(jié)構(gòu)至少省去2/3的工作量。

工程實(shí)現(xiàn)

方案選型

GPU加速的API

使用GPU加速有如下一些方案： 
CUDA、OpenCL、OpenGL（ES）、RenderScript、Metal 
CUDA只適用到NVIDIA的GPU，Metal只適用于apple系列，這兩個(gè)對(duì)android設(shè)備而言基本不用考慮。 
對(duì)于OpenCL，雖然有不少移動(dòng)GPU已經(jīng)支持，比如 Arm 的 mali 系列（T628之后），且有相應(yīng)的支持庫(kù)。但是，一方面由于Android在系統(tǒng)層面上沒有支持，沒有相應(yīng)的系統(tǒng)API，兼容性還是比較差，另一方面，OpenCL 操作完成后的內(nèi)存?zhèn)鞯絆penGL還是需要同步一下，會(huì)影響效率。 
RenderScript 這個(gè)坑比較多，文檔極少，而且會(huì)有跟OpenCL一樣的需要跟OpenGL同步的問題，不做考慮。 
***就只剩下 OpenGL ES，為了開發(fā)方便，用 Computer shader 實(shí)現(xiàn)，盡管會(huì)有一定的兼容性犧牲（Android 5.1 及以上，GPU支持openGLES 3.1），但考慮到下面兩點(diǎn)是值得的： 
1、走渲染管線去實(shí)現(xiàn)通用計(jì)算，編程復(fù)雜且容易出錯(cuò)，調(diào)優(yōu)也很麻煩。有 computer shader之后，編程就跟opencl、metal類似，這些工作量可以大幅降低，大大加快開發(fā)。 
2、支持OpenGLES 3.1版本的GPU一般都是相對(duì)較新的，性能不會(huì)太差，能夠?qū)崿F(xiàn)加速的目的。

運(yùn)算的分配

CNNdroid中僅用GPU加速卷積層的運(yùn)算，其他還是由CPU+多線程執(zhí)行。以前我們?cè)谠缙谧鱣pu加速的預(yù)研時(shí)，也有過類似的嘗試，但是數(shù)據(jù)傳輸和同步的性能消耗遠(yuǎn)大于協(xié)同計(jì)算帶來(lái)的性能提升。因此這個(gè)工程中，網(wǎng)絡(luò)中的計(jì)算全部由GPU完成，避免數(shù)據(jù)在CPU和GPU之間反復(fù)傳輸或同步。

另外，GPU驅(qū)動(dòng)在申請(qǐng)內(nèi)存（分配紋理所需要內(nèi)存空間）的時(shí)間消耗在移動(dòng)設(shè)備端是不可忽略的，因此，不能在運(yùn)算過程中臨時(shí)創(chuàng)建紋理或其他Buffer，必須事先分配好。

優(yōu)化注意點(diǎn)

1、向量化運(yùn)算 
預(yù)測(cè)時(shí)，我們輸入神經(jīng)網(wǎng)絡(luò)的數(shù)據(jù)可表示為  w?h?d 的三維數(shù)據(jù)。我們將輸入數(shù)據(jù)用一個(gè)RGBA32F格式的3D紋理存維，由于每一個(gè)像素有4個(gè)數(shù)值，得到的紋理大小是 w?h?ceil(d4) 。 
對(duì)于卷積層和內(nèi)積層，我們把參數(shù)存儲(chǔ)為mat4的數(shù)組，然后其計(jì)算就完全是vec4級(jí)的向量化運(yùn)算。

2、合適的localsize設(shè)計(jì) 
與OpenCL不一樣，computer shader 必須手動(dòng)指定 workgroup 的大小，并且指定運(yùn)行的 workgroup 數(shù)量。這兩組維度，都是越大越好。 
local size 一般而言越大越好，但 computer shader 所需要的寄存器越多，local size 的***值就越小，考慮到最耗時(shí)的卷積shader所能使用的local size 一般也就 64，保守起見都定為64（8乘8）。 
不能對(duì)齊的情況在shader中處理，比如下面的代碼：

void main()
{
    ivec3 pos = ivec3(gl_GlobalInvocationID);
    if (pos.x < MAX_WIDTH && pos.y < MAX_HEIGHT)
    {
        /*Do something*/
    }
}
 
 
 
 

  
  
  
  
1
  
  
  
  
2
  
  
  
  
3
  
  
  
  
4
  
  
  
  
5
  
  
  
  
6
  
  
  
  
7
  
  
  
  
8
 
 
 
 
 
 
 
 

  
  
  
  
1
  
  
  
  
2
  
  
  
  
3
  
  
  
  
4
  
  
  
  
5
  
  
  
  
6
  
  
  
  
7
  
  
  
  
8
 
 
 
 

3、適當(dāng)?shù)睾喜?去除layer 
如正則層可以直接和上一層合并（末尾加個(gè)max處理就行），dropout層可以直接丟棄。 
合并可以提升性能（不過不會(huì)太多），但最重要的是減少了中間內(nèi)存。

框架設(shè)計(jì)

分為兩個(gè)子模塊，引擎模塊在客戶端上運(yùn)行，工具模塊用來(lái)轉(zhuǎn)換caffe的模型文件。

引擎模塊

1、數(shù)據(jù)層 
Image 為一個(gè)RGBA32F格式的2D Array紋理，SSBO為一種vbo， 
全稱為GL_SHADER_STORAGE_BUFFER，用于存儲(chǔ)自定義類型的數(shù)據(jù)（主要就是卷積層和內(nèi)積層的參數(shù)）。 
Program 為 著色器鏈接而成的 opengl program，NetInfo 由 proto 定義，用于規(guī)定網(wǎng)絡(luò)結(jié)構(gòu)。 
在 shader 中，image 和 SSBO 示例如下：

layout(rgba32f, binding = 0) writeonly uniform highp image2DArray uOutput;//Image
layout(rgba32f, binding = 1) readonly uniform highp image2DArray uInput;//Image
layout(binding = 2) readonly buffer kernel {
    mat4 values[];
} uKernel;//SSBO
 
 
 
 

  
  
  
  
1
  
  
  
  
2
  
  
  
  
3
  
  
  
  
4
  
  
  
  
5
 
 
 
 
 
 
 
 

  
  
  
  
1
  
  
  
  
2
  
  
  
  
3
  
  
  
  
4
  
  
  
  
5
 
 
 
 

2、算子層 
包括各類layer的實(shí)現(xiàn)，如卷積，正則，內(nèi)積（全連接），Softmax等。 
每一個(gè)layer要負(fù)責(zé)申請(qǐng)自己的輸出內(nèi)存（image）。

3、結(jié)構(gòu)層 
根據(jù) NetInfo 的信息，創(chuàng)建各類算子并構(gòu)成DAG（有向無(wú)環(huán)圖），執(zhí)行運(yùn)算并輸出結(jié)果。

工具模塊

包括一個(gè)結(jié)構(gòu)轉(zhuǎn)換器、參數(shù)初始化和拷貝工具?？截惞ぞ呤潜容^容易出錯(cuò)的，因?yàn)榫矸e層和內(nèi)積層的參數(shù)需要補(bǔ)零對(duì)齊及重排。

性能與效果

跟開源的 caffe-android-lib 對(duì)比 
https://github.com/sh1r0/caffe-android-lib

庫(kù)大小

caffe-android-lib 11M 
DeeplearningOGL 440K 
全自主開發(fā)的，毫無(wú)疑問要小很多很多。

運(yùn)行效率

Oppo R9 （MT6755， GPU: Mali-T860）上的測(cè)試結(jié)果： 
連續(xù)運(yùn)行十次，去除***次的結(jié)果（移動(dòng)設(shè)備上一般都是動(dòng)態(tài)調(diào)頻的，***次跑的時(shí)候CPU/GPU的頻率還沒調(diào)起來(lái)，會(huì)比較慢）。 
Lenet 網(wǎng)絡(luò)： 
caffe-android-lib：5.0~5.2ms（線程設(shè)為4） 
DeeplearningOGL：3.6-3.8 ms

較CPU版本（包含了neon與多線程優(yōu)化）提升了 50%左右的效率，已經(jīng)大大超出預(yù)期了，在GPU更好的機(jī)器上（如mate8上）表現(xiàn)會(huì)更佳。 
相比于 CNNdroid 更是好很多了。

人像摳圖的場(chǎng)景很流暢，且不需要隔幀計(jì)算。

當(dāng)前標(biāo)題：基于OpenGLES的深度學(xué)習(xí)框架編寫
分享地址：http://uogjgqi.cn/article/coehegd.html