ニンテンドーDSコンソールGPUと興味深い機能

ニンテンドーDS GPUコンソールの操作、最新のGPUとの違いについて説明し、エミュレーターでOpenGLの代わりにVulkanを使用しても利点が得られない理由についても意見を述べたいと思います。



Vulkanのことはあまり知りませんが、読んだことから、VulkanはOpenGLとは異なり、低レベルで動作し、プログラマーがGPUメモリなどを管理できるという点で明らかです。 これは、OpenGLでは利用できない制御レベルを提供する独自のグラフィカルAPIを使用する、より新しいコンソールをエミュレートするのに役立ちます。



たとえば、blargSNESハードウェアレンダラー-その秘oneの1つは、異なるカラーバッファーでの操作中に、1つの深度/ステンシルバッファーが使用されることです。 OpenGLでは、これは不可能です。



さらに、アプリケーションとGPUの間に残るガーベッジが少なくなります。つまり、正しく実装されれば、パフォーマンスが向上します。 OpenGLドライバーは、標準的なユースケースや特定のゲーム向けに最適化されていますが、Vulkanでは、まずアプリケーション自体を適切に作成する必要があります。



つまり、本質的に「大きな責任には大きな力が伴います」。



私は3D APIの専門家ではないので、その話に戻りましょう。 私がよく知っていること：GPUコンソールDS。



個々のパーツ（ 洗練されたクワッド 、 ビューポートでのナンセンス 、ラスタライザーの面白い機能、 アンチエイリアスの驚くべき実装について）についていくつかの記事が既に書かれていますが、この記事では、デバイス全体を、しかしすべてのジューシーな詳細について検討します。 少なくとも私たちが知っていることはそれだけです。



GPU自体はかなり古くて時代遅れのハードウェアです。 フレームあたり2048ポリゴンおよび/または6144頂点に制限されています。 解像度は256x192です。 これを4倍にしても、パフォーマンスは問題になりません。 最適な条件下では、DSは1秒あたり最大122880ポリゴンを出力できます。これは、最新のGPUの標準ではとんでもないです。



では、GPUの詳細に移りましょう。 表面的にはかなり標準的なように見えますが、その動作の奥深くは最新のGPUの動作とは非常に異なり、一部の機能をエミュレートすることがより困難になっています。



GPUは、ジオメトリエンジンとレンダリングエンジンの2つの部分に分かれています。 ジオメトリエンジンは、結果の頂点を処理し、ポリゴンを構築して変換し、レンダリングエンジンに渡すことができるようにします。レンダリングエンジンは（推測したとおり）すべてを画面に描画します。

ジオメトリエンジン

かなり標準的な幾何学的コンベヤー。



DSは浮動小数点数をサポートしていないため、すべての演算は固定小数点整数で実行されることに注意してください。



ジオメトリエンジンは完全にプログラムでエミュレートされます（GPU3D.cpp）。つまり、グラフィックスのレンダリングに使用するものにはあまり適用されませんが、とにかくそれについて詳しく説明します。



1.変換と照明。 結果の頂点とテクスチャ座標は、4x4マトリックスのセットを使用して変換されます。 頂点の色に加えて、照明が適用されます。 ここではすべてが非常に標準的です。唯一の非標準は、テクスチャ座標の仕組みです（1.0 =テクセルDS 1つ）。 マトリックススタックのシステム全体についても言及する価値があります。これは、ある程度、glPushMatrix（）のハードウェア実装です。



2.ポリゴンの構成。 変換された頂点は、三角形、四角形（四角形）、三角形のストライプ、または四角形のストライプであるポリゴンに組み立てられます。 クワッドはネイティブに処理され、三角形に変換されません。これは、最新のGPUが三角形のみをサポートするため、かなり問題です。 しかし、誰かが私がテストする必要のあるソリューションを思いついたようです。



3.ドロップ。 画面上の向きと選択したカリングモードに応じて、ポリゴンを破棄できます。 また、かなり標準的なスキーム。 ただし、これがクワッドでどのように機能するかを理解する必要があります。



