Mixed reality のパフォーマンスについてUnderstanding performance for mixed reality

この記事では、Mixed Reality アプリのパフォーマンスの合理化の概要について説明します。This article is an introduction into rationalizing the significance of performance for your Mixed Reality app. アプリケーションが最適なフレームレートで実行されない場合、ユーザーエクスペリエンスが大幅に低下する可能性があります。User experience can be greatly degraded if your application does not run at optimal frame rate. ホログラムが不安定になり、環境のヘッドトラッキングが不適切になり、ユーザーのエクスペリエンスが悪くなります。Holograms will appear unstable and head tracking of the environment will be inaccurate leading to an poor experience for the user. 実際には、パフォーマンスは、安定したサイクル終了タスクではなく、混合現実の開発のためのファーストクラスの機能と見なす必要があります。Indeed, performance must be considered as a first class feature for Mixed Reality development and not a stabilization, end of cycle task.

確認のために、各ターゲットプラットフォームのパフォーマンスの高いフレームレート値を以下に示します。For review, the performant framerate values for each target platform are listed below.

プラットフォームPlatform ターゲットフレームレートTarget Frame Rate
HoloLensHoloLens 60 FPS60 FPS
Windows Mixed Reality ウルトラ PcWindows Mixed Reality Ultra PCs 90 FPS90 FPS
Windows Mixed Reality PcWindows Mixed Reality PCs 60 FPS60 FPS

以下のフレームワークは、ベストプラクティスとターゲットフレームレートの異なればに対する一般的な概要を示しています。The framework below gives a general outline for best practices and understandings towards hitting target frame rates. 詳細について詳しくは、 「Unity のパフォーマンスに関する推奨事項」を参照してください。To dive further into details, consider reading the performance recommendations for Unity article. 特に、この関連記事では、Unity Windows Mixed Reality アプリでフレームレートを測定する方法と、Unity 環境でパフォーマンスを向上させるための手順について説明します。In particular, this related article will discuss how to measure framerate in your Unity Windows Mixed Reality app as well as steps to take in the Unity environment to improve performance.

パフォーマンスのボトルネックについてUnderstanding performance bottlenecks

アプリの不採算事業フレームレートがある場合、最初の手順は、アプリケーションが計算を集中的に使用している場所を分析して理解することです。If your app has an underperforming framerate, the first step is to analyze and understand where your application is computationally intensive. シーンをレンダリングする作業には、CPU と GPU の2つの主要なプロセッサがあります。There are two primary processors responsible for the work to render your scene: the CPU and the GPU. これらの2つのコンポーネントは、混在する現実のアプリのさまざまな操作とステージを処理します。Each of these two components handle different operations and stages of your Mixed Reality app. ボトルネックが発生する可能性がある主な場所は3つあります。There are three key places where bottlenecks may occur.

  1. アプリスレッド-CPU -このスレッドは、アプリロジックを担います。App Thread - CPU - This thread is responsible for your app logic. これには、入力、アニメーション、物理、およびその他のアプリのロジック/状態の処理が含まれます。This includes processing input, animations, physics, and other app logic/state
  2. スレッドを gpu にレンダリングする-このスレッドは、gpu への描画呼び出しを送信します。Render Thread - CPU to GPU - This thread is responsible for submitting your draw calls to the GPU. アプリでキューブやモデルなどのオブジェクトをレンダリングする場合、このスレッドは GPU に要求を送信します。 GPU には、レンダリングのために最適化されたアーキテクチャがあり、これらの操作を実行します。When your app wants to render an object such as a cube or model, this thread sends a request to the GPU, which has an architecture optimized for rendering, to perform these operations.
  3. GPU- このプロセッサは、一般に、3d データ (モデル、テクスチャなど) をピクセルに変換し、最終的にデバイスの画面に送信する2d イメージを生成するために、アプリケーションのグラフィックスパイプラインを処理します。GPU - This processor most commonly handles the graphics pipeline of your application to transform 3D data (models, textures, etc) into pixels and ultimately produce a 2D image to submit to your device's screen.

フレームの有効期間

