👫 🙍🏿 🧝🏽 iOSプラットフォーム向けのゲームの最適化。コードのベクトル化 👩‍👩‍👧‍👧 😖 🖐🏻

ARMv7 CPUアーキテクチャーおよびPowerVR SGX 5 GPUシリーズ向けにゲームを最適化するための経験と知識を説明できる記事を2、3書いて、iOSプラットフォームを読みたいという願望が長年にわたって高まってきました。しかし、すべてまたはほぼすべてのヒントは、同じハードウェアを備えた他のシステムにも同様に適用できます。Androidを読んでください。この素材は、ゲームだけでなく、画像処理、オーディオ、ビデオなど、最も要求の厳しいアプリケーションでも使用できます。 NEONのコードのベクトル化である、最も重要なIMHO最適化で最初の記事を始めます。

この記事は、24.11に開催される会議へのレポートとして始まりました。 iPhoneの最適化に関する豊富なヒントがここにあります。次の記事では、このプレゼンテーションの内容の幅と深さを拡大します。

NEONとは何ですか？ NEONは、ARMプロセッサで使用される汎用SIMDエンジンです。ボード上には、それぞれ128ビットの16個のレジスタがあり、64ビットの32個のレジスタと見なすことができます。 NEONは独自のパイプラインを持っていますが、VFPとレジスタを共有しています。 SSEと同様に、データは16バイトで整列する必要があります。 NEONは、非境界整列データの操作方法も知っていますが、通常は2倍遅くなります。

NEONは以下で動作します：

符号付き\符号なし8 \ 16 \ 32 \ 64ビット整数データ型。
単精度浮動小数点数-32ビット浮動小数点。

ゲームなどのマルチメディアタスクに最適です。

主なものから始めましょう-現代のすべてのモバイルシステムの中心、システムオンチップまたはSoC（System on Chip）。 iOS Aデバイスは、チップ上のApple Aシリーズのシステム-A4、A5、A5x、A6、およびA6xを使用することが知られています。これらのチップの最も重要な仕様を表に示します。

CPUの仕様	A4	A5	A5x	A6
建築	ARMv7	ARMv7	ARMv7	ARMv7
コア	皮質a8	皮質a9	皮質a9	独自の開発
＃コア	1	2	2	2
周波数、MHz	800	1000	1000	1300
拡張機能	VFPv3（VFPLite）、NEON	VFPv3、NEON	VFPv3、NEON	VFPv4、NEON
GPUの仕様
モデル	PowerVR SGX 535	PowerVR SGX 543MP2	PowerVR SGX 543MP4	PowerVR SGX 543MP3
周波数、MHz	200	200	200	266

*注：NEONはCPU周波数で実行されます

NEONの周波数はGPUに比べて5倍高いことがわかります。もちろん、これは、IPC、パイプラインなど、GPUと比較してパフォーマンスが5倍向上するという意味ではありません。重要です。ただし、NEONには1つの機能キラーがあります。4つの32ビットフロートを同時に処理できますが、PowerVR SGXは1つだけです。 GPUは4つの半精度浮動小数点数（16ビット）を同時に処理できるため、PowerVR SGX 5シリーズSIMDレジスタの長さは64ビットのようです。例を考えてみましょう：

highp vec4 v1, v2; highp float s1, s2; //  v2 = (v1 * s1) * s2; //v1 * s1      – 4 ,       s2,     -  4 . //8    //  v2 = v1 * (s1 * s2); //s1 * s2 – 1    ;  * v1 – 4   . //5

次に、GPUベクトルエンジンで実行される別の例を考えます。

 mediump vec4 v1, v2, v3; highp vec4 s1, s2, s3; v3 = v1 * v2; //    – 1  s3 = s1 * s2; //    – 4

たとえば、頂点の位置など、データのhighp指定子が必要になります。 NEONからの利益はここで明白です。

次に、NEONの別の利点に移りましょう。 PowerVR SGX 5シリーズには、処理するシェーダーの種類、頂点、ピクセルを問わないシェーダープロセッサであるUSSEが搭載されています。つまり、プログラマーには一定の電力バジェットがあり、頂点処理に費やすかピクセル処理に費やすかはプログラマー次第です。ここでNEONが助けになります-これが新しい頂点プロセッサです。ここにトロールフェイスを挿入するのを忘れたと思うかもしれませんが、それはすべて非常に深刻です。ほぼすべてのモバイルシステムのパフォーマンスは、特に2Dゲーム、特に最近の画面解像度の競争において、フィルレートによって制限されます。すべての頂点処理をNEONに転送すると、ピクセル処理用のリソースが解放されます。これに加えて、NEONは描画呼び出しの回数を減らすのに役立ちます-1つのバッチのすべての頂点の位置をワールド座標で計算し、1つの呼び出しでN個のオブジェクトを描画します。

