MAPS.MEのApple Metal

みなさんこんにちは！

世界にはOpenGL上に膨大な数のアプリケーションがあり、Appleはこれにまったく同意していないようです。 iOS 12およびMacOS Mojaveから、OpenGLは非推奨になりました。 Apple MetalをMAPS.MEに統合し、経験と結果を共有する準備が整いました。 グラフィックエンジンをリファクタリングする方法、直面しなければならない困難、そして最も重要なことは、現在FPSがいくつあるかを説明します。

グラフィックエンジンにApple Metalサポートを追加することに興味があるか、検討している人は誰でもcatを歓迎します。

発行

私たちのグラフィックエンジンはクロスプラットフォームとして設計されており、実際、OpenGLは私たちが興味を持っている一連のプラットフォーム（iOS、Android、MacOS、Linux）のための唯一のクロスプラットフォームグラフィックAPIであるため、それをベースとして選択しました。 OpenGL固有の機能を隠す追加の抽象化レベルは作成しませんでしたが、幸いなことに、その実装の可能性は残されていました。

新世代のグラフィックスAPIであるApple MetalとVulkanの出現により、もちろん、アプリケーションでそれらが出現する可能性を検討しましたが、次のことをやめました。

1. VulkanはAndroidとLinuxでのみ動作し、Apple MetalはiOSとMacOSでのみ動作しました。 グラフィックAPIのレベルでクロスプラットフォーム性を失いたくありませんでした。これにより、開発とデバッグのプロセスが複雑になり、作業量が増加します。
2. Apple Metal上のアプリケーションは、iOSシミュレータ上でビルドして実行することはできません（これまでのところ）。これは開発を複雑にし、OpenGLを完全に削除することもできません。
3. 内部ツールの作成に使用するQtフレームワークは、OpenGLのみをサポートしました（ Vulkanがサポートされるようになりました ）。
4. Apple MetalにはC ++ APIがありませんでした。これにより、ランタイムだけでなく、エンジンの一部がObjective-C ++でコンパイルされている場合、アプリケーションのビルド段階でも抽象化が必要になります。
5. iOS専用のエンジンまたはコードブランチを個別に作成する準備ができていませんでした。
6. 1人のグラフィック開発者の作業で、少なくとも6か月間、実装が評価されました。

2018年春にAppleがOpenGLの廃止予定ステータスへの移行を発表したとき、延期することはもはや不可能であり、上記の問題は何らかの方法で解決する必要があることが明らかになりました。 さらに、私たちはアプリケーションの速度と消費電力の両方の最適化に長い間取り組んできましたが、Apple Metalが助けになったようです。

決定の選択

すぐにMoltenVKに気付きました 。 このフレームワークはApple Metalを使用してVulkan APIをエミュレートし、そのソースコードは最近公開されました。 MoltenVKを使用すると、OpenGLをVulkanに置き換えることができ、Apple Metalの個別の統合に対処する必要がまったくないようです。 さらに、Qt開発者はMoltenVKを支持してApple Metalでのレンダリングの個別サポートを拒否しました。 ただし、停止しました。

• Vulkanが利用できないAndroidデバイスをサポートする必要性。
• OpenGLにフォールバックが存在しないと、iOSシミュレーターで起動できない。
• MoltenVKがSPIR-VまたはGLSLソースコードからApple Metalのリアルタイムシェーダーを生成するため、シェーダーのデバッグ、プロファイリング、およびプリコンパイルにAppleツールを使用できない。
• Metalの新しいバージョンがリリースされたとき、MoltenVKの更新とバグ修正を待つ必要。
• Metalに固有の微妙な最適化は不可能ですが、Vulkanには固有ではないか、存在しません。

OpenGLを保存する必要があることがわかりました。つまり、グラフィカルAPIからエンジンを抽象化しないと、できません。 Apple Metal、OpenGL ES、および将来的にはVulkanを使用して、グラフィックエンジンの独立した内部コンポーネントを作成します。これらは完全に交換可能です。 何らかの理由でMetalまたはVulkanが利用できない場合、OpenGLはフォールバックオプションの役割を果たします。

実装計画は次のとおりでした。

1. 使用されるグラフィックスAPIを抽象化するグラフィックスエンジンリファクタリング。
2. iOSバージョンのアプリのApple Metalにレンダリングします。
3. レンダリング速度と消費電力の適切なベンチマークを行い、最新の低レベルのグラフィックスAPIが製品に役立つかどうかを確認します。