一般に、HoloLens アプリケーションは GPU で制限されます。Generally, HoloLens applications will be GPU bounded. ただし、この方法はすべてのアプリケーションに当てはまるわけではありません。そのため、以下のツール & の手法を使用して、特定のアプリの基本を理解することをお勧めします。However, this does not hold true in every application and thus it is recommended to use the tools & techniques below to get to ground-truth for your particular app.

アプリケーションを分析する方法How to analyze your application

開発者が混合現実アプリケーションのパフォーマンスプロファイルを理解できるツールは多数あります。There are many tools that allow you as a developer to understand the performance profile of your Mixed Reality application. これらを使用すると、ボトルネックがある場所と、それらをデバッグするために自身を manifesting する方法の両方をターゲットにすることができます。These will enable you to both target where you have bottlenecks and how they are manifesting themselves to debug them.

これは、アプリケーションの詳細なプロファイル情報を取得するための一般的で強力なツールの一覧です。This is a list of popular and powerful tools to gain deep profiling information for your application.

任意の環境でプロファイリングする方法How to profile in any environment

アプリケーションで GPU が制限されているか、CPU が制限されている可能性があるかどうかをすばやく判断するための簡単なテストがあります。There is a simple test to quickly determine if you are likely GPU bounded or CPU bounded in your application. レンダーターゲットの出力の解像度を下げると、計算するピクセル数が少なくなるため、イメージをレンダリングするために GPU で実行する必要がある作業が少なくなります。If you decrease the resolution of the render target output, there are less pixels to calculate and thus, less work the GPU needs to perform to render an image. ビューポートのスケーリング (動的な解決のスケーリング) は、イメージを小さいレンダーターゲットにレンダリングする場合に、出力デバイスで表示できるようにするための方法です。Viewport scaling (dynamic resolution scaling) is the practice of rendering your image to a smaller render target then your output device can display. デバイスは、小さいピクセルセットから、最終的なイメージを表示するためにアップサンプリングされます。The device will up-sample from the smaller set of pixels to display your final image.

レンダリングの解像度を下げると、次のようになります。After decreasing rendering resolution, if:

  1. アプリケーションのフレームレートが増加し、 GPU が制限されている可能性があります。Application framerate increases, then you are likely GPU Bounded
  2. アプリケーションのフレームレートが変更されていないため、 CPU が制限される可能性がありますApplication framerate unchanged, then you are likely CPU Bounded

注意

Unity では、 XRSettings プロパティを使用して、実行時にアプリケーションのレンダーターゲットの解像度を簡単に変更することができます。Unity provides the ability to easily modify the render target resolution of your application at runtime through the XRSettings.renderViewportScale property. デバイスに表示される最終的なイメージには、固定された解決策があります。The final image presented on device has a fixed resolution. このプラットフォームでは、解像度の低い出力をサンプリングして、ディスプレイに表示する解像度の高いイメージを構築します。The platform will sample the lower resolution output to build a higher resolution image for rendering on displays.

UnityEngine.XR.XRSettings.renderScale = 0.7f;

アプリケーションを改善する方法How to improve your application

CPU パフォーマンスに関する推奨事項CPU performance recommendations

一般に、CPU 上の mixed reality アプリケーションでほとんどの作業を行うには、シーンの "シミュレーション" を実行し、広範な一意のアプリケーションロジックを処理する必要があります。Generally, most work in a mixed reality application on the CPU involves performing the "simulation" of the scene and processing extensive unique application logic. したがって、通常、次の領域は最適化の対象となります。Thus, the following areas are usually targeted for optimization.

  • アニメーションAnimations
  • 物理の単純化Simplify Physics
  • メモリの割り当てMemory allocations
  • 複雑なアルゴリズム (Complex algorithms (i.e 逆のキネマティック、パスの検索)inverse kinematics, path-finding)

GPU のパフォーマンスに関する推奨事項GPU performance recommendations

帯域幅と塗りつぶしレートを理解するUnderstanding bandwidth vs fill rate

