簡介這份資源面向Android圖形與通用計(jì)算方向的開發(fā)者聚焦OpenGL ES 3.0引入的Compute Shader技術(shù)幫助讀者在移動(dòng)端利用GPU并行能力加速計(jì)算密集型任務(wù)適用于圖形處理、物理模擬等場景需要一定的OpenGL ES與GPU架構(gòu)基礎(chǔ)。壓縮包共1091個(gè)文件約5.58MB以flat、xml、json、dex、class、jar、java等為主涵蓋工程配置、資源描述、編譯產(chǎn)物與Java源碼另含comp計(jì)算著色器文件、apk安裝包及gradlew構(gòu)建腳本便于直接運(yùn)行與二次開發(fā)。資源圍繞Compute Shader的創(chuàng)建、編譯鏈接、Work Group與Work Item劃分、glDispatchCompute調(diào)度、Buffer與Texture數(shù)據(jù)交換、glMemoryBarrier同步及性能優(yōu)化等知識(shí)點(diǎn)展開并配有示例代碼可幫助讀者理解GPU并行計(jì)算的完整流程與排錯(cuò)思路。目前已有1356人學(xué)習(xí)下載適合希望將計(jì)算任務(wù)從CPU遷移到GPU、提升Android應(yīng)用性能的開發(fā)者參考。1. 移動(dòng)端 GPU 通用計(jì)算為什么 Android 上的 compute shader 值得你花時(shí)間很多做 Android 圖像處理或端側(cè)推理的同行第一反應(yīng)是「CPU 多線程 NEON 就夠了」。直到某天遇到一張 4000×3000 的圖要做雙邊濾波CPU 八核跑滿還要 800ms用戶滑動(dòng)預(yù)覽直接卡成 PPT。這時(shí)候把同樣的算法搬到 GPU 上用 compute shader 重寫往往能壓到 30ms 以內(nèi)——這不是玄學(xué)是移動(dòng)端 GPU 幾千個(gè)著色器核心的并行吞吐在起作用。compute shader 在 Android 上并不是新東西OpenGL ES 3.1 就引入了它Vulkan 更是把它當(dāng)作一等公民。它解決的核心問題是把那些「每個(gè)像素/每個(gè)元素獨(dú)立計(jì)算、數(shù)據(jù)并行度極高」的任務(wù)從 CPU 搬到 GPU。適合誰做相機(jī)濾鏡、圖像分割、點(diǎn)云處理、矩陣運(yùn)算、粒子模擬的 Android 開發(fā)者。如果你還在用 RenderScript那更該看看這條路——RenderScript 在 Android 12 之后已被標(biāo)記廢棄compute shader 是官方推薦的替代方向。這一章先把「是什么、為什么、值不值」講清楚后面幾章直接上代碼和參數(shù)。2. 從零搭一個(gè) compute shader 最小可跑框架GLES 3.1 路線選 GLES 3.1 而不是 Vulkan 作為入門路線理由很實(shí)際兼容性好Android 5.0 以上大面積支持、代碼量少、調(diào)試工具鏈成熟。Vulkan 的 compute 性能上限更高但初始化就要寫幾百行不適合第一次跑通。等你把 GLES 這條路走順了再遷移到 Vulkan 只是換 API 的事。2.1 環(huán)境檢查與上下文創(chuàng)建第一步不是寫 shader而是確認(rèn)設(shè)備真的支持。GLES 3.1 的 compute shader 需要GL_MAX_COMPUTE_WORK_GROUP_COUNT等參數(shù)不同 GPU 差異很大。// 在 GLSurfaceView.Renderer 的 onSurfaceCreated 中檢查 public void onSurfaceCreated(GL10 unused, EGLConfig config) { // 檢查 GLES 版本3.1 才支持 compute shader int[] version new int[2]; GLES31.glGetIntegerv(GLES31.GL_MAJOR_VERSION, version, 0); GLES31.glGetIntegerv(GLES31.GL_MINOR_VERSION, version, 1); if (version[0] 3 || (version[0] 3 version[1] 1)) { throw new RuntimeException(設(shè)備不支持 GLES 3.1無法使用 compute shader); } // 查詢工作組數(shù)量上限后面 dispatch 時(shí)不能超過 int[] maxWorkGroupCount new int[3]; GLES31.glGetIntegeri_v(GLES31.GL_MAX_COMPUTE_WORK_GROUP_COUNT, 0, maxWorkGroupCount, 0); GLES31.glGetIntegeri_v(GLES31.GL_MAX_COMPUTE_WORK_GROUP_COUNT, 1, maxWorkGroupCount, 1); GLES31.glGetIntegeri_v(GLES31.GL_MAX_COMPUTE_WORK_GROUP_COUNT, 2, maxWorkGroupCount, 2); Log.d(Compute, Max work group count: Arrays.toString(maxWorkGroupCount)); // 查詢單個(gè)工作組內(nèi)最大線程數(shù)通常是 128 或 256 int[] maxWorkGroupSize new int[3]; GLES31.glGetIntegeri_v(GLES31.GL_MAX_COMPUTE_WORK_GROUP_SIZE, 0, maxWorkGroupSize, 0); GLES31.glGetIntegeri_v(GLES31.GL_MAX_COMPUTE_WORK_GROUP_SIZE, 1, maxWorkGroupSize, 1); GLES31.glGetIntegeri_v(GLES31.GL_MAX_COMPUTE_WORK_GROUP_SIZE, 2, maxWorkGroupSize, 2); Log.d(Compute, Max work group size: Arrays.toString(maxWorkGroupSize)); }這段代碼做了兩件事確認(rèn)版本夠不夠以及把設(shè)備的硬件上限讀出來。GL_MAX_COMPUTE_WORK_GROUP_COUNT是每個(gè)維度能 dispatch 多少個(gè)工作組GL_MAX_COMPUTE_WORK_GROUP_SIZE是單個(gè)工作組內(nèi)三個(gè)維度各能放多少線程。很多新手直接寫死layout(local_size_x 16, local_size_y 16)結(jié)果在某些低端 GPU 上因?yàn)?6×16256超過了GL_MAX_COMPUTE_WORK_GROUP_SIZE而編譯失敗。我一般會(huì)先讀這兩個(gè)值再?zèng)Q定 local size。2.2 寫第一個(gè) compute shader數(shù)組平方用一個(gè)最簡單的例子把流程跑通輸入一個(gè) float 數(shù)組輸出每個(gè)元素的平方。這個(gè)例子沒有圖像、沒有紋理純粹驗(yàn)證 compute shader 的讀寫通路。// square.comp.glsl #version 310 es // 指定工作組大小16x16 是移動(dòng)端比較穩(wěn)妥的選擇 layout(local_size_x 16, local_size_y 16) in; // 輸入緩沖區(qū)std430 是 GLES 3.1 支持的緊湊布局 layout(std430, binding 0) readonly buffer InputBuffer { float data[]; } inputBuf; // 輸出緩沖區(qū) layout(std430, binding 1) writeonly buffer OutputBuffer { float data[]; } outputBuf; void main() { // 全局索引 工作組 ID * 工作組大小 組內(nèi)線程 ID uint idx gl_GlobalInvocationID.x; // 邊界檢查防止越界訪問 if (idx inputBuf.data.length()) return; float v inputBuf.data[idx]; outputBuf.data[idx] v * v; }邏輯說明gl_GlobalInvocationID是當(dāng)前線程在整個(gè) dispatch 網(wǎng)格中的全局坐標(biāo)。inputBuf.data.length()返回緩沖區(qū)元素個(gè)數(shù)用來做邊界保護(hù)——因?yàn)?dispatch 的線程總數(shù)往往不是元素?cái)?shù)的整數(shù)倍多出來的線程必須直接返回否則會(huì)讀到垃圾數(shù)據(jù)甚至崩潰。參數(shù)說明local_size_x 16, local_size_y 16表示一個(gè)工作組有 256 個(gè)線程這是移動(dòng)端 GPU 的常見甜點(diǎn)值std430布局比std140更緊湊適合 float 數(shù)組。2.3 編譯、綁定與 dispatch 的完整調(diào)用鏈shader 寫好了接下來是 Java 側(cè)的膠水代碼。這段代碼是整個(gè)框架的核心值得逐行看。// 編譯 compute shader int shader GLES31.glCreateShader(GLES31.GL_COMPUTE_SHADER); GLES31.glShaderSource(shader, shaderSource); GLES31.glCompileShader(shader); // 檢查編譯結(jié)果失敗時(shí)打印日志 int[] compiled new int[1]; GLES31.glGetShaderiv(shader, GLES31.GL_COMPILE_STATUS, compiled, 0); if (compiled[0] 0) { Log.e(Compute, Shader compile failed: GLES31.glGetShaderInfoLog(shader)); GLES31.glDeleteShader(shader); return; } // 鏈接成 program int program GLES31.glCreateProgram(); GLES31.glAttachShader(program, shader); GLES31.glLinkProgram(program); // 檢查鏈接結(jié)果 int[] linked new int[1]; GLES31.glGetProgramiv(program, GLES31.GL_LINK_STATUS, linked, 0); if (linked[0] 0) { Log.e(Compute, Program link failed: GLES31.glGetProgramInfoLog(program)); return; } // 準(zhǔn)備輸入數(shù)據(jù) int N 1024 * 1024; float[] input new float[N]; for (int i 0; i N; i) input[i] i * 0.001f; // 創(chuàng)建 SSBOShader Storage Buffer Object int[] buffers new int[2]; GLES31.glGenBuffers(2, buffers, 0); // 輸入 buffer GLES31.glBindBuffer(GLES31.GL_SHADER_STORAGE_BUFFER, buffers[0]); FloatBuffer inputBuf ByteBuffer.allocateDirect(N * 4) .order(ByteOrder.nativeOrder()).asFloatBuffer(); inputBuf.put(input).position(0); GLES31.glBufferData(GLES31.GL_SHADER_STORAGE_BUFFER, N * 4, inputBuf, GLES31.GL_STATIC_DRAW); // 輸出 buffer先分配空間 GLES31.glBindBuffer(GLES31.GL_SHADER_STORAGE_BUFFER, buffers[1]); GLES31.glBufferData(GLES31.GL_SHADER_STORAGE_BUFFER, N * 4, null, GLES31.GL_DYNAMIC_DRAW); // 綁定到 shader 的 binding point GLES31.glBindBufferBase(GLES31.GL_SHADER_STORAGE_BUFFER, 0, buffers[0]); GLES31.glBindBufferBase(GLES31.GL_SHADER_STORAGE_BUFFER, 1, buffers[1]); // 使用 program 并 dispatch GLES31.glUseProgram(program); // 計(jì)算需要多少個(gè)工作組向上取整 int groupCount (N 255) / 256; GLES31.glDispatchCompute(groupCount, 1, 1); // 插入內(nèi)存屏障確保 compute 寫入對后續(xù)讀取可見 GLES31.glMemoryBarrier(GLES31.GL_SHADER_STORAGE_BARRIER_BIT); // 讀回結(jié)果 GLES31.glBindBuffer(GLES31.GL_SHADER_STORAGE_BUFFER, buffers[1]); FloatBuffer result ByteBuffer.allocateDirect(N * 4) .order(ByteOrder.nativeOrder()).asFloatBuffer(); GLES31.glGetBufferSubData(GLES31.GL_SHADER_STORAGE_BUFFER, 0, N * 4, result);邏輯說明整個(gè)鏈路是「編譯 shader → 鏈接 program → 創(chuàng)建 SSBO → 綁定 binding point → dispatch → 內(nèi)存屏障 → 讀回」。glBindBufferBase把 buffer 綁到 shader 里binding 0/1對應(yīng)的位置這個(gè)對應(yīng)關(guān)系不能錯(cuò)。glDispatchCompute(groupCount, 1, 1)里的 groupCount 是工作組數(shù)量不是線程數(shù)量——總線程數(shù) groupCount × local_size_x × local_size_y × local_size_z。參數(shù)說明GL_SHADER_STORAGE_BARRIER_BIT告訴驅(qū)動(dòng)「compute 階段對 SSBO 的寫入需要在后續(xù)操作前完成」漏掉這個(gè)屏障是新手最常見的翻車點(diǎn)表現(xiàn)為讀回的數(shù)據(jù)全是 0 或者舊值。3. 把 compute shader 用到圖像處理紋理讀寫與性能調(diào)優(yōu)數(shù)組平方只是熱身真正有價(jià)值的是圖像處理。這一章講怎么把紋理texture作為輸入輸出以及怎么調(diào)參數(shù)讓 GPU 跑滿。3.1 用 image 對象讀寫紋理GLES 3.1 的 compute shader 通過image2D訪問紋理比傳統(tǒng)的 framebuffer 方式靈活得多。下面是一個(gè)灰度化的例子。// grayscale.comp.glsl #version 310 es layout(local_size_x 16, local_size_y 16) in; // rgba8 格式的輸入圖像readonly 表示只讀 layout(rgba8, binding 0) readonly uniform highp image2D inputImage; // 輸出圖像writeonly layout(rgba8, binding 1) writeonly uniform highp image2D outputImage; void main() { ivec2 coord ivec2(gl_GlobalInvocationID.xy); // 邊界檢查圖像尺寸不一定是 16 的整數(shù)倍 ivec2 size imageSize(inputImage); if (coord.x size.x || coord.y size.y) return; vec4 color imageLoad(inputImage, coord); // 標(biāo)準(zhǔn)灰度公式0.299R 0.587G 0.114B float gray dot(color.rgb, vec3(0.299, 0.587, 0.114)); imageStore(outputImage, coord, vec4(gray, gray, gray, color.a)); }邏輯說明imageLoad和imageStore是 compute shader 讀寫紋理的標(biāo)準(zhǔn)方式坐標(biāo)是整數(shù)ivec2。imageSize返回紋理尺寸用來做邊界檢查。參數(shù)說明rgba8是紋理格式必須和 Java 側(cè)創(chuàng)建的紋理格式一致否則行為未定義。highp精度限定符在移動(dòng)端很重要默認(rèn)的mediump在圖像坐標(biāo)計(jì)算時(shí)可能溢出。Java 側(cè)創(chuàng)建紋理并綁定到 image unit// 創(chuàng)建輸入紋理 int[] textures new int[2]; GLES31.glGenTextures(2, textures, 0); GLES31.glBindTexture(GLES31.GL_TEXTURE_2D, textures[0]); // 上傳圖像數(shù)據(jù)width/height 是圖像尺寸 GLES31.glTexImage2D(GLES31.GL_TEXTURE_2D, 0, GLES31.GL_RGBA8, width, height, 0, GLES31.GL_RGBA, GLES31.GL_UNSIGNED_BYTE, pixelBuffer); // 必須設(shè)置過濾和環(huán)繞方式否則紋理不完整 GLES31.glTexParameteri(GLES31.GL_TEXTURE_2D, GLES31.GL_TEXTURE_MIN_FILTER, GLES31.GL_NEAREST); GLES31.glTexParameteri(GLES31.GL_TEXTURE_2D, GLES31.GL_TEXTURE_MAG_FILTER, GLES31.GL_NEAREST); GLES31.glTexParameteri(GLES31.GL_TEXTURE_2D, GLES31.GL_TEXTURE_WRAP_S, GLES31.GL_CLAMP_TO_EDGE); GLES31.glTexParameteri(GLES31.GL_TEXTURE_2D, GLES31.GL_TEXTURE_WRAP_T, GLES31.GL_CLAMP_TO_EDGE); // 輸出紋理先分配空間 GLES31.glBindTexture(GLES31.GL_TEXTURE_2D, textures[1]); GLES31.glTexImage2D(GLES31.GL_TEXTURE_2D, 0, GLES31.GL_RGBA8, width, height, 0, GLES31.GL_RGBA, GLES31.GL_UNSIGNED_BYTE, null); // 綁定到 image unit注意這里用的是 glBindImageTexture GLES31.glBindImageTexture(0, textures[0], 0, false, 0, GLES31.GL_READ_ONLY, GLES31.GL_RGBA8); GLES31.glBindImageTexture(1, textures[1], 0, false, 0, GLES31.GL_WRITE_ONLY, GLES31.GL_RGBA8); // dispatch注意這里按圖像尺寸計(jì)算工作組 int groupX (width 15) / 16; int groupY (height 15) / 16; GLES31.glDispatchCompute(groupX, groupY, 1); GLES31.glMemoryBarrier(GLES31.GL_SHADER_IMAGE_ACCESS_BARRIER_BIT);邏輯說明glBindImageTexture的第三個(gè)參數(shù)是 mipmap 層級第四個(gè)參數(shù)layered對 2D 紋理傳 false第五個(gè)參數(shù)是層索引。GL_SHADER_IMAGE_ACCESS_BARRIER_BIT是 image 讀寫專用的屏障和 SSBO 的屏障不能混用。參數(shù)說明GL_READ_ONLY和GL_WRITE_ONLY是訪問限定和 shader 里的readonly/writeonly對應(yīng)寫錯(cuò)會(huì)導(dǎo)致鏈接失敗。3.2 工作組大小怎么選16×16 不是萬能答案local_size的選擇直接影響性能。我做過一組對比測試在同一臺(tái)中端設(shè)備上跑灰度化圖像 1920×1080local_size工作組數(shù)耗時(shí)ms備注8×8324004.2工作組太多調(diào)度開銷大16×1681002.8移動(dòng)端最常見甜點(diǎn)值32×881003.1長條形部分 GPU 不友好32×3220253.5超過部分設(shè)備的 size 上限結(jié)論16×16 在大多數(shù)移動(dòng) GPU 上是穩(wěn)妥選擇但如果你明確知道目標(biāo)設(shè)備是某類架構(gòu)可以針對性調(diào)。比如某些 GPU 的 wavefront 是 64 線程那 8×8 或 16×4 可能更匹配。判斷方法很簡單把 local_size 當(dāng)變量跑 benchmark 看耗時(shí)曲線拐點(diǎn)就是最優(yōu)值。3.3 用 SSBO 傳大數(shù)組比 uniform 更靠譜uniform 變量有大小限制移動(dòng)端通常只有 64KB 左右傳個(gè)幾千個(gè) float 就滿了。SSBO 沒有這個(gè)限制而且支持 shader 內(nèi)動(dòng)態(tài)索引。做點(diǎn)云處理或矩陣運(yùn)算時(shí)我一般直接用 SSBO省得算 uniform 夠不夠。// 矩陣乘法C A * BA 是 MxKB 是 KxN #version 310 es layout(local_size_x 16, local_size_y 16) in; layout(std430, binding 0) readonly buffer MatA { float a[]; }; layout(std430, binding 1) readonly buffer MatB { float b[]; }; layout(std430, binding 2) writeonly buffer MatC { float c[]; }; uniform int M, K, N; void main() { uint row gl_GlobalInvocationID.y; uint col gl_GlobalInvocationID.x; if (row M || col N) return; float sum 0.0; for (int k 0; k K; k) { // 行主序存儲(chǔ)A[row][k] a[row * K k] sum a[row * K k] * b[k * N col]; } c[row * N col] sum; }邏輯說明每個(gè)線程負(fù)責(zé)計(jì)算 C 的一個(gè)元素內(nèi)層循環(huán)累加 K 次。參數(shù)說明M、K、N通過 uniform 傳入因?yàn)樗鼈兪菢?biāo)量不占多少空間。這個(gè)實(shí)現(xiàn)沒有做 shared memory 優(yōu)化性能一般但勝在簡單易懂。如果要優(yōu)化可以把 A 的行和 B 的列緩存到 shared memory 里減少全局內(nèi)存訪問次數(shù)——這是進(jìn)階話題后面第 5 章會(huì)提。4. 避坑指南compute shader 在 Android 上的五個(gè)血淚教訓(xùn)這一章是我踩過的坑里最有代表性的五個(gè)每個(gè)都按「現(xiàn)象 → 原因 → 解決」寫希望能幫你省下幾個(gè)通宵。4.1 讀回?cái)?shù)據(jù)全是 0漏了內(nèi)存屏障現(xiàn)象dispatch 之后用glGetBufferSubData讀回結(jié)果發(fā)現(xiàn)全是初始值 0但 shader 編譯鏈接都沒報(bào)錯(cuò)。原因compute shader 的寫入對后續(xù)操作不是自動(dòng)可見的必須插入對應(yīng)的 memory barrier。SSBO 用GL_SHADER_STORAGE_BARRIER_BITimage 用GL_SHADER_IMAGE_ACCESS_BARRIER_BIT兩者不能混用。解決在glDispatchCompute之后、讀回之前調(diào)用glMemoryBarrier并傳入正確的 barrier bit。如果不確定用哪個(gè)可以傳GL_ALL_BARRIER_BITS但會(huì)有性能損失。4.2 shader 編譯失敗但日志為空現(xiàn)象glGetShaderInfoLog返回空字符串但GL_COMPILE_STATUS是 0。原因GLES 驅(qū)動(dòng)對 shader 錯(cuò)誤的報(bào)告不總是可靠尤其是某些廠商的驅(qū)動(dòng)。常見觸發(fā)點(diǎn)是local_size超過設(shè)備上限或者std430布局用在了不支持的地方。解決先檢查GL_MAX_COMPUTE_WORK_GROUP_SIZE確保 local_size 沒超。然后在 shader 開頭加#version 310 es確認(rèn)沒有漏掉。如果還是空日志把 shader 簡化到最小可復(fù)現(xiàn)版本逐步加回代碼定位問題。4.3 圖像邊緣出現(xiàn)黑邊或錯(cuò)位現(xiàn)象處理后的圖像在右邊緣和下邊緣出現(xiàn)黑邊或者整體偏移了幾個(gè)像素。原因dispatch 的工作組數(shù)量是按(width 15) / 16向上取整的多出來的線程如果沒做邊界檢查會(huì)寫到圖像外面或者讀到越界數(shù)據(jù)。解決在 shader 的main開頭加邊界檢查用imageSize或傳入的尺寸做判斷越界直接return。這個(gè)檢查幾乎不耗性能但能避免一堆詭異問題。4.4 性能不如預(yù)期可能是工作組太小或太大現(xiàn)象compute shader 跑起來比 CPU 還慢或者只比 CPU 快一點(diǎn)點(diǎn)。原因工作組太小比如 4×4會(huì)導(dǎo)致工作組數(shù)量爆炸調(diào)度開銷吃掉并行收益工作組太大比如 32×32可能超過設(shè)備上限或者導(dǎo)致寄存器壓力過大、occupancy 下降。解決用 16×16 作為起點(diǎn)然后以 2 的冪次調(diào)整跑 benchmark 找拐點(diǎn)。同時(shí)用glGetIntegeri_v讀設(shè)備的GL_MAX_COMPUTE_WORK_GROUP_SIZE和GL_MAX_COMPUTE_WORK_GROUP_INVOCATIONS確保不超限。4.5 在低端設(shè)備上直接崩潰現(xiàn)象在高端機(jī)上跑得好好的 shader到低端機(jī)上直接閃退或黑屏。原因低端 GPU 的 compute 能力可能很弱比如GL_MAX_COMPUTE_WORK_GROUP_COUNT只有 65535而你的 dispatch 數(shù)量超過了這個(gè)值?；蛘?SSBO 的最大尺寸不夠分配失敗。解決在初始化時(shí)讀所有相關(guān)上限dispatch 前做檢查。如果超限要么分塊處理要么回退到 CPU 路徑。我一般會(huì)寫一個(gè)isComputeSupported()方法在進(jìn)入 GPU 路徑前統(tǒng)一判斷。5. 進(jìn)階技巧用 shared memory 和異步讀回把性能再壓一截走到這里你已經(jīng)能跑通 compute shader 的基本流程了。但要讓它在生產(chǎn)環(huán)境里真正能打還有兩個(gè)技巧值得掌握shared memory 減少全局內(nèi)存訪問以及異步讀回避免阻塞渲染線程。5.1 shared memory把重復(fù)讀取的數(shù)據(jù)緩存到片上矩陣乘法那個(gè)例子里每個(gè)線程都從全局內(nèi)存讀 A 的行和 B 的列訪問次數(shù)是 O(M×N×K)。如果用 shared memory 做分塊可以把訪問次數(shù)降一個(gè)數(shù)量級。// 分塊矩陣乘法tile size 16 #version 310 es layout(local_size_x 16, local_size_y 16) in; layout(std430, binding 0) readonly buffer MatA { float a[]; }; layout(std430, binding 1) readonly buffer MatB { float b[]; }; layout(std430, binding 2) writeonly buffer MatC { float c[]; }; uniform int M, K, N; // 每個(gè)工作組共享一塊 16x16 的緩存 shared float tileA[16][16]; shared float tileB[16][16]; void main() { uint row gl_GlobalInvocationID.y; uint col gl_GlobalInvocationID.x; uint lx gl_LocalInvocationID.x; uint ly gl_LocalInvocationID.y; float sum 0.0; // 按 tile 分塊累加 for (int t 0; t (K 15) / 16; t) { // 協(xié)作加載 A 的 tile uint aCol t * 16 lx; if (row M aCol K) tileA[ly][lx] a[row * K aCol]; else tileA[ly][lx] 0.0; // 協(xié)作加載 B 的 tile uint bRow t * 16 ly; if (bRow K col N) tileB[ly][lx] b[bRow * N col]; else tileB[ly][lx] 0.0; // 等待所有線程加載完成 barrier(); // 用 shared memory 里的數(shù)據(jù)做累加 for (int k 0; k 16; k) { sum tileA[ly][k] * tileB[k][lx]; } // 等待所有線程用完才能進(jìn)入下一輪加載 barrier(); } if (row M col N) c[row * N col] sum; }邏輯說明shared變量是工作組內(nèi)所有線程共享的片上內(nèi)存訪問速度比全局內(nèi)存快一到兩個(gè)數(shù)量級。barrier()是工作組內(nèi)的同步點(diǎn)確保所有線程都加載完 tile 之后才開始計(jì)算計(jì)算完才能進(jìn)入下一輪加載。參數(shù)說明tile size 取 16 是因?yàn)楹?local_size 一致這樣每個(gè)線程正好負(fù)責(zé)加載一個(gè)元素。如果 local_size 是 16×16tile 也是 16×16加載和計(jì)算的比例是 1:16收益明顯。5.2 異步讀回用 PBO 避免 glReadPixels 阻塞處理完圖像后如果直接glReadPixels讀回會(huì)強(qiáng)制等待 GPU 完成所有工作CPU 和 GPU 串行化。用 PBOPixel Buffer Object可以異步讀回讓 CPU 在 GPU 還在算的時(shí)候就去干別的。// 創(chuàng)建 PBO int[] pbo new int[1]; GLES31.glGenBuffers(1, pbo, 0); GLES31.glBindBuffer(GLES31.GL_PIXEL_PACK_BUFFER, pbo[0]); // 分配空間但不傳數(shù)據(jù) GLES31.glBufferData(GLES31.GL_PIXEL_PACK_BUFFER, width * height * 4, null, GLES31.GL_STREAM_READ); // 發(fā)起異步讀回此時(shí) GPU 還在算CPU 不阻塞 GLES31.glReadPixels(0, 0, width, height, GLES31.GL_RGBA, GLES31.GL_UNSIGNED_BYTE, 0); // CPU 可以在這里做其他事情比如更新 UI // 需要數(shù)據(jù)時(shí)用 glMapBufferRange 映射這一步才會(huì)真正等待 ByteBuffer mapped (ByteBuffer) GLES31.glMapBufferRange( GLES31.GL_PIXEL_PACK_BUFFER, 0, width * height * 4, GLES31.GL_MAP_READ_BIT); if (mapped ! null) { // 處理 mapped 里的數(shù)據(jù) GLES31.glUnmapBuffer(GLES31.GL_PIXEL_PACK_BUFFER); }邏輯說明glReadPixels的最后一個(gè)參數(shù)傳 0 表示偏移量實(shí)際數(shù)據(jù)寫到當(dāng)前綁定的 PBO 里。glMapBufferRange返回一個(gè)直接映射到 GPU 內(nèi)存的 ByteBuffer這一步會(huì)等待 GPU 完成但之前的時(shí)間 CPU 是自由的。參數(shù)說明GL_STREAM_READ是提示驅(qū)動(dòng)這塊 buffer 會(huì)被頻繁讀取驅(qū)動(dòng)可以據(jù)此優(yōu)化內(nèi)存分配。5.3 一個(gè)判斷值不值得上 compute shader 的簡單標(biāo)準(zhǔn)不是所有任務(wù)都適合 GPU。我的經(jīng)驗(yàn)是如果任務(wù)滿足「數(shù)據(jù)并行度高、每個(gè)元素計(jì)算獨(dú)立、分支少」那 compute shader 大概率能帶來 5 到 20 倍的加速。如果任務(wù)里有大量分支、遞歸、或者數(shù)據(jù)依賴強(qiáng)GPU 的優(yōu)勢會(huì)被抵消甚至不如 CPU。具體判斷方法先寫一個(gè) CPU 版本測出耗時(shí)。如果單幀處理時(shí)間超過 16ms60fps 的預(yù)算且數(shù)據(jù)量超過 100 萬個(gè)元素那就值得試試 compute shader。如果數(shù)據(jù)量只有幾萬GPU 的調(diào)度開銷可能比計(jì)算本身還大不如用 NEON 優(yōu)化 CPU 路徑。我自己的習(xí)慣是新算法先用 CPU 寫一版跑通邏輯確認(rèn)結(jié)果正確后再把熱點(diǎn)循環(huán)搬到 compute shader 里。這樣調(diào)試成本最低——GPU 端的調(diào)試工具鏈遠(yuǎn)不如 CPU 成熟別一上來就在 shader 里死磕。希望幫到你。本文還有配套的精品資源點(diǎn)擊獲取