むかしむかし、>が<よりも高速だったとき...待って、何？

Question

私は素晴らしいOpenGLチュートリアルを読んでいます。本当に素晴らしいです、私を信頼してください。私が現在いるトピックはZ-bufferです。著者は、GL_LESS、GL_ALWAYSなどのカスタム深度テストを実行できることを述べています。また、深度値の実際の意味（最上位であるかどうか）もできることを説明しています。カスタマイズされました。今のところわかりました。そして、著者は信じられないようなことを言います：

範囲zNearは、範囲zFarより大きくすることができます。そうである場合、ウィンドウスペースの値は、ビューアーから最も近いまたは最も遠いものに関して、逆になります。

前に、0のウィンドウスペースZ値が最も近く、1が最も遠いと言われました。ただし、クリップスペースのZ値を無効にすると、深さ1はビューに最も近く、深さ0は最も遠くなります。ただし、深度テストの方向を逆にすると（GL_LESSからGL_GREATERなど）、まったく同じ結果が得られます。だから、それは本当に単なる慣習です。 実際、Zの符号と深度テストの反転は、かつて多くのゲームにとって重要なパフォーマンス最適化でした。

パフォーマンスに関して正しく理解できれば、Zの符号を反転させて深度テストを行うことは、<比較を>比較に変更することに他なりません。したがって、私が正しく理解し、作者が嘘をついたり、物事を作り上げていない場合、<を>に変更すると、以前はa vital Optimization多くのゲーム。

著者は物事を作り上げていますか、私は何かを誤解していますか、それとも実際に<が>よりも遅い（vitally、著者が言うように）のですか？

この非常に奇妙な問題を明確にしてくれてありがとう！

_{免責事項：アルゴリズムの複雑さが最適化の主な原因であることを完全に認識しています。さらに、私は今日では間違いなく何の違いももたらさないだろうと疑っていますし、これを最適化することも求めていません。私はただ、非常に、痛々しいほど、ひどく好奇心が強いです。}

Nicol Bolas · Accepted Answer

パフォーマンスに関して正しく理解している場合、Zの符号を反転し、深度テストを行うことは、<比較を>比較に変更すること以外は何もありません。したがって、私が正しく理解し、作者が嘘をついたり、物事を作り上げていない場合、多くのゲームにとって<を>に変更することが重要な最適化でした。

それは重要ではなかったので、特にうまく説明しませんでした。ちょっとしたトリビアを追加するのは面白いと感じました。アルゴリズムについて詳しく説明するつもりはありませんでした。

ただし、コンテキストが重要です。 <比較が>比較よりも速いとは言いませんでした。覚えておいてください：私たちはあなたのCPUではなく、グラフィックスのハードウェア深度テストについて話しているのです。 operator<。

私が言っていたのは、特定の古い最適化で、1つのフレームを使用しますGL_LESS [0、0.5]の範囲。次のフレームでは、GL_GREATER [1.0、0.5]の範囲。フレームごとに文字通り「Zの符号と深度テストを反転」します。

これにより深度の精度が1ビット失われますが、深度バッファをクリアする必要はありませんでした。深度クリアは最近では無料であるだけでなく、実際にはこの手法よりも速いため、人々はもうそれをしません。

Crowley9 · Answer

答えはほぼ間違いなく、チップ+ドライバーの化身が使用された場合、Hierarchical Zは一方向にしか機能しなかったということです-これは当時のかなり一般的な問題でした。低レベルのアセンブリ/分岐はそれとは何の関係もありません-Zバッファリングは固定機能ハードウェアで行われ、パイプライン処理されます-投機はなく、したがって分岐予測はありません。

t0rakka · Answer

このような最適化は、多くの組み込みグラフィックスソリューションのパフォーマンスを低下させます。フレームバッファーの解決効率が低下するためです。バッファのクリアは、ビニング時にバッファを保存および復元する必要がないことをドライバーに知らせるクリアシグナルです。

少しの背景情報：タイル化/ビニングラスタライザーは、オンチップメモリに収まる非常に小さなタイルの数で画面を処理します。これにより、外部メモリへの書き込みと読み取りが減少し、メモリバス上のトラフィックが減少します。フレームが完了すると（スワップが呼び出されるか、FIFOがいっぱいになったため、FIFOがフラッシュされたり、フレームバッファバインディングが変更されるなど）、フレームバッファを解決する必要があります。つまり、すべてのビンが順番に処理されます。

ドライバーは、以前の内容を保存する必要があると想定する必要があります。保存とは、ビンが外部メモリに書き出され、後でビンが再度処理されるときに外部メモリから復元される必要があることを意味します。クリア操作は、ビンの内容が明確に定義されていること、つまりクリアカラーであることをドライバーに伝えます。これは最適化が簡単な状況です。バッファの内容を「破棄」する拡張機能もあります。