GPU でフレームをレンダリングする場合、通常、アプリケーションはメモリ帯域幅またはフィルレートによって制限されます。When rendering a frame on the GPU, an application is generally either bounded by memory bandwidth or fill rate.

  • メモリ帯域幅は、GPU がメモリから実行できる読み取りと書き込みの比率です。Memory bandwidth is the rate of reads and writes the GPU can perform from memory
    • 帯域幅の制限を特定するには、テクスチャの品質を下げ、フレームレートが向上したかどうかを確認します。To identify bandwidth limitations, reduce texture quality and check if framerate improved.
    • Unity では、[プロジェクト設定 > の 品質設定編集 > ] で [テクスチャの品質] を変更することによってこれを行うことができます。In Unity, this can be done by changing Texture Quality in Edit > Project Settings > Quality Settings.
  • Fill rateは、GPU によって1秒あたりに描画できる描画ピクセルのスループットを表します。Fill rate refers to the throughput of rendered pixels that can be drawn per second by the GPU.
    • フィルレートの制限を特定するには、ディスプレイの解像度を下げ、フレームレートが改善されたかどうかを確認します。To identify fill rate limitations, decrease the display resolution and check if framerate improved.
    • Unity では、XRSettings プロパティを使用してこれを行うことができ ます。In Unity, this can be done via the XRSettings.renderViewportScale property

通常、メモリ帯域幅には最適化が必要です。Memory bandwidth generally involves optimizations to either

  1. テクスチャ解像度を下げるdecrease texture resolutions
  2. 使用するテクスチャを減らす (つまり、utilize less textures (i.e 法線、スペキュラなど)normals, specular, etc)

Fill rate は、描画された最終的なピクセルに対して計算する必要がある操作の数を減らすことに主に焦点を合わせています。Fill rate is primarily focused on reducing the number of operations that need to be computed for a final rendered pixel. 一般的に、この例は減少します。Examples of this commonly fall into reducing

  1. 表示/処理するオブジェクトの数number of objects to render/process
  2. シェーダーあたりの操作数number of operations per shader
  3. 最終的な結果に対する GPU ステージの数 (ジオメトリシェーダー、処理後の効果など)number of GPU stages to final result (geometry shaders, post-processing effects, etc)
  4. レンダリングするピクセル数 (つまり、number of pixels to render (i.e 表示解像度)display resolution)

Poly 数を減らすReduce poly count

多角形の数が多いほど、GPU に対する操作が増加し、シーン内のポリゴンの数が減少するため、そのジオメトリをレンダリングする時間が短縮されます。Higher polygon counts result in more operations for the GPU and reducing the number of polygons in your scene will reduce the amount of time to render that geometry. それ以外にも、負荷が高くなる可能性があるジオメトリの網掛けに関連する要因がありますが、ポリゴンの数は、シーンのレンダリングにかかるコストを決定する基本メトリックです。There are other factors involved as well in shading the geometry that can still be expensive but polygon count is the base metric to determine how expensive a scene will be to render.

オーバードローを制限するLimit overdraw

大きなオーバードローは、複数のオブジェクトがレンダリングされるときに発生しますが、画面には出力されません。これは、通常より近くにある別の occluding オブジェクトによって隠されているためです。High overdraw occurs when multiple objects are rendered but not outputted to the screen as they are hidden by another, generally closer, occluding object. 複数の部屋とジオメトリの背後にある壁を見てみてください。Imagine looking at a wall that had multiple rooms and geometry behind it. すべてのジオメトリはレンダリング用に処理されますが、他のすべてのコンテンツのビューを occludes するときは、不透明なウォールだけをレンダリングする必要があります。All of the geometry would be processed for rendering but only the opaque wall really needs to be rendered as it occludes the view of all other content. その結果、現在のビューでは不要な無駄な操作が発生します。This results in wasteful operations that are not needed for the current view.

シェーダーShaders