4.切り捨て。 可視範囲を超えるポリゴンは排除されます。 この領域を超えて部分的に延びるポリゴンは切り捨てられます。 この手順では、新しいポリゴンは作成されませんが、既存のポリゴンに頂点が追加されます。 実際、6つの切り捨て面のそれぞれがポリゴンに1つの頂点を追加できます。つまり、結果として最大10の頂点を取得できます。 レンダリングエンジンのセクションで、これをどのように処理したかを説明します。



5.ビューポートに変換します。 X / Y座標は画面座標に変換されます。 Z座標は、24ビットの深度バッファー間隔に収まるように変換されます。



おもしろいのは、W座標がどのように処理されるかということです。それらは16ビット間隔に収まるように「正規化」されます。 このために、ポリゴンの各W座標が取得され、0xFFFFより大きい場合は、16ビットに収まるように4ポジション右にシフトされます。 逆に、座標が0x1000未満の場合は、間隔に入るまで左に移動します。 良い間隔を得るためにはこれが必要だと思います。つまり、補間中の精度が高くなります。



6.ソート。 ポリゴンは、半透明のポリゴンが最初に描画されるようにソートされます。 次に、Y座標（ええ）で並べ替えられます。これは、不透明でオプションの半透明ポリゴンに必要です。



さらに、これが2048ポリゴンの制限の理由です。並べ替えには、どこかに格納する必要があります。 ポリゴンと頂点の保存専用の2つの内部メモリバンクがあります。 格納されているポリゴンと頂点の数を報告するレジスタもあります。

レンダリングエンジン

そして、ここから楽しみが始まります！



すべてのポリゴンの構成と並べ替えが完了すると、レンダリングエンジンが動作を開始します。



最初の面白い瞬間は、ポリゴンをどのように埋めるかです。 これは、タイルの塗りつぶしを実行し、三角形に最適化されたアルゴリズムを使用する最新のGPUの動作とはまったく異なります。 それらがすべてどのように機能するかはわかりませんが、3DSコンソールGPUでこれがどのように行われるかを見ました。すべてがタイルに基づいています。



DSでは、レンダリングはラスター文字列で行われます。 開発者は、ラスターラインに描画を実行する旧式の2次元タイルエンジンと並行してレンダリングを実行できるように、これを行う必要がありました。 いくつかのラスタラインを調整するために使用できる48のラスタラインを持つ小さなバッファがあります。



ラスタライザは、ラスタ文字列に基づいた凸多角形のレンダラーです。 任意の数の頂点を処理できます。 凸でない、または交差するエッジを持つポリゴンを渡すと、正しくレンダリングされない場合があります。例：









ポリゴンは蝶です。 すべてが正しく壮大です。



しかし、それを好転させるとどうなりますか？









痛い。



ここの間違いは何ですか？ 元のポリゴンのアウトラインを描画して理解しましょう。









レンダラーは、ラスタラインごとに1つのギャップのみを埋めることができます。 最も高いピークで始まる左と右のエッジを定義し、新しいピークに遭遇するまでこれらのエッジをたどります。



上記の画像では、最上部の頂点、つまり左上から始まり、左端（左下の頂点）の終わりに達するまで塗り続けます。 彼はrib骨が交差することを知りません。



この時点で、彼は左端の次の頂点を検索します。 彼が現在の頂点よりも高い頂点を取得する必要がないことを知っており、また左と右のエッジが入れ替わっていることを知っていることに注意するのは興味深いことです。 したがって、埋め立てが終わるまで埋め続けられます。



非凸多角形の例をもう少し追加しますが、トピックから離れすぎます。



グーローシェーディングとテクスチャリングが任意の数の頂点でどのように機能するかをよく理解しましょう。 三角形に沿ってデータを補間するために使用される重心アルゴリズムがありますが、...私たちの場合、それらは適切ではありません。



ここのDSレンダラーにも独自の実装があります。 いくつかの興味深い画像。









多角形の頂点はポイント1、2、3、および4です。数字は実際の走査順序に対応していませんが、意味は理解しています。



現在のラスターラインでは、レンダラーはエッジを直接囲む頂点を定義します（上記のように、最上部の頂点から始まり、完全になるまでエッジを通過します）。 この場合、これらは左端の頂点1と2、右端の頂点3と4です。



エッジの勾配は、ギャップの制限、つまりポイント5および6を決定するために使用されます。これらのポイントでは、頂点の属性は、エッジの垂直位置（または、主にX軸に沿ったエッジの水平位置）に基づいて補間されます。



次に、ギャップ内の各ピクセル（ポイント7など）について、ギャップ内のX位置に基づく属性が、ポイント5および6で以前に計算された属性から補間されます。



ここでは、作業を簡素化するために使用されるすべての係数が50％に等しくなっていますが、意味は明確です。



また、属性補間の詳細については説明しませんが、これについて書くことは興味深いでしょう。 実際、これは視点の観点からは正しい補間ですが、興味深い単純化と機能があります。



次に、DSがポリゴンを塗りつぶす方法について説明します。



彼はどの充填ルールを使用していますか？ ここには多くの興味深いものもあります！



まず、不透明ポリゴンと半透明ポリゴンには異なる塗りつぶしルールがあります。 しかし、最も重要なのは、これらのルールがピクセルごとに適用されることです。 半透明ポリゴンには不透明ピクセルを含めることができ、不透明ポリゴンと同じルールに従います。 最新のGPUでこのようなトリックをエミュレートするには、いくつかのレンダリングパスが必要であると推測できます。



さらに、さまざまなポリゴン属性がさまざまな興味深い方法でレンダリングに影響を与える可能性があります。 レンダラーには、かなり標準的な色および深度バッファーに加えて、あらゆる種類の興味深いものを追跡する属性バッファーもあります 。 すなわち：ポリゴンID（不透明ポリゴンと半透明ポリゴンの場合は個別）、ピクセルの半透明性、フォグを適用する必要性、このポリゴンがカメラに向けられているかカメラから向けられているか（はい、これも）、ピクセルがポリゴンの端にあるかどうか。 そして多分何か。



このようなシステムをエミュレートするタスクは簡単ではありません。 通常の最新のGPUには、8ビットに制限されたステンシルバッファーがあります。これは、属性バッファーを格納できるすべてのものには十分ではありません。 トリッキーな回避策を考え出す必要があります。



それを理解しましょう：



*深度バッファの更新：不透明ピクセルには必須、半透明ピクセルにはオプション。



*ポリゴンID：6ビットIDはポリゴンに割り当てられ、いくつかの目的に使用できます。 不透明なポリゴンIDは、エッジをマークするために使用されます。 半透明ポリゴンのIDは、それらが描画される場所を制御するために使用できます。ポリゴンIDが属性バッファに既にある半透明ポリゴンのIDと一致する場合、半透明ピクセルは描画されません。 また、両方のポリゴンIDは、シャドウレンダリングを制御するために同様に使用されます。 たとえば、キャラクターではなく床を覆う影を作成できます。



（注：シャドウはステンシルバッファの単なる実装であり、ここにはひどいものはありません。）



半透明のピクセルをレンダリングする場合、不透明なポリゴンの既存のIDと最後の不透明なポリゴンのエッジのエッジが保存されることに注意してください。



*フォグフラグ：このピクセルにフォグパスを適用するかどうかを決定します。 更新プロセスは、入力ピクセルが不透明か半透明かによって異なります。



*最前線の旗：ここに問題があります。 スクリーンショットを見てください：









Sands of Destruction、このゲームの画面はトリックのセットです。 Yソートに影響するようにY座標を変更するだけではありません。 このスクリーンショットに示されている画面は、おそらく最悪です。



深さテストの境界ケースを使用します 。ゲームがカメラから離れた方向のポリゴンの不透明ピクセルの上にカメラを見てポリゴンを描画する場合、比較関数「より小さい」 は等しい値を取り ます 。 はい、正確に。 そして、すべてのポリゴンのZ値はゼロです。 この機能をエミュレートしないと、画面上の一部の要素が失われます。



これは、Z値が同じであるほど平坦な場合でも、オブジェクトの前面が常に背面に見えるように行われたと思います。 これらすべてのハックとトリックにより、DSレンダラーはDOS時代のレンダラーのハードウェアバージョンに似ています。



ただし、GPUを介してこの動作をエミュレートするのは困難でした。 ただし、深度テストには他にも同様の境界ケースがあり、テストと文書化が必要です。



*リブフラグ：レンダラーはポリゴンのエッジの位置を追跡します。 これらは、最後のパス、つまりエッジにマークを付けてアンチエイリアスをかけるときに使用されます。 アンチエイリアスを無効にして不透明なポリゴンを塗りつぶすための特別なルールもあります。 次の図は、これらのルールを示しています。









注：ワイヤフレームは、エッジのみを埋めることによってレンダリングされます！ 非常にスマートな動き。



深度バッファリングに関する別の楽しいメモ：



DSには、ZバッファリングとWバッファリングの2つの深度バッファリングモードがあります。 それはかなり標準的なようですが、詳細に入らない場合のみです。



* Zバッファリングは、24ビットの深度バッファ間隔に収まるように変換されたZ座標を使用します。 Z座標は、ポリゴン上で線形補間されます（奇妙な点もありますが、特に重要ではありません）。 ここにも非標準のものはありません。



* Wバッファリングでは、W座標が「そのまま」使用されます。 最近のGPUは通常1 / Wを使用しますが、DSは固定小数点演算のみを使用するため、逆数値の使用はあまり便利ではありません。 このモードでは、W座標は遠近補正で補間されます。



最終的なレンダリングパスは次のようになります。



*エッジのマーキング：エッジフラグが設定されているピクセルには、テーブルから取得した色が割り当てられ、不透明なポリゴンのIDに基づいて決定されます。



ポリゴンの色付きのエッジになります。 半透明のポリゴンが不透明なポリゴンの上に描画される場合、ポリゴンのエッジはまだ色付けされていることに注意してください。



切り捨ての原理の副作用：ポリゴンが画面の境界と交差する境界も色付けされます。 たとえば、Picross 3Dのスクリーンショットでこれに気付くことができます。



*フォグ：フォグ密度テーブルのインデックスに使用される深度値に基づいて各ピクセルに適用されます。 ご想像のとおり、属性バッファにフォグフラグが設定されているピクセルに適用されます。



*アンチエイリアス（平滑化）：（不透明な）ポリゴンのエッジに適用されます。 ポリゴンをレンダリングするときのエッジの傾斜に基づいて、ピクセルカバレッジ値が計算されます。 最後のパスでは、これらのピクセルは、前の投稿で説明したトリッキーなメカニズムを使用して、それらの下のピクセルと混合されます。



アンチエイリアスはGPUでこのようにエミュレートすることはできません（できません）。したがって、ここではこれは重要ではありません。



エッジマーキングとアンチエイリアスを同じピクセルに適用する必要がある場合を除き、エッジの汚れのみが得られますが、不透明度は50％です。



レンダリングプロセスについては、多少なりとも説明しているようです。 テクスチャの混合（頂点カラーとテクスチャカラーの組み合わせ）については掘り下げませんでしたが、フラグメントシェーダーでエミュレートできます。 属性バッファを使用してこのシステム全体を回避する方法を見つければ、エッジマーキングとフォグにも同じことが当てはまります。



しかし、一般的に、私は次のことを伝えたかった：OpenGLまたはVulkan（およびDirect3D、またはGlide、またはその他）はここでは役に立ちません。 最新のGPUには、生のポリゴンを処理するのに十分なパワーがあります。 問題は、ラスタライズの詳細と機能です。 そして、ピクセルの理想についてすらありません。たとえば、DeSmuMEエミュレーターの問題トラッカーを見て、開発者がOpenGLを介してレンダリングするときに発生する問題を理解するだけです。 また、これらの同じ問題に何らかの方法で対処する必要があります。



また、OpenGLを使用すると、たとえばSwitchにエミュレーターを移植できることに注意してください（Hydr8gonというGithubユーザーがSwitchでエミュレーター用のポートの作成を開始したため ）。



だから...幸運を祈ります。