PVRUniScoEditor を使用してピクセル シェーダーのプロファイリングを行ったところ、フラグ シェーダーはほとんどのポリゴンで約 20 サイクル、パーティクルでは 6 ～ 8 サイクルで入ってくることがわかりました。これはまともなパフォーマンスを得るという点で私たちのバターゾーンのようですが、これらのシェーダーをできるだけシンプルにすることで他の問題を隠しているのではないかと考えています. これらの人にもう少し機能があればいいのにと思います。約 120,000 ポリゴンのシーンをレンダリングしていますが、頂点シェーダーを重くしてもパフォーマンスへの影響はほとんどまたはまったくありません。
したがって、非常に頻繁に使用されるフラグ シェーダにはどれくらい多すぎるのか、30 fps にはどれだけ多すぎるのか疑問に思っていると思います。
これに対する唯一の正解はありません。PVRUniScoEditor は、シェーダーのパフォーマンスを相対的に見積もるための優れたツールですが、X 推定サイクルを消費するフラグメント シェーダーが特定のデバイスで Y フレームレートにつながるとは言えません。
特定のシェーダーがどれほど重いかは、パズルの 1 ピースにすぎません。画面上でいくつのフラグメントがカバーされますか? パフォーマンスのボトルネックはフラグメント処理側にありますか (OpenGL ES ドライバー計測器のレンダラー使用率は 100% に近い)? ブレンディングは有効ですか？これらの要因はすべて、フレームのレンダリングにかかる時間に影響します。
iOS のタイルベースの遅延レンダラーには、興味深いパフォーマンス特性もいくつかあります。特定のフラグメント シェーダーのサイクル カウントを調整しても、フィル レートが制限されたアプリケーションであっても、レンダリング時間の直線的な変化にはつながりません。この例は、this question of mineで見ることができます。ここでは、フラグメント シェーダーのわずかなバリエーションで突然のパフォーマンスの変化に遭遇しました。その場合、シェーダーを調整することは主要な解決策ではなく、不要なフラグメントのブレンドを防ぐことでした。
プロファイラーによって報告されるストレート サイクル カウントに加えて、テクスチャ帯域幅の制限があり、キャッシュ ミスがこれらのシェーダーに与える深刻な影響があることがわかりました。
私が言おうとしているのは、アプリケーションでシェーダーのパフォーマンスがどうなるかを知る唯一の実際の方法は、シェーダーを実行して確認することです。十分に高速でないものを調整するために使用できる一般的なヒントがありますが、非常に多くの変数があるため、すべてのソリューションがアプリケーション固有になります。