シェーダーは、GPU 上で実行される小さなプログラムであり、一般にレンダリングの2つの重要な手順を決定します。Shaders are small programs that run on the GPU and generally determine two important steps in rendering:

  1. 画面上に描画するオブジェクトの頂点と、その頂点が画面空間 (which object's vertices should be drawn on the screen and where they are in screen space (i.e 頂点シェーダー)the Vertex shader)
    • 頂点シェーダーは、一般に、各オブジェクトの頂点ごとに実行されます。The Vertex shader is generally executed per vertex for every GameObject
  2. これらのピクセルに色を設定する (つまり、what to color those pixels (i.e ピクセルシェーダー)the Pixel shader)
    • ピクセルシェーダーは、デバイスに表示されているテクスチャのピクセルごとに実行されます。The Pixel shader is executed per pixel for the texture being rendered for device present

通常、シェーダーでは、多くの変換と照明計算が実行されます。Typically shaders perform many transformations and lighting calculations. 複雑な照明モデル、影、およびその他の操作によって、優れた結果が得られる場合もありますが、価格もあります。Although complex lighting models, shadows, and other operations can generate fantastic results, they also come with a price. シェーダーで計算される操作の数を減らすと、フレームあたりの GPU によって実行される作業全体が大幅に減少します。Reducing the number of operations computed in shaders can greatly reduce the overall work needed to be done by a GPU per frame.

シェーダーのコーディングに関する推奨事項Shader coding recommendations
  • 可能な限り、バイリニアフィルタリングを使用するUse bilinear filtering whenever possible
  • 同時に乗算と加算を行うために、MAD 組み込みを使用するように式を再配置します。Rearrange expressions to use MAD intrinsics in order to do a multiply and an add at the same time
  • CPU で可能な限り Precalculate し、素材に定数として渡します。Precalculate as much as possible on the CPU and pass as constants to the material
  • ピクセルシェーダーから頂点シェーダーへの移動操作を優先するFavor moving operations from the pixel shader to the vertex shader
    • 一般に、頂点の数 < < ピクセル数 (つまり、Generally the # of vertices << # of pixels (i.e 720p = = 921600 ピクセル、1080p = = 2073600 ピクセルなど)720p == 921,600 pixels, 1080p == 2,073,600 pixels, etc)

GPU ステージの削除Remove GPU stages

処理後の影響には非常にコストがかかり、一般にアプリケーションのフィルレートが妨げられる可能性があります。Post-processing effects can be very expensive and generally inhibit the fill rate of your application. これには、MSAA などのアンチエイリアシング手法も含まれます。This also includes anti-aliasing techniques such as MSAA. HoloLens では、これらの手法を完全に回避することをお勧めします。On HoloLens, it is recommended to avoid these techniques entirely. さらに、可能な場合は、geometry、ハル、compute シェーダーなどの追加のシェーダーのステージを避ける必要があります。Furthermore, additional shader stages such as geometry, hull, and compute shaders should be avoided when possible.

メモリに関する推奨事項Memory recommendations

過剰なメモリ割り当て & 解放操作によって holographic アプリケーションに悪影響を及ぼす可能性があるため、パフォーマンスが低下したり、フレームが固定されたり、その他の有害な動作が発生したりする可能性があります。Excessive memory allocation & deallocation operations can have adverse effects on your holographic application resulting in inconsistent performance, frozen frames, and other detrimental behavior. メモリ管理はガベージコレクターによって制御されるため、Unity で開発するときは、メモリに関する考慮事項を理解することが特に重要です。It is especially important to understand memory considerations when developing in Unity since memory management is controlled by the garbage collector.

オブジェクトプールObject pooling

オブジェクトプールは、オブジェクトの割り当て解除 & の継続的な割り当てのコストを削減するための一般的な手法です。Object pooling is a popular technique to reduce the cost of continuous allocations & deallocations of objects. これを行うには、同一のオブジェクトの大規模なプールを割り当て、時間の経過と共にオブジェクトを絶えず破棄するのではなく、このプールから使用可能な非アクティブなインスタンスを再利用します。This is done by allocating a large pool of identical objects and re-using inactive, available instances from this pool instead of constantly spawning and destroying objects over time. オブジェクトプールは、アプリの有効期間が可変の再使用可能なコンポーネントに最適です。Object pools are great for re-useable components that have variable lifetime during an app.

関連項目See also