理論は終わりました！さあ、ハードコアを始めましょう！ NEONを活用する方法はいくつかあります。

コンパイラにコードをベクトル化させます。悪い方法。コンパイラーはベクトル化するか、ベクトル化しない場合があります。コンパイラがコードをベクトル化しても、これが最良のコードになるという事実からはほど遠い。しかし、一方で、この方法はあなたの側での努力を必要とせず、利益を得ることができます。それでも、盲目的にコンパイラに頼るのではなく、少なくとも最も重要なコードを手動でベクトル化する必要があります。
NEONアセンブラー。そして、ここで彼はハードコアです。真のジェダイとそのすべての道。ダークマジックを学び、ARMのマニュアルに一晩を費やす必要があります。 NEONコードはARMモードとThumb-2モードの両方で機能することにも留意してください。
NEON組み込み関数（x86のSSEと同じ）。コンパイラが指定されたものを愚かに挿入するアセンブラとは異なり、組み込み関数は最適化されます。彼らと一緒に暮らすことははるかに簡単です-命令のタイミングを研究したり、パイプの停滞を避けるためにそれらをシャッフルする必要はありません
既にベクトル化されたコード-GLKMath、数学ネオンで使用します。

それぞれの方法の長所と短所をすべて発見する時が来ました。これを行うために、単純なデモを作成しました。10,000個のスプライトの各フレームは、画面内で位置をランダムに変更します。目標は、最小限のCPU負荷で最速のコードを取得することです。結局のところ、ゲームでは、レンダリング用のデータに加えて、多くをカウントする必要があります。

すべてのデータは1つのVBOに保存されます。 Updateメソッドは、射影行列にランダムな位置のModelView行列を乗算します。次に、各スプライトの各頂点に、結果のModelViewProjectionマトリックスが乗算されます。各頂点の最終位置は、単に頂点シェーダーのgl_Positionに渡されます。すべてのデータは16バイトの境界に揃えられます。

