OpenGL ES 在不同架構上的指令優化是否真的完美？

01-21

特別是 glReadPixels()，測試方法用 System.nanotime()的 benchmark ， arm64-v8a 的執行時間是 armeabi-v7a 的一倍多。 480p 的 RGBA 格式， arm64-v8a 是 40ms 以上， armeabi-v7a 是 20ms 左右。
---補充---
看了兩位好心人答案，覺得自己問得急了點，沒有把實際情況說清楚，在此說明我的演算法：yasea/GPUImageFilter.java at gpuimage · begeekmyfriend/yasea · GitHub

這是安卓上的GLES，其實也不複雜，圖源來自Camera綁定的SurfaceTexture，作為samplerExternalOES採樣，渲染到FBO的Texture，也就是color attachment0，然後glReadPixels讀到內存交給libyuv處理；接下來FBO的Texture作為sampler2D採樣，渲染到屏幕。
個人認為自己的演算法是沒有問題的。問題就在於armeabi-v7a上是好的，arm64-v8a上就掉幀（如果shader寫得比較複雜的話），定位的點就在於glReadPixels()，可是從FBO中讀取不就是調用它嗎？
我是在同一個Nexus 5x手機上測試的，兩個架構都能跑。

這件事情跟OpenGLES沒關係。glReadPixels需要同步流水線，所以會把GPU沒畫完的全部畫完，再讀回來。瓶頸在同步而不在讀，多長時間都有可能。所以幾乎任何時候，用glReadPixels都代表你演算法有錯。

這和指令優化有毛關係……

你去glReadPixels了……尼瑪這個不得等Cache Flush啊？

這不是一個給顯卡發Command Queue的函數，就我的認識上你不能像渲染命令一樣把這個插進隊列里然後撒手不管，而是像龔大說的那樣會把Pipeline給整個Stall掉

如果你在main loop裡面呼叫這個了，等吧，起碼等到當前推到顯卡的Command Queue渲染完畢，還得等顯卡Flush Cache，如果顯卡驅動做了Render Queue（當代顯卡驅動基本上都會做的），那你還得等隊列裡面的幀都渲染完畢了才能拿到FB內容……

題主可能還活在PS1PS2的年代……是啊，那時候CPU直接去取FB沒啥困難……現在不一樣了，你CPU推給驅動的Command Queue都不一定會當場渲染了……

還是老老實實用FBO吧……

並沒有實際做過GL的開發，從其他API的經驗和GL的文檔裡面總結的

如果有啥不對的地方還請指教