複合現実のパフォーマンスを理解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. 実際には、パフォーマンスは Mixed Reality 開発しないを安定化、サイクルのタスクの最後のファースト クラスの機能として見なす必要があります。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
Pc を Windows Mixed Reality UltraWindows Mixed Reality Ultra PCs 90 FPS90 FPS
Windows Pc の現実の混在Windows 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. 2 つの主なプロセッサがある、シーンを表示するために作業を担当します。 CPU と GPU します。There are two primary processors responsible for the work to render your scene: the CPU and the GPU. これら 2 つのコンポーネントのそれぞれは、さまざまな操作と、Mixed Reality アプリのステージを処理します。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 に CPU -このスレッドは、GPU の描画呼び出しの送信を担当します。Render Thread - CPU to GPU - This thread is responsible for submitting your draw calls to the 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 - このプロセッサは、3 D のデータ (モデル、テクスチャなど) をピクセルに変換し、最終的には、デバイスの画面に送信する 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. あるボトルネックとどのようにデバッグすること自体が明白は両方のターゲットにできます。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. アプリケーションのフレーム レートunchanged、可能性がありますし、 CPU の制限Application framerate unchanged, then you are likely CPU Bounded

注意

Unity は、アプリケーションを介して実行時のレンダー ターゲット解像度を簡単に変更する機能、 XRSettings.renderViewportScale プロパティ。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 上の複合現実のアプリケーションでのほとんどの作業は、シーンの「シミュレーション」を実行して、広範な一意のアプリケーション ロジックを処理する必要があります。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 帯域幅の vs のフィル レート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.
  • フィル レート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.renderViewportScale プロパティ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 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)

ポリゴンの数を削減します。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

高オーバー ドローの複数のオブジェクトがレンダリングされますが、別、一般に近い、他のオブジェクトによって隠されていると画面に出力されていないときに発生します。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. 処理されるすべてのジオメトリのレンダリングが、不透明な壁のみが本当にその他のすべてのコンテンツの表示を邪魔になりますが描画される必要があります。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)
    • すべて GameObject の頂点ごと、頂点シェーダーが一般に実行されます。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
  • 可能であれば、bilinear フィルタ リングを使用します。Use bilinear filtering whenever possible
  • MAD の組み込みを同時に、multiply メソッドと追加を実行するために使用する式を再配置します。Rearrange expressions to use MAD intrinsics in order to do a multiply and an add at the same time
  • CPU の可能な限りを事前計算し、材料に定数として渡す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 720 p 921,600 ピクセル、1080 p = = 2,073,600 ピクセルなどを = =)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、ハル、計算シェーダーなどの追加のシェーダー ステージは、可能であれば避ける必要があります。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