OpenGLとMetalの主な違い

グラフィカルAPIを抽象化する方法を理解するために、まずOpenGLとMetalの主要な概念上の違いを判断しましょう。

1. Metalは低レベルのAPIであると考えられますが、理由はありません。 ただし、これはアセンブラーで記述したり、ラスタライズを自分で実装する必要があるという意味ではありません。 Metalは、非常に少数の暗黙的なアクションを実行するという意味で、低レベルAPIと呼ばれます。つまり、ほとんどすべてのアクションはプログラマー自身に書き込まれる必要があります。 OpenGLは、OpenGLコンテキストへの暗黙的な参照をサポートし、このコンテキストを作成されたストリームにリンクすることから始めて、暗黙的に多くのことを行います。
2. Metalでは、チームのリアルタイム検証は「ありません」。 デバッグモードでは、もちろん検証が存在し、Xcodeとの緊密な統合のおかげで、他の多くのAPIよりもはるかに優れています。 しかし、プログラムがユーザーに送信されると、検証は行われなくなり、プログラムは最初のエラーで単純にクラッシュします。 言うまでもなく、OpenGLは最も極端な場合にのみクラッシュします。 最も一般的な方法は、エラーを無視して作業を続行することです。
3. Metalはシェーダーをプリコンパイルし、そこからライブラリを構築できます。 OpenGLでは、シェーダーはプログラムのプロセスでソースからコンパイルされます。これは、特定のデバイスでのOpenGLの特定の低レベル実装を担当するためです。 シェーダーコンパイラの実装の違いやエラーは、特に中国ブランドのAndroidデバイスで、素晴らしいバグを引き起こすことがあります。
4. OpenGLは、ほとんどすべての機能に副作用を追加するステートマシンを積極的に使用します。 したがって、OpenGL関数は純粋な関数ではなく、順序と呼び出し履歴が重要になることがよくあります。 Metalは暗黙的にステートを使用せず、レンダリングに必要な状態よりも長く保持しません。 状態は、事前に作成され、失敗したオブジェクトとして存在します。

グラフィックエンジンのリファクタリングと埋め込み

グラフィックエンジンをリファクタリングするプロセスは、基本的に、エンジンが積極的に使用しているOpenGL機能を取り除くための最適なソリューションを見つけることで構成されていました。 いずれかの段階から始まる埋め込み金属は、並行して実行されました。

• 既に述べたように、OpenGL APIにはコンテキストと呼ばれる暗黙的なエンティティがあります。 コンテキストは特定のスレッドに関連付けられており、そのスレッドで呼び出されるOpenGL関数はこのコンテキストを見つけて使用します。 Metal、Vulkan（はい、およびDirect3Dなどの他のAPI）はこの方法では機能せず、デバイスまたはインスタンスと呼ばれる同様の明示的なオブジェクトを持っています。 ユーザー自身がこれらのオブジェクトを作成し、異なるサブシステムへの転送を担当します。 これらのオブジェクトを介して、グラフィックコマンドへのすべての呼び出しが行われます。
  
  抽象オブジェクトをグラフィカルコンテキストと呼び、OpenGLの場合はOpenGLコマンドの呼び出しを単に装飾し、Metalの場合はMetalコマンドを呼び出すMTLDeviceルートインターフェイスを含みます。
  
  もちろん、すべてのサブシステムにこのオブジェクトを分散しなければなりませんでした（そして、マルチスレッドレンダリングを使用しているため、このようなオブジェクトもいくつかありました）。
  
  OpenGLには存在しないエンティティを広めないように、コマンド、エンコーダー、およびそれらの管理をグラフィカルコンテキスト内に作成することを隠しました。
