これまでのところ、グラフィックパイプラインのさまざまな段階を実装する非常に専門的なサーキュリーから、より一般的なアプローチへの移行があったことがわかりました。この変換は、プログラマブルシェーダーの形で3D APIに部分的に反映されています。ほとんどのトランジスタは、実際のシェーダー命令を実行する超並列SIMDユニット専用です。
正しい。基本的に、古いGPUの機能サイズが比較的大きいため、基本的な照明、アンチエイリアス、テクスチャマッピング、ジオメトリなどを効率的に実装する唯一の方法は、「固定機能」パイプラインを使用することでした。現在のGPUのような、より一般的な超並列SIMDアーキテクチャを使用して実装できるほど十分なチップ密度がなかったため、パフォーマンスのために柔軟性を犠牲にしました。
最新のGPU（Nvidia Fermiなど）は基本的に、CPUとさまざまなキャッシュからの命令とデータが供給される「愚かな」SIMDアレイのセットであり、グラフィックスパイプラインをそれらの命令にマッピングする実際のロジックはすべてグラフィックスドライバーで発生します？
特定のことはまだハードウェアで行われます。他の人はそうではありません。たとえば、ピクセルデータをVGAチップセットにプッシュするために、ROPは最終段階で引き続き使用されます。注ここでは、「VGAチップセット」を一般用語として使用しており、ビデオ信号をモニターに送信するメカニズムを指します。
一般的に、Nvidia FermiやAMD Southern Islandsなどの現在のGPUアーキテクチャは、大部分がカスタム命令セットを備えた超並列CPUであり、個々の「コア」は非常に弱いですが、全体のコアの多くの（時には数千）。しかし、そこにはまだグラフィック固有のハードウェアがあります。
多くの場合、ハードウェアビデオのデコードは、多くの場合、固定機能チップを使用して行われます。これは特に、DRM（デジタル制限管理）が関係している場合に当てはまります。「ハードウェア」ビデオデコードとは、SIMDコアの通常の古いタスクとして提供されるファームウェアガイドの命令セットを意味する場合があります。それは本当に依存しています。
ごく少数のコンピューティング固有のNvidiaボード（Tesla）を除き、ほぼすべての「汎用SIMD」グラフィックスカードには、ビデオ出力専用のハードウェアの完全な配列があります。ビデオ出力はレンダリングと同じではありません。HDMIはオーディオをサポートするため、固定機能の出力要素にはLVDS / TMDS / HDMI / DisplayPortコーデック、HDCP、さらにはオーディオ処理（基本的には小さなDSP）が含まれます。
「グラフィックメモリ」はまだGPUにオンボードで格納されているため、システムRAMにヒットするために、おしゃべりで比較的高いレイテンシのPCIeバスを通過する必要はありません。高品質、高速のグラフィックメモリ（GDDR5など）。システムメモリよりも容量は小さいが高速です。グラフィックメモリにデータを保存し、そこからGPUまたはCPUにデータを取得するプロセスは、まだほとんど固定された関数操作です。一部のGPUには独自の種類の「IOMMU」がありますが、このメモリ管理ユニットはCPUとは別の（別個の）ものです。ただし、これは、メモリアーキテクチャがほぼ完全に「コヒーレント」であるプロセッサ（Sandy and Ivy Bridge）に統合された最近のIntel GPUには当てはまりません。 システムメモリ）とグラフィックメモリからの読み取りは、GPUと同様にCPUにとっても安価です。
または、GPUのどこかに、入ってくる高レベルの命令とデータストリーム（コンパイルされたシェーダープログラム、頂点データと属性、およびテクスチャ）を実際のSIMD命令に変換し、同期、メモリ割り当てなどを処理する制御ユニットがありますか？
SIMDの「ネイティブ」言語は、ほとんどの場合、GPU自身のファームウェアではなく、ソフトウェアのドライバーによって生成されます。これは、特にDirectX 9 / OpenGL 2.xレベルの機能に当てはまります。HLSL、GLSL、OpenGL ARBシェーダーアセンブラーなどの高レベル言語で記述されたシェーダーは、ドライバーによって、特定のレジスタを強打し、必要なPCIeフープを実行して計算および/またはレンダリングのバッチバッファーを送信することにより、最終的にGPU命令に変換されますコマンド。
ハードウェアテッセレーション（DirectX 11 / OpenGL 4.0）などのいくつかの機能は、以前のほとんどすべてを実行する方法と同様に、固定機能の方法でハードウェアに再びプッシュされます。これは、パフォーマンスの制約により、これらの計算を行うための最も効率的な方法は、ファームウェアまたはドライバーがそれを行うためにSIMDを「プログラム」するのではなく、専用の回路を持つことを必要とするためです。
現実はこれらの両極端のどこかにあると思われ、答えはかなり長く、多くの推測に基づいています（特定のGPUベンダーが製品についてのドキュメントを公開することを拒否し、ドライバーはもちろん理由があるはずです）ソースコード...）、しかし正しい方向のヒントや有用なリソースは大歓迎です。
AMDとIntelは、最近のGPUについて非常に堅牢なドキュメントを公開しているほか、Linux用の完全に機能するオープンソースグラフィックドライバーも提供しています（MesaおよびDirect Rendering Managerプロジェクトを参照）。これらのドライバーのコードの一部を見ると、グラフィックドライバーの作成者はさまざまな形状やパターンの描画などのジオメトリを「ソフトウェア」で実装する必要があります（ただし、ハードウェアコマンドを使用して実際のGPUファームウェアも固定機能もハードウェアで完全に処理するためにもう存在しないためです:) OpenGL 1.x / 2.xをサポートするためにやらなければならないことはちょっと面白いハードウェア。
進化は次のようになりました。
- かなり前（リアルタイム3Dレンダリングが可能と見なされる前）：CPUでのレイトレーシングは、非リアルタイムレンダリングでは正常でした。Windowsの初期バージョンで見られるような単純なグラフィックスの場合、CPUは固定機能ハードウェアなしで単純な形状（長方形、フォントの文字、シェーディングパターンなど）を描画するのに十分高速でしたが、あまりにも複雑なものは描画できませんでした。
- 昔（OpenGL 1.x）：ほぼすべてがソリッドステートハードウェアによって実装されていました。「電気的に」固定された機能は、基本操作でも標準でした
- 少し前（OpenGL 2.x）：GPUをよりプログラム可能にする方向への移行が始まっていました。5年前のハードウェア上の「フラグメントシェーダー」（別名ピクセルシェーダー）は、CPUのようなほぼ任意の計算を実行できますが、アーキテクチャによって制限されています。したがって、このハードウェアではOpenCL / DirectComputeは使用できません。
- 最近（OpenGL 3.x）：汎用GPUへの移行はほぼ完了していますが、もちろん、効率的に動作できるCPUではなく、大量のデータ行列（線形代数を考える）がバッチで送信されるワークロードに最適化されています非常に小さなデータの長いシーケンス（1 + 1、2 * 4、5 * 6のシーケンスなど）汎用コンピューティングはOpenCL、CUDAなどを介して利用できますが、ハードウェアはまだ完全な「SIMDコプロセッサー」ではありません（a）GPUの機能を利用するには、ハードウェア固有のレジスタを使用する必要があるためです。（b）PCIeバスのオーバーヘッドのため、GPU VRAMからの読み取りは非常に遅い（GPUからの読み取りは現在のアーキテクチャではあまり最適化されていない）。（c）メモリおよびキャッシュアーキテクチャがCPUと一貫性がない。多くのレガシーな固定機能ハードウェアがまだ存在しています。
- 現在（OpenGL 4.x）：多くのレガシーな固定機能ハードウェアを取り除きました。GPUの読み取りレイテンシをいくらか改善しました。IOMMUを使用すると、VRAMとシステムメモリ間の（変換された）ハードウェア支援マッピングが可能になります。また、ハードウェアテッセレーションが導入され、固定機能の要素が復活しました。
- 未来（HSA）：GPUは基本的にコプロセッサーです。PCIeバス上の専用GPUであっても、GPUとCPUの間のインピーダンス（読み取り/書き込み用）はほとんどなく、CPUと完全に統合されています。完全に一貫したメモリアーキテクチャ-「mi memoria es su memoria」（私の記憶はあなたの記憶）ユーザー空間プログラムは、ドライバーシムなしでシステムメモリから読み取るのと同じように「VRAM」から読み取ることができ、ハードウェアがそれを処理します。適度な量のデータには「シリアル」処理用のCPU（これを実行し、次に実行し、次に実行し、次に実行します）、およびGPUは「並列」処理に使用します（この巨大なデータセットでこの操作を実行し、分割します）あなたがどのようにフィットするかを確認してください）。GPUが搭載されているボードには、ROP、HDMIコーデックなどがまだ残っている場合がありますが、これはディスプレイ出力に必要です。