GPUにラスタライザーがまだあるのはなぜですか?


14

進歩にもかかわらず、最新のGPUはまだラスタライザーを修正しています。プログラム可能なシェーダーで高度にカスタマイズ可能ですが、完全にプログラム可能ではありません。

何故ですか?

GPUが、ラスタライザーがユーザーが提供するデバイス用の単なるソフトウェアであるユニバーサルコンピューティングユニットを備えた単純な超並列デバイスになれないのはなぜですか?

固定機能のハードウェアはパフォーマンス面で非常に有益であり、そのようなアプローチは実行不可能ですか?


1
「グラフィック処理装置がユニバーサル処理装置ではないのはなぜですか」、あなたは疑問に思っていますか?
アンドレアス

1
@Andreasいいえ、私の質問は投稿に記載されているとおりです。ラスタライザーがソフトウェアで実行できるのに、ハードウェアの一部であるのはなぜですか(実際、既にOpenCLまたはコンピューティングシェーダーで実行できます)。質問が一般的ではない理由です...多分それは単にパフォーマンスである、私は知らない、それが私が尋ねている理由です
...-mrpyo

ラスタライズをバイパスして、最新のGPUの計算ユニットを使用して独自のラスタライザを実装できます。実際、特定の目的でこれを行う人々を知っています。
JarkkoL

ラスタライザーは、ベクターポリゴンを、照明できるピクセルの束に変換します。ピクセルがなくなった場合、またはベクタージオメトリの使用を停止した場合、ラスタライザーは不要になります。パイプラインの残りの部分がどのようなものであっても、1日の終わり(またはフレーム)にはピクセルが必要です。ラスタライザは、指定された三角形についてどのピクセルを懸念しているかを通知するだけです。これらはすべてプログラム可能です-ラスタライザーから異なる出力が必要な場合は、異なる三角形をその方法で送信します。または、すべてをコンピューティングシェーダーのレンダリングテクスチャに描画し、ビューに揃えられたクワッドで画面にブリットします。
3Dave

回答:


15

要するに、パフォーマンス上の理由がプログラムできない理由です。

歴史と市場

過去には、FPUデザインの肥大化を避けるために、頂点プロセッサとフラグメントプロセッサに別々のコアが使用されていました。たとえば、フラグメントシェーダーコードでしか実行できない数学的操作がいくつかありました(ほとんどがフラグメントシェーダーにのみ関連するため)。これにより、各タイプのコアの可能性を最大限に活用できなかったアプリケーションのハードウェアのボトルネックが深刻になります。

プログラマブルシェーダーの人気が高まるにつれて、ユニバーサルユニットが導入されました。グラフィックスパイプラインの段階がハードウェアに実装され、スケーリングを支援しました。この間、GPGPUも人気が高まったため、ベンダーはこの機能の一部を組み込む必要がありました。ただし、GPUからの収入の大部分は依然としてビデオゲームであるため、これがパフォーマンスを妨げることはないことに注意することが重要です。

結局、Intelの大企業は、Larrabeeアーキテクチャを備えたプログラマブルラスタライザに投資することを決定しました。このプロジェクトは画期的なものと想定されていましたが、パフォーマンスは明らかに期待しものよりも低かったようです。シャットダウンされ、その一部がXeon Phiプロセッサ用に回収されました。ただし、他のベンダーがこれを実装していないことは注目に値します。

ソフトウェアラスタライザーの試み

ソフトウェアを使用したラスタライズの試みはいくつかありましたが、すべてパフォーマンスに問題があるようです。

一つの注目すべき努力はしたのNvidiaの試み本で2011年に論文。これは、Larrabeeが終了したときにリリースされたため、これに対する応答であった可能性が非常に高いです。とにかく、これにはいくつかのパフォーマンス値があり、それらのほとんどはハードウェアラスタライザよりも数倍遅いパフォーマンスを示しています。

ソフトウェアラスタライズの技術的な問題

Nvidiaの論文で直面した多くの問題があります。ただし、ソフトウェアラスタライザに関する最も重要な問題の一部を次に示します。

主要課題

  • 補間: ハードウェア実装は、特殊なハードウェアで補間方程式を生成します。これは、フラグメントシェーダーで実行する必要があるため、ソフトウェアレンダラーでは低速です。

  • アンチエイリアス: アンチエイリアス(特にメモリ)のパフォーマンスの問題もありました。サブピクセルサンプルに関する情報はオンチップメモリ​​に保存する必要がありますが、これを保持するには不十分です。Julien Guertaultさんは、ソフトウェアではテクスチャキャッシュ/キャッシュが遅くなる可能性があると指摘しました。MSAAは、キャッシュ(非テクスチャキャッシュ)をオーバーフローさせ、チップ​​からメモリに移動するため、確かにここに問題があります。ラスタライザは、そのメモリに格納されているデータを圧縮します。これは、ここでのパフォーマンスにも役立ちます。

  • 消費電力: サイモンFは、消費電力が少なくなると指摘しました。論文では、カスタムALUがラスタライザーにある(電力消費を削減する)ことに言及していました。これは、過去のフラグメントおよび頂点処理ユニットがカスタム命令セット(カスタムALUも同様)を使用していたためです。これは確かに多くのシステム(モバイルなど)のボトルネックになりますが、これはパフォーマンス以外にも影響を及ぼします。

概要

TL; DR:ソフトウェアレンダリングでは過去にできない非効率性が多すぎるため、これらの要素が加算されます。また、VRAM帯域幅、同期の問題、余分な計算を扱う場合は特に、多くの大きな制限があります。


ボックスフィルトレーションが十分であれば、サブピクセルサンプルを保存する必要があるとは思わない。
-joojaa

2
テクスチャサンプリングとキャッシュは、おそらくハードウェア実装ではソフトウェア実装では達成できないパフォーマンスを可能にする領域でもあると思われます。
ジュリアンゲルトー

3
@aces言及する価値のあるもう1つの項目はパワーです。専用ハードウェアは、通常、わずかな電力バジェットで同じ仕事をします。特にモバイルデバイスでは、電力調整がすでに問題であるため、完全にプログラム可能にすると、さらに悪化します。
サイモンF

@JulienGuertault公正なポイントですが、これはほとんどMSAAに適用できると思います。テスト結果は、すべてがオンチップメモリ​​に収まる場合、これは大きな問題ではないことを示しているようです(ただし、これはパフォーマンスに何らかの影響を与える可能性があります)。
エース

@SimonFそれも素晴らしい点だと思います。答えに含めました。
エース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.