2017-10-17 178 views
0

背景:我們的開發中遊戲在我們更新至iOS 10或11的設備上進行了性能潛水。兩款iPhone 6s的運行時間爲10.3 .3只能達到20-30fps,而iPhone 5s仍然以每秒60fps的速度順利通過8.0。與iOS9(OGLES2.0)相比,iOS10/11下的海量屏幕外渲染性能下降

最近我更新了iPod6從ios 9到ios 11,它也從60下降到20-30 fps,運行完全相同的遊戲構建。

注意:最初GPU分析器讓我相信這是一個着色器相關問題,但那是一個錯誤的線索。感謝所有在此基礎上評論的人。

下面是我已經收窄的問題了下來:

運行正常,我們的遊戲生成以下屏幕外的紋理每一幀:

  • 十選手的陰影,在256×256(無alpha混合參與)
  • 十128×256 256×256到動畫「電視屏幕」紋理
  • 一個256×512個「全球思考」的質感結合場景模型的一小部分。

在iPhone5s上,所有這些都以平穩的60fps進行。在iPod6和iPhone6s上,由於更新到iOS10/11,它努力達到30fps。

作爲測試,我將所有離屏渲染重定向到主幀緩衝區,禁用了深度檢查並啓用了對所有內容的Alpha混合,以確保任何內容都不會被tile渲染器優化。

結果是,遊戲被迫渲染的像素數量是以前的十倍(因爲填充256x256紋理的渲染現在全部填充640x1136屏幕),所有的alpha混合(在很多之前它沒有混合),它在iPod6上以60fps的速度高興地做到了這一點。

我知道我仍然可以對離屏渲染進行優化(我目前沒有標記用於丟棄的陰影紋理上的深度緩衝區),但這不是真正的重點:5s是處理未經優化的渲染效果還不錯,而iPod6也曾經使用過,所以在iOS 10/11下改變了什麼?

重現步驟:

  • 生成20小(256×256)的紋理和爲它們分配幀緩存。
  • 每一幀,爲每個紋理渲染幾個精靈,然後將紋理渲染到屏幕上。
  • OpenGL剖析這個設置。
  • 將所有精靈渲染重定向到屏幕(但保留'渲染紋理到屏幕'步驟)
  • 剖析此設置。在我的測試中,儘管精靈渲染必須覆蓋更多像素,但第二個設置的速度要快10ms。
+0

你在談論的OpenGL-ES,對不對?您定位的是哪個版本? – BDL

+0

OGLES2.0 - 現在添加到主帖。 – Peeling

+0

幾件事情要嘗試:1.用兩個獨立的vec2替換vec4 texcoord,可以避免依賴於紋理的讀取(儘管它們在新硬件上並不那麼糟糕)。 2.使用臨時vec4而不是多次寫入/修改gl_FragColor。 – Columbo

回答

0

根據我的測試,似乎某些iOS OGLES實現(特別是10.3.3和11)在優化交錯渲染到屏幕和離屏紋理方面的工作嚴重不足。

理想(1),從基於區塊的硬件在一幀期間渲染到多個目的地的角度來看,一個OpenGL實現將推遲儘可能長時的主幀緩衝區執行渲染命令,與效果解交錯該要求序列:

  • 繪製到主幀緩衝區
  • 繪製紋理1
  • 繪製紋理1主幀緩衝區
  • 繪製到紋理2
  • ...
  • 繪製紋理n至主幀緩衝區

到該視覺等效執行序列:

  • 繪製到紋理1
  • 繪製紋理2
  • ...
  • 繪製紋理Ñ
  • 繪製紋理1到主幀緩衝區
  • 繪製紋理2到主幀緩衝區
  • ...
  • 繪製紋理n至主幀緩衝區

後者序列是遠效率更高,因爲它避免了重複邏輯加載的需要,並且存儲主幀緩衝器的內容(2)

但是,從一個簡單的基準測試中可以看出,在更新版本的iOS中執行此優化的實施比以往更嚴重。

我的基準測試分配了10個256x256紋理和10個512x512紋理,併爲它們分配了一個幀緩衝區。然後每個框架都會爲每個紋理繪製大量的alpha混合精靈,然後將這些紋理渲染到屏幕(也是alpha混合)。我將它設置爲默認情況下以交錯順序進行,然後在觸摸屏幕時進行解交錯處理。

這裏是不變/觸摸(差)在所測試的範圍內的設備的結果:

  • iPhone 5S(iOS的8.0):14毫秒/ 11.5ms(爲2.5ms)
  • 的iPod 6gen(iOS11) :19ms/11.8ms(7.2ms)
  • iPhone6s(iOS10.3.3):17MS/8.2ms(8.8ms)

正如你可以看到,所有的設備從手動校正呈現順序中受益。然而,不這樣做的懲罰從iOS8下的2.5ms上升到類似硬件上的iOS11下高達7.2ms(在iPod上安裝iOS11之前,它順利運行我們的遊戲,所以我覺得得出這個推論是合理的)。無疑,由於屏幕分辨率更高,iPhone6的罰款更高。

懲罰可能部分歸因於邏輯加載和存儲,部分原因是由渲染到紋理之前的依賴關係引入的停頓,然後纔會被拖動到屏幕上。再說一遍:在一個將命令緩存到主幀緩衝區的實現中,那些停頓不會發生。

拒絕替代

邏輯加載和存儲有自己在成本大幅上升。

這將解釋觀察到的放緩,但不影響iPod和iPhone5s在手動解交錯渲染順序時的性能相似性。糾正後的訂單仍然需要大量的邏輯存儲(10mb),並且沒有明顯額外成本的證據。

參考文獻:

1:https://community.arm.com/graphics/b/blog/posts/mali-performance-2-how-to-correctly-handle-framebuffers

2:https://developer.apple.com/library/content/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/Performance/Performance.html