メソッド更新コード：

 void Update() { GLKMatrix4 modelviewMat = { 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, 0, 0, 0, 0, 1, }; const u32 QUADS_COUNT = 10000; const u32 VERTS_PER_QUAD = 4; const float Y_DELTA = 420.0f / QUADS_COUNT; //     Y float vertDelta = Y_DELTA; for (int i = 0; i < QUADS_COUNT * VERTS_PER_QUAD; i += VERTS_PER_QUAD) { float randX = random() % 260; //     modelviewMat.m[12] = randX; modelviewMat.m[13] = vertDelta; float32x4x4_t mvp; Matrix4ByMatrix4((float32x4x4_t*)proj.m, (float32x4x4_t*)modelviewMat.m, &mvp); for (int j = 0; j < 4; ++j) { Matrix4ByVec4(&mvp, &squareVertices[j], &data[i + j].pos); } vertDelta += Y_DELTA; } glBindBuffer(GL_ARRAY_BUFFER, vertexBuffer); glBufferData(GL_ARRAY_BUFFER, sizeof(data), data, GL_STREAM_DRAW); }

さて、今度はこの記事の本質であるコードのベクトル化について説明します。次に、ゲーム開発で最も頻繁に使用される操作の3つの比較アプローチで使用されるコードを示します。ベクトルによる行列乗算と行列による行列乗算です。

GLKMathを使用したコピーペースト：

 static __inline__ GLKVector4 GLKMatrix4MultiplyVector4(GLKMatrix4 matrixLeft, GLKVector4 vectorRight) { float32x4x4_t iMatrix = *(float32x4x4_t *)&matrixLeft; float32x4_t v; iMatrix.val[0] = vmulq_n_f32(iMatrix.val[0], (float32_t)vectorRight.v[0]); iMatrix.val[1] = vmulq_n_f32(iMatrix.val[1], (float32_t)vectorRight.v[1]); iMatrix.val[2] = vmulq_n_f32(iMatrix.val[2], (float32_t)vectorRight.v[2]); iMatrix.val[3] = vmulq_n_f32(iMatrix.val[3], (float32_t)vectorRight.v[3]); iMatrix.val[0] = vaddq_f32(iMatrix.val[0], iMatrix.val[1]); iMatrix.val[2] = vaddq_f32(iMatrix.val[2], iMatrix.val[3]); v = vaddq_f32(iMatrix.val[0], iMatrix.val[2]); return *(GLKVector4 *)&v; } static __inline__ GLKMatrix4 GLKMatrix4Multiply(GLKMatrix4 matrixLeft, GLKMatrix4 matrixRight) { float32x4x4_t iMatrixLeft = *(float32x4x4_t *)&matrixLeft; float32x4x4_t iMatrixRight = *(float32x4x4_t *)&matrixRight; float32x4x4_t m; m.val[0] = vmulq_n_f32(iMatrixLeft.val[0], vgetq_lane_f32(iMatrixRight.val[0], 0)); m.val[1] = vmulq_n_f32(iMatrixLeft.val[0], vgetq_lane_f32(iMatrixRight.val[1], 0)); m.val[2] = vmulq_n_f32(iMatrixLeft.val[0], vgetq_lane_f32(iMatrixRight.val[2], 0)); m.val[3] = vmulq_n_f32(iMatrixLeft.val[0], vgetq_lane_f32(iMatrixRight.val[3], 0)); m.val[0] = vmlaq_n_f32(m.val[0], iMatrixLeft.val[1], vgetq_lane_f32(iMatrixRight.val[0], 1)); m.val[1] = vmlaq_n_f32(m.val[1], iMatrixLeft.val[1], vgetq_lane_f32(iMatrixRight.val[1], 1)); m.val[2] = vmlaq_n_f32(m.val[2], iMatrixLeft.val[1], vgetq_lane_f32(iMatrixRight.val[2], 1)); m.val[3] = vmlaq_n_f32(m.val[3], iMatrixLeft.val[1], vgetq_lane_f32(iMatrixRight.val[3], 1)); m.val[0] = vmlaq_n_f32(m.val[0], iMatrixLeft.val[2], vgetq_lane_f32(iMatrixRight.val[0], 2)); m.val[1] = vmlaq_n_f32(m.val[1], iMatrixLeft.val[2], vgetq_lane_f32(iMatrixRight.val[1], 2)); m.val[2] = vmlaq_n_f32(m.val[2], iMatrixLeft.val[2], vgetq_lane_f32(iMatrixRight.val[2], 2)); m.val[3] = vmlaq_n_f32(m.val[3], iMatrixLeft.val[2], vgetq_lane_f32(iMatrixRight.val[3], 2)); m.val[0] = vmlaq_n_f32(m.val[0], iMatrixLeft.val[3], vgetq_lane_f32(iMatrixRight.val[0], 3)); m.val[1] = vmlaq_n_f32(m.val[1], iMatrixLeft.val[3], vgetq_lane_f32(iMatrixRight.val[1], 3)); m.val[2] = vmlaq_n_f32(m.val[2], iMatrixLeft.val[3], vgetq_lane_f32(iMatrixRight.val[2], 3)); m.val[3] = vmlaq_n_f32(m.val[3], iMatrixLeft.val[3], vgetq_lane_f32(iMatrixRight.val[3], 3)); return *(GLKMatrix4 *)&m; }

Appleのこれらの操作の実装では、値から変数を転送し、変数をコピーするという、最適なアプローチとはほど遠い方法を使用していることがわかります。少なくともデバッグアセンブリでは、かなり遅く見えます。プロファイリング中にこのコードがどのように表示されるかを見てみましょう。

アセンブラーのアプローチ：

 inline void Matrix4ByVec4(float32x4x4_t* __restrict__ mat, const float32x4_t* __restrict__ vec, float32x4_t* __restrict__ result) { asm ( "vldmia %0, { d24-d31 } \n\t" "vld1.32 {q1}, [%1]\n\t" "vmul.f32 q0, q12, d2[0]\n\t" "vmla.f32 q0, q13, d2[1]\n\t" "vmla.f32 q0, q14, d3[0]\n\t" "vmla.f32 q0, q15, d3[1]\n\t" "vstmia %2, { q0 }" : : "r" (mat), "r" (vec), "r" (result) : "memory", "q0", "q1", "q8", "q9", "q10", "q11" ); } inline void Matrix4ByMatrix4(const float32x4x4_t* __restrict__ m1, const float32x4x4_t* __restrict__ m2, float32x4x4_t* __restrict__ r) { asm ( "vldmia %1, { q0-q3 } \n\t" "vldmia %2, { q8-q11 }\n\t" "vmul.f32 q12, q8, d0[0]\n\t" "vmul.f32 q13, q8, d2[0]\n\t" "vmul.f32 q14, q8, d4[0]\n\t" "vmul.f32 q15, q8, d6[0]\n\t" "vmla.f32 q12, q9, d0[1]\n\t" "vmla.f32 q13, q9, d2[1]\n\t" "vmla.f32 q14, q9, d4[1]\n\t" "vmla.f32 q15, q9, d6[1]\n\t" "vmla.f32 q12, q10, d1[0]\n\t" "vmla.f32 q13, q10, d3[0]\n\t" "vmla.f32 q14, q10, d5[0]\n\t" "vmla.f32 q15, q10, d7[0]\n\t" "vmla.f32 q12, q11, d1[1]\n\t" "vmla.f32 q13, q11, d3[1]\n\t" "vmla.f32 q14, q11, d5[1]\n\t" "vmla.f32 q15, q11, d7[1]\n\t" "vstmia %0, { q12-q15 }" : : "r" (result), "r" (m2), "r" (m1) : "memory", "q0", "q1", "q2", "q3", "q8", "q9", "q10", "q11", "q12", "q13", "q14", "q15" ); }

アセンブラーに慣れていない人にとっては、すべてがかなり怖いようです-私自身もそうです、私はNEONアセンブラーしか理解できません。しかし、実際には、ここではすべてが単純です。実際には、 q1〜q15はNEONレジスタです。 vldmia \ vld1.32-ダウンロード手順。 vstmia-メモリ内の保存。 vmul.f32 \ vmla.f32-乗算\乗算および加算。

組み込みメソッド：

 inline void Matrix4ByVec4(float32x4x4_t* __restrict__ mat, const float32x4_t* __restrict__ vec, float32x4_t* __restrict__ result) { (*result) = vmulq_n_f32((*mat).val[0], (*vec)[0]); (*result) = vmlaq_n_f32((*result), (*mat).val[1], (*vec)[1]); (*result) = vmlaq_n_f32((*result), (*mat).val[2], (*vec)[2]); (*result) = vmlaq_n_f32((*result), (*mat).val[3], (*vec)[3]); } inline void Matrix4ByMatrix4(const float32x4x4_t* __restrict__ m1, const float32x4x4_t* __restrict__ m2, float32x4x4_t* __restrict__ r) { (*r).val[0] = vmulq_n_f32((*m1).val[0], vgetq_lane_f32((*m2).val[0], 0)); (*r).val[1] = vmulq_n_f32((*m1).val[0], vgetq_lane_f32((*m2).val[1], 0)); (*r).val[2] = vmulq_n_f32((*m1).val[0], vgetq_lane_f32((*m2).val[2], 0)); (*r).val[3] = vmulq_n_f32((*m1).val[0], vgetq_lane_f32((*m2).val[3], 0)); (*r).val[0] = vmlaq_n_f32((*r).val[0], (*m1).val[1], vgetq_lane_f32((*m2).val[0], 1)); (*r).val[1] = vmlaq_n_f32((*r).val[1], (*m1).val[1], vgetq_lane_f32((*m2).val[1], 1)); (*r).val[2] = vmlaq_n_f32((*r).val[2], (*m1).val[1], vgetq_lane_f32((*m2).val[2], 1)); (*r).val[3] = vmlaq_n_f32((*r).val[3], (*m1).val[1], vgetq_lane_f32((*m2).val[3], 1)); (*r).val[0] = vmlaq_n_f32((*r).val[0], (*m1).val[2], vgetq_lane_f32((*m2).val[0], 2)); (*r).val[1] = vmlaq_n_f32((*r).val[1], (*m1).val[2], vgetq_lane_f32((*m2).val[1], 2)); (*r).val[2] = vmlaq_n_f32((*r).val[2], (*m1).val[2], vgetq_lane_f32((*m2).val[2], 2)); (*r).val[3] = vmlaq_n_f32((*r).val[3], (*m1).val[2], vgetq_lane_f32((*m2).val[3], 2)); (*r).val[0] = vmlaq_n_f32((*r).val[0], (*m1).val[3], vgetq_lane_f32((*m2).val[0], 3)); (*r).val[1] = vmlaq_n_f32((*r).val[1], (*m1).val[3], vgetq_lane_f32((*m2).val[1], 3)); (*r).val[2] = vmlaq_n_f32((*r).val[2], (*m1).val[3], vgetq_lane_f32((*m2).val[2], 3)); (*r).val[3] = vmlaq_n_f32((*r).val[3], (*m1).val[3], vgetq_lane_f32((*m2).val[3], 3)); }

GLKMathとほぼ同じコードですが、わずかな違いがあります。説明： vmulq_n_f32-ベクトルとスカラーの乗算。 vgetq_lane_f32-ベクトルからスカラーを選択するマクロ。 vmlaq_n_f32-スカラーを乗算して加算します。このコードは、アセンブラーを組み込み関数に単に反映したものです。彼が彼と比較してどのように彼自身を示すか見てみましょう。

iPod Touch 4でテストを行いました。表には、更新機能のプロファイリング結果が含まれています。

アプローチ	実行時間、ミリ秒	CPU負荷、％
FPU	6058 + 5067 *	35〜38
GLKMath	2789	20-23
アセンブラー	5304	23-25
真性	2803	18-20

* Instrumentsのスクリーンショットでは、Matrix4ByMatrix4関数がインライン化されていないことがわかります。

ここに別のヒントがあります-パフォーマンスが重要なコードを積極的にインライン化します。このような場合は、通常のインラインよりも__attribute __（（always_inline））を優先してください 。

更新された結果表：

アプローチ	実行時間、ミリ秒	CPU負荷、％
FPU強制インライン化	6209	25〜28
GLKMath	2789	20-23
アセンブラー	5304	23-25
真性	2803	18-20

強制インライン化により、パフォーマンスが非常に向上しました！コードの自動ベクトル化がどのように表示されるかを見てみましょう。必要なのは、プロジェクト設定のその他のCフラグに–mllvm –vectorize –mllvm –bb-vectorize-aligned-onlyを追加することだけです。

最終結果表：

アプローチ	実行時間、ミリ秒	実行時間（ベクトル）、ms	CPU負荷、％	CPU負荷（ベクトル）、％
FPU強制インライン化	6209	5028	25〜28	22-24
GLKMath	2789	2776	20-23	20-23
アセンブラー	5304	5291	23-25	22-24
真性	2803	2789	18-20	18-20

アセンブラーと組み込み関数の場合、かなり奇妙な結果が観察されます-実際にはコードは同じですが、結果は劇的に異なります-ほぼ2回です！この質問に対する答えは、アセンブリのリスト（自分で調べたい人）にあります。アセンブラの場合、リストに書いたものを正確に見ることができます。組み込み関数の場合、コンパイラはコードを最適化しました。ゆっくり、一見したところ、GLKMathコードコンパイラは完全に最適化されており、手動で記述された組み込み関数と同じコード実行時間を与えました。

スクリーンショットの結果

FPU強制インライン化

FPU自動ベクトル化

GLKMath

アセンブラー

真性

在庫を取る時です。いくつかの結論を引き出すことができます。

LLVMのエンジニアは素晴らしい仕事をしました。その結果、コンパイラは最適化された組み込みコードを生成します。 Xcodeの唯一のコンパイラがGCC 4.2で、1年以上前に同様のテストを行いましたが、FPUコードと比較してパフォーマンスが10〜15％しか向上しませんでした。これは素晴らしいニュースです。アセンブラーを学ぶ必要はなく、私はそれについて非常に満足しています！
clangコンパイラは、コードを自動ベクトル化できます。プログラマーにとって、これはたった4語で書くことによるパフォーマンスボーナスです。これがクールなものであることを除いて、私は他に何を言うことができますか？！
NEONコードは、通常のCコードに比べてパフォーマンスが2.22倍向上しています。最適化の結果、頂点処理はこれらの頂点をGPU側にコピーするよりも高速になりました！ memcpyアセンブラーを見ると、そこでNEONコードも使用されていることがわかります。 Cortex A8にハードウェアダニがないため、コードが遅くなります。
特にあなたの目標がプロになることである場合、これらすべての低レベルのことを学ぶことは価値があります。

参照資料

www.arm.com/products/processors/technologies/neon.php

blogs.arm.com/software-enablement/161-coding-for-neon-part-1-load-and-stores

code.google.com/p/math-neon

llvm.org/devmtg/2012-04-12/Slides/Hal_Finkel.pdf

デモプロジェクト

iOSプラットフォーム向けのゲームの最適化。 コードのベクトル化

参照資料

More articles:

iOSプラットフォーム向けのゲームの最適化。コードのベクトル化