• ユーザーデバイス上のグラフィックコマンドの検証が消える見込みは、私たちにとって公然と喜ばれませんでした。 QA部門では、さまざまなデバイスとOSバージョンを完全にカバーできませんでした。 そのため、以前にグラフィカルAPIから意味のあるエラーを受け取った場所に詳細なログを追加する必要がありました。 もちろん、この検証はグラフィックエンジンの潜在的に危険で重要な場所にのみ追加されました。これは、エンジン全体を診断コードで覆うことは実際上不可能であり、一般にパフォーマンスに有害であるためです。 新しい現実は、ユーザーのテストとログのデバッグが、少なくともレンダリングに関しては過去のものになったことです。
• 以前のシェーダーシステムはリファクタリングに適していないため、完全に書き直す必要がありました。 ここでのポイントは、シェーダーのプリコンパイルとプロジェクトアセンブリの段階での検証だけではありません。 OpenGLは、いわゆる均一変数を使用して、パラメーターをシェーダーに渡します。 構造化データ転送はOpenGL ES 3.0でのみ使用でき、OpenGL ES 2.0を引き続きサポートしているため、この方法は使用しませんでした。 Metalはデータ構造を使用してパラメーターを渡すことを余儀なくされ、OpenGLの場合、構造フィールドを統一変数にマッピングする必要がありました。 さらに、Metal Shading Languageで各シェーダーを書き直す必要がありました。
• 状態オブジェクトを使用するとき、私たちはトリックに行かなければなりませんでした。 OpenGLでは、すべての状態は、原則として、レンダリングの直前に設定され、Metalでは、以前に作成および検証されたオブジェクトである必要があります。 明らかに、私たちのエンジンはOpenGLアプローチを使用しており、状態オブジェクトの予備作成によるリファクタリングは、エンジンの完全な書き直しに対応しています。 このノードをカットするために、グラフィカルコンテキスト内に状態キャッシュを作成しました。 状態パラメーターの一意の組み合わせが初めて生成されると、状態オブジェクトがMetalで作成され、キャッシュに配置されます。 2回目以降は、オブジェクトは単にキャッシュから取得されます。 状態パラメーターのさまざまな組み合わせの数が多すぎない（約20〜30）ため、これはマップで機能します。 複雑なゲームグラフィックエンジンの場合、この方法はあまり適していません。

その結果、約5か月の作業の後、Apple Metalで完全なレンダリングを行って初めてMAPS.MEを起動することができました。 何が起こったのかを知る時が来ました。

レンダリング速度のテスト

実験手法

実験では、異なる世代のAppleデバイスを使用しました。 それらはすべてiOS 12に更新されました。同じユーザースクリプトがすべてで実行されました-マップナビゲーション（移動とスケーリング）。 スクリプトは、各デバイスで起動されるたびに、アプリケーション内のプロセスのほぼ完全な識別を保証するためにスクリプト化されました。 テスト場所として、ロサンゼルスエリアを選択しました。これは、MAPS.MEで最も負荷の高いエリアの1つです。

最初に、OpenGL ES 3.0でレンダリングしてスクリプトを実行し、次にApple Metalでレンダリングした同じデバイスで実行しました。 起動の間に、アプリケーションはメモリから完全にアンロードされました。
次の指標が測定されました。

• フレーム全体のFPS（1秒あたりのフレーム数）。
• データの準備やその他のフレームごとの操作を除く、レンダリングのみを扱うフレームの部分のFPS。
• 遅いフレームの割合（最大30ミリ秒）、つまり 人間の目がぎこちないように知覚できるもの。

FPSを測定する場合、デバイスの画面に直接描画することは除外されました。これは、画面のリフレッシュレートとの垂直同期では信頼できる結果が得られないためです。 したがって、フレームはメモリ内のテクスチャに描画されました。 CPUとGPUを同期するために、OpenGLはglFinishへの追加の呼び出しを使用し、Apple MetalはwaitUntilCompletedにMTLFrameCommandBuffer使用しMTLFrameCommandBuffer 。

	iPhone 6s		iPhone 7以降		iPhone 8
	Opengl	メタル	Opengl	メタル	Opengl	メタル
Fps	106	160	159	221	196	298
FPS（レンダリングのみ）	157	596	247	597	271	833
遅いフレームの割合（<30 fps）	4.13％	1.25％	5.45％	0.76％	1.5％	0.29％

	iPhone X		iPad Pro 12.9 '
	Opengl	メタル	Opengl	メタル
Fps	145	210	104	137
FPS（レンダリングのみ）	248	705	147	463
遅いフレームの割合（<30 fps）	0.15％	0.15％	17.52％	4.46％

	iPhone 6s	iPhone 7以降	iPhone 8	iPhone X	iPad Pro 12.9 '
Metal上のフレームの加速（N回）	1,5	1.39	1,52	1.45	1.32
メタルレンダリングアクセラレーション（N回）	3.78	2.41	3.07	2.84	3.15
スローフレームの改善（N回）	3.3	7.17	5.17	1	3.93

結果分析

Apple Metalを使用したフレームパフォーマンスの向上は平均で43％でした。 iPad Pro 12.9で最小値は固定-32％、iPhone 8では最大-52％。画面解像度が低いほど、Apple MetalがOpenGL ES 3.0を上回ります。

レンダリングに直接関与するフレームの部分を評価すると、Apple Metalのレンダリング速度は平均で3倍になりました。 これは、組織が大幅に改善されていることを示し、その結果、OpenGL ES 3.0と比較してApple Metal APIの効率が向上しています。

Apple Metalでの低速フレーム（〜30 ms以上）の数は、約4倍減少しました。 これは、アニメーションの認識とマップ内の移動がよりスムーズになったことを意味します。 最悪の結果はiPad Pro 12.9に記録され、解像度は2732 x 2048ピクセルでした。OpenGLES 3.0は約17.5％の低速フレームを提供しますが、Apple Metalはわずか4.5％です。

電力試験

実験手法

iOS 12上のiPhone 8で消費電力をテストしました。同じユーザーシナリオを実行しました-1時間のマップナビゲーション（移動とスケーリング）。 スクリプトは、各起動時にアプリケーション内のプロセスのほぼ完全な識別を保証するためにスクリプト化されました。 ロサンゼルス地域もテスト場所として選ばれました。

エネルギー消費の測定には、次のアプローチを使用しました。 デバイスが充電に接続されていません。 開発者の設定では、電力ログが有効になっています。 実験を開始する前に、デバイスは完全に充電されています。 実験はスクリプトの終わりで終了します。 実験の最後に、バッテリーの充電状態が記録され、Xcodeでバッテリーのプロファイルを作成するために、電力消費ログがユーティリティにインポートされました。 GPUに費やされた金額を記録しました。 さらに、メトロスキームの表示とフルスクリーンアンチエイリアスを含めることで、レンダリングをさらに複雑にしました。

画面の明るさは、すべての場合で変化しませんでした。 systemおよびMAPS.ME以外のプロセスは実行されませんでした。 機内モードがオンになり、Wi-FiとGPSがオフになりました。 さらに、いくつかの制御測定が実行されました。

その結果、各指標について、MetalとOpenGLの比較が行われ、その後、比率が平均化されて1つの集計された推定値が得られました。

	Opengl	メタル	ゲイン
バッテリー消耗	32％	28％	12.5％
Xcodeでのバッテリー使用量のプロファイリング	1.95％	1.83％	6.16％

結果分析

Apple Metalのレンダリングバージョンの消費電力は、平均してわずかに改善されています。 GPUの使用に関してMAPS.MEを高負荷と呼ぶことはできないため、GPUアプリケーションの消費電力は約2％ほどの影響を受けません。 CPUでGPUの命令を準備する際の計算コストを削減することで、おそらくわずかな利益が得られますが、残念ながら、プロファイリングツールでは区別できません。

まとめ

Metalを埋め込むと、開発に5か月かかりました。 ただし、ほとんどの場合、2人の開発者が順番にこれを行いました。 明らかに、レンダリングパフォーマンスが大幅に向上し、エネルギー消費がわずかに向上しました。 さらに、新しいグラフィックAPI、特にVulkanをはるかに少ない労力で埋め込む機会がありました。 グラフィックエンジンをほぼ完全に「整理」し、その結果、いくつかの古いバグとパフォーマンスの問題を見つけて修正しました。

私たちのプロジェクトが本当にApple Metalでのレンダリングを必要とするかどうかという質問に、私たちは肯定的に答える用意ができています。 私たちがイノベーションを愛しているのではなく、AppleがついにOpenGLを放棄できるのではありません。 それはちょうど2018年であり、OpenGLは1997年に登場しました。次のステップに進むときです。

PSすべてのiOSデバイスでこの機能を開始するまで。 手動でオンにするには、検索バーに?metalして、アプリケーションを再起動します。 レンダリングをOpenGLに戻すには、 ?glコマンドを入力して、アプリケーションを再起動します。

PPS MAPS.MEは、オープンソースプロジェクトです。 ソースコードはgithubで読むことができます。