テストとパフォーマンス分析

• メディアアプリは60FPSを目標にするとよいでしょう。
• インタラクティブアプリでは、最低でも72FPSを達成しなければなりません。

• パイプライン状態の変化: これには、シェーダー、テクスチャ、メッシュ、そのようなドロー間の変化が含まれます。
  • メッシュとインスタンスメッシュを可能な限り共有する。
  • 可能ならグローバルテクスチャー配列を使う。
  • バリエーションを生成しない、統合されたシェーダーの最少のセットを使う。
• メインスレッドとレンダースレッドの容量: レンダースレッドと、レンダースレッドにデータを準備および供給するメインスレッドで利用可能なリソースを検討します。
  • アニメーション、スキンニング、ネットワークなどのプロセスは、レンダースレッドの開始を遅らせ、ターゲットFPS内で実行可能なドローコールの数を減らします。
• グラフィックAPIと使い方
  • VulkanとOpenGL ESの比較。
  • マルチスレッドレンダリング - 低遅延 vs.フレームビハインド。
  • バインドレステクスチャーと間接ドローの使用状況。

• 重いシミュレーション: ほかのプレイヤーまたは多数のNPCからのシミュレーション、VoIP、ネットワーク、アニメーション、スキニングが大量にあるアプリ。例えば、マルチプレイヤーのシューターや利用者の多いソーシャルアプリなどです。
• 中程度のシミュレーション: プレイヤーまたはNPCの数が少ない、サイズが中程度のワールド。例えば、単一プレイヤーのシューターや利用者数が中程度のソーシャルゲームなどです。ほとんどのアプリはこのカテゴリに入ります。
• 軽いシミュレーション: エスケープルームゲーム、パズルゲーム、協力型ゲームといったパイプライン状態の変化が最小限のアプリです。

• 複数のタイルに広がる三角形: これらはコストが高くなります。
  • 三角形の頂点シェーダーは、その範囲内のタイルごとに3回(頂点ごとに1回)実行されます。
  • 三角形が大きくなるほど範囲内のタイル数が多くなりますが、タイルの境界線を予測するのは困難です。
• 頂点属性のメモリーアクセスパターン: これらは、頂点シェーダーの速度に影響します。
  • 位置データ、スキンニングの重さ、アウトプット位置を計算するために必要なその他のデータ専用の頂点属性配列を割り当てます。ほかのものは、別々のインターリーブ頂点属性配列に配置します。この設定により、出力位置に影響する属性だけが考慮されるので、ビニングフェーズのスピードが上がります。
• 頂点属性: 頂点シェーダーに送信する頂点属性の数と精度に注目します。
  • パフォーマンスを向上させるためには、NORMAL、TANGENT、TEXCOORD*などの使われていないチャネルを削除するか、可能であればチャネルを組み合わせます。
  • 通常、フルの精度を必要とするのは、POSITIONチャネルだけです。ほかのチャネルを半精度まで圧縮し、ビジュアルクオリティを維持できるかどうか試してみてください。

• Rift Sで80 FPS、Riftで90 FPS
• フレームあたり500〜1,000回のドローコール
• 毎フレーム1〜2百万個の三角形または頂点

• フレームバッファビューアーは、データがリアルタイムで受信される際に、フレームバッファを検査するメカニズムを提供します。これは、プレイテストセッションをモニターするときに特に役立ちます。有効にすると、キャプチャライブラリが、ネットワーク全体に縮小されたプレディストーションアイバッファをストリーミングします。
• パフォーマンスデータビューアーは、以下の項目に対して、単一の連続したタイムラインによるリアルタイムのオフライン点検を行います。
  • CPU/GPUイベント
  • センサー測定値
  • コンソールメッセージ、警告、エラー
  • フレームバッファキャプチャ
• ロギングビューアーは、スレッドIDによってトラッキングされているさまざまなメッセージやエラーの未加工データへのアクセスを提供します。
• コード内のほぼすべての定数は、プレイテスト中にリアルタイムでアップデートできるノブとして使うこともできます。