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