GPU仮想化技術の詳しい説明

GPU の英語名は Graphic Processing Unit で、中国語での正式名称は computer graphics processing unit であり、1999 年に NVIDIA によって提案されました。

[[262683]]

1. GPUの概要

GPU の概念は、コンピュータ システム内の CPU に関連します。特に家庭用システムやゲーム愛好家の間ではグラフィックスに対する需要が高まり、従来の CPU では現状に対応できないため、グラフィックス処理専用のコア プロセッサを提供する必要があります。

ハードウェア グラフィック カードの「心臓部」である GPU は、コンピュータ システム内の CPU と同じ役割を果たします。同時に、GPU は 2D ハードウェア グラフィックス カードと 3D ハードウェア グラフィックス カードを区別するための重要な基準としても使用できます。 2D ハードウェア グラフィックスでは、主に CPU を使用して機能と 3D グラフィックスを処理します。これは「ソフト アクセラレーション」と呼ばれます。

3D ハードウェア グラフィックス カードは、機能と 3D 画像処理能力をハードウェア グラフィックス カードに集中させます。これを「ハードウェア アクセラレーション」と呼びます。市場で人気のあるグラフィック カードのほとんどは、NVIDIA と ATI の 2 つの会社によって製造されています。

1.1.グラフィックタスクを処理するために GPU が必要なのはなぜですか? CPU は同じことができないのはなぜですか?

GPU は並列プログラミング モデルであり、CPU のシリアル プログラミング モデルとはまったく異なります。その結果、CPU 上の優れたアルゴリズムの多くは GPU に直接マッピングできません。また、GPU の構造は共有メモリマルチプロセッシング構造と同等です。したがって、GPU 上で設計された並列プログラムは、CPU 上のシリアルプログラムとは大きく異なります。 GPU は主に、キュービック環境マテリアル マッピング、ハードウェア T&L、頂点ブレンディング、バンプ マッピングとテクスチャ圧縮、デュアル テクスチャ 4 ピクセル 256 ビット レンダリング エンジンなどの重要なテクノロジを使用します。

グラフィックス レンダリング タスクは高度に並列化されているため、GPU は並列処理ユニットとメモリ制御ユニットを追加するだけで、処理能力とメモリ帯域幅を効果的に向上できます。

GPU の設計目的は CPU とはまったく異なります。 CPU は一般的なタスクを処理するように設計されているため、複雑な制御ユニットを備えていますが、GPU は主に、計算負荷は高いがあまり論理的ではないコンピューティング タスクを処理するために使用されます。 GPU で利用可能な処理ユニットは、実行ユニットとしてさらに活用できます。したがって、大規模な繰り返しデータセットの計算や頻繁なメモリアクセスなどの特性を持つアプリケーションシナリオでは、CPU と比較して GPU には比類のない利点があります。

1.2. GPU の使い方は?

GPU を使用する方法は 2 つあります。 1 つは、開発されたアプリケーションが一般的なグラフィックス ライブラリ インターフェイスを介して GPU デバイスを呼び出すことです。もう 1 つは、GPU 自体が API プログラミング インターフェイスを提供し、アプリケーションが GPU が提供する API プログラミング インターフェイスを介して GPU デバイスを直接呼び出すというものです。

1.2.1 一般的なグラフィックライブラリ

一般的なグラフィックス ライブラリを介して GPU を使用するには、OpenGL や Direct3D などの既存のグラフィックス関数ライブラリを使用してシェーディング言語を記述し、GPU 内のレンダラー (シェーダー) を制御して必要な計算を完了します。

現在、業界で認められている 2 つの主要なグラフィック プログラミング インターフェイスは、OpenGL と DirectX です。 OpenGL は現在、インタラクティブでポータブルな 2D および 3D グラフィックス アプリケーションを開発するための最適な環境であり、グラフィックス アプリケーションで最も広く使用されている標準でもあります。 OpenGL は、SGI によって開発されたコンピュータ グラフィックス処理システムです。グラフィック ハードウェア用のソフトウェア インターフェイスです。 GL はグラフィックス ライブラリの略です。 OpenGL アプリケーションでは、オペレーティング システムや動作環境のプラットフォームを気にする必要はありません。

OpenGL 標準に準拠した環境であれば、同様の視覚効果が得られます。 OpenGL と同様に、DirectX (Directe Xtension) もグラフィックス API です。これは、Microsoft によって作成されたマルチメディア プログラミング インターフェイスであり、Microsoft Windows の標準となっています。 DirectX は、GPU アプリケーションのニーズを満たすために、新しい GPU 製品機能の拡張と進歩に基づいてタイムリーに新しいバージョンを定義しており、それが提供する機能は GPU によって提供される機能とほぼ同期しています。

1.2.2 GPUプログラミングインターフェース

GPU自体が提供するプログラミングインターフェースは、主にGPUデバイスを提供する2社、NVIDIAのCUDAフレームワークと、2006年に提案されたAMD(ATI)のCTM(Close To Metal)フレームワークによって提供されています(注: ATIはもともとGPUデバイスを製造しており、後にAMDに買収されました)。 AMD の CTM フレームワークは現在使用されていません。主な理由は、AMD (ATI) が 2007 年に ATI Stream SDK アーキテクチャを開始し、2008 年にパブリック OpenCL 標準に完全に切り替えたためです。したがって、AMD (ATI) には現在、独立したプライベートな汎用コンピューティング フレームワークはありません。

2007 年、NVIDIA は CUDA (Compute Unified Device Architecture) 専用の汎用コンピューティング フレームワークをリリースしました。一般的なコンピューティング プログラミングに CUDA を使用する場合、グラフィックス API を使用する必要はなくなり、代わりに C 言語に非常によく似た開発アプローチが使用されます。 CUDA プログラミング モデルには、ホストと呼ばれる CPU と、デバイスまたはコプロセッサと呼ばれる複数の GPU があります。

このモデルでは、CPU と GPU が連携して、それぞれが独自の機能を実行します。 CPU は論理トランザクション処理とシリアル計算を担当し、GPU はスレッド化された並列処理タスクの実行に重点を置いています。 CPU と GPU にはそれぞれ、ホスト側メモリとデバイス側ビデオメモリという独立したメモリ アドレス空間があります。一般的に、石油探査、流体力学シミュレーション、分子動力学シミュレーション、生物学的コンピューティング、オーディオおよびビデオのエンコードとデコード、天文学的コンピューティングなどの分野など、一部の大規模なアプリケーションは CUDA フレームワークを使用してプログラムされます。

ただし、開発コストと互換性の理由により、一般的なエンタープライズ レベルのアプリケーションのほとんどは、一般的なグラフィックス ライブラリを使用して GPU デバイスを開発および呼び出します。

1.3. GPUはどのように機能しますか?

一般的なコンピューティングとグラフィック処理用の GPU の内部コンポーネントは、主に頂点プロセッサとフラグメント プロセッサの 2 つの部分で構成されます。このプロセッサにはストリーム処理モードがあり、読み取りと書き込み用の大容量のキャッシュ/メモリは搭載されておらず、チップ上の一時レジスタのみを使用してストリーム データを操作します。

GPU をグラフィック処理に使用する場合、GPU 内の頂点レンダリング、ピクセル レンダリング、ジオメトリ レンダリング操作はすべて、ストリーム プロセッサを通じて完了できます。図からわかるように、現時点では GPU 内のすべてのストリーム プロセッサはマルチコア プロセッサに相当します。異なるストリーム プロセッサの入力と出力間でデータを簡単に移動できます。同時に、ストリーム プロセッサは汎用的であるため、GPU ディスパッチャと制御ロジックは、対応する頂点、ピクセル、ジオメトリ、およびその他の操作を実行するためにストリーム プロセッサを動的に割り当てることができます。

2. GPU仮想化

話題から始めましょう。現在、仮想マシン システムでのグラフィック処理には、仮想グラフィック カードを使用する方法、物理グラフィック カードを直接使用する方法、GPU 仮想化を使用する方法の 3 つの方法があります。

2.1.仮想グラフィックカード

1 つ目は、仮想グラフィック カードを使用することです。これは、プロ仕様のグラフィック カード ハードウェアが高価なため、現在では仮想化システムの主流の選択肢となっています。現在仮想グラフィック カードを使用しているテクノロジには、次のものがあります。

• VNC (仮想ネットワークコンピューティング)
• Xen 仮想フレーム バッファ
• VMware 仮想グラフィック ディスプレイ プロセッサ GPU (グラフィックス プロセッシング ユニット)
• VMGL (VMM 独立グラフィック アクセラレーション) は、仮想マシン マネージャーから独立したグラフィック アクセラレーション システムです。

VNC (Virtual Network Computing) は基本的に表示システムであり、完全なウィンドウ インターフェイスをネットワーク経由で別のコンピューターの画面に送信できます。 Windows Server に含まれる「ターミナル サーバー」は、この原則に基づいて設計されています。 VNC は AT&T Labs によって開発され、GPL (General Public License) ライセンス条項を使用しているため、誰でも無料でソフトウェアを入手できます。 VNC ソフトウェアは、VNC サーバーと VNC ビューアーの 2 つの部分で構成されています。ユーザーは、ホスト上で VNC ビューアを実行してリモート コントロールを実行する前に、リモート コントロールするコンピューターに VNC サーバーをインストールする必要があります。

XEN 仮想フレーム バッファは、XEN によって提供される仮想ディスプレイ デバイスを指します。仮想ディスプレイ デバイスは特権ドメインの VNC サーバーを使用するため、仮想ディスプレイ デバイスには同様の VNC インターフェイスがあります。クライアントは XEN 仮想フレーム バッファにデータを書き込み、変更されたイメージを VNC プロトコル経由で送信し、最後にフロント エンドに通知して対応する領域を更新します。この仮想フレーム バッファー デバイスのソース コードは、オープン ソースの Qemu から取得されます。 XenServer 上に表示される仮想マシンのオペレーティング システム デスクトップ インターフェイスは、このテクノロジの表示です。

仮想ネットワーク コンピュータ (VNC) と XEN 仮想フレーム バッファは、仮想マシンで特定のハードウェア グラフィック アクセラレーション機能をまだ提供していない 2 つのモードです。現在、仮想マシンがグラフィック ハードウェアにアクセスできるようにするメカニズムはないため、これらの仮想ディスプレイ デバイスは CPU とメモリを使用してグラフィック データを処理します。物理的なディスプレイデバイスの機能は活用されません。

ただし、VMGL モデルでは、通常フロントエンド仮想化と呼ばれるこのメカニズムがすでに実装されています。 VMGL モードでは、このメカニズムを使用して、グラフィックス処理を必要とするデータを、対応するグラフィックス データ処理のためのハードウェア グラフィックス アクセラレーション機能を備えた仮想モニターに送信します。現在、GPU アプリケーション開発に使用できる主流のグラフィック処理インターフェイスは、OpenGL と Direct3D の 2 つです。

これら 2 種類のグラフィックス処理インターフェイスのうち、OpenGL は、主流のオペレーティング システムのプラットフォーム間で動作できる唯一のグラフィックス API インターフェイスです。仮想マシン プラットフォームにおいて、VMGL は OpenGL API を仮想化する最初のプロジェクトです。 VMGL の動作原理は、クライアント オペレーティング システムに偽のライブラリを展開して、標準の OpenGL ライブラリを置き換えることです。偽のライブラリは、標準の OpenGL ライブラリと同じインターフェースを備えています。クライアント オペレーティング システム内の偽のライブラリは、リモート サーバーのホスト オペレーティング システムへのリモート呼び出しも実装します。

この方法では、すべてのローカル OPENGL 呼び出しは、リモート サーバーへのサービス要求として解釈されます。リモート サーバーのホスト オペレーティング システムには、実際の OPENGL ライブラリ、グラフィックス ドライバー、物理ハードウェア GPU があり、OPENGL 要求を完了して実行結果を画面に表示する役割を担っています。 VMGL はプロセス全体を通じて完全に透過的であるため、OPENGL を呼び出すアプリケーションはソース コードを変更したりバイナリを書き換えたりする必要がなく、仮想マシン プラットフォームに変更を加える必要もありません。

2.2 グラフィックカードパススルー

グラフィック カード パススルーは、グラフィック カード ペネトレーション (Pass-Through) とも呼ばれ、仮想マシン管理システムをバイパスして GPU を仮想マシンに割り当てることを意味します。 GPU を使用する権限があるのは仮想マシンのみです。この排他的なデバイス割り当て方法により、GPU の整合性と独立性が維持され、そのパフォーマンスは非仮想化条件でのパフォーマンスに近くなり、一般的なコンピューティングに使用できます。ただし、グラフィック カード パススルーでは、グラフィック カードの特殊な詳細を使用する必要があり、互換性が低いため、一部の GPU デバイスでしか使用できません。

Xen 4.0 では VGA パススルー テクノロジが追加されたため、XenServer にもこのテクノロジが搭載されています。 XenServer のパススルーは、Intel Device Virtualization (Intel VT-d) テクノロジを使用して、ディスプレイ デバイスを特定のクライアント仮想マシンに公開します。他のクライアント仮想マシンがアクセスできなくなるだけでなく、ホスト仮想マシンも GPU を使用できなくなります。直接アクセスをサポートするために、VGA BIOS、テキスト モード、IO ポート、メモリ マッピング、VESA モードなど、ゲスト仮想マシンのグラフィック カードのいくつかの特別な詳細を実装します。 Xen Server の VGA パススルー テクノロジを使用する GPU は、実行効率が高く、機能が充実していますが、単一のシステムでのみ排他的に使用でき、デバイスの多重化機能が失われます。 VMware ESXi には VM Direct Path I/O フレームワークが含まれており、これを使用してグラフィック カード デバイスを仮想マシンに直接渡して使用することができます。

XenServer と VMware は異なるテクノロジを使用しますが、同じ効果を実現します。つまり、物理グラフィック カード デバイスを仮想マシンの 1 つに直接渡して、仮想マシンの 3D 表示とレンダリングの効果を実現します。

グラフィックス パススルーは、実際にはネイティブ ドライバーとハードウェアを使用してクライアント オペレーティング システムによって実装されるため、GPU の状態を追跡および維持するために必要な中間層が不足しており、ライブ マイグレーションなどの高度な仮想マシン機能はサポートされていません。たとえば、XenServer Passthrough では、保存/復元/移行などの操作の実行が禁止されます。 VMware 仮想マシンでは、VMDirectPath I/O 機能を有効にすると、対応する仮想マシンはサスペンド/再開およびライブ マイグレーションを実行できなくなります。

2.3 グラフィックカード仮想化（GPU仮想化）

グラフィック カードの仮想化は、グラフィック カードをスライスし、これらのグラフィック カードのタイム スライスを仮想マシンに割り当てて使用するプロセスです。グラフィック カード仮想化をサポートするグラフィック カードは、一般的に必要に応じて異なる仕様のタイム スライスに分割できるため、複数の仮想マシンに割り当てて使用することができます。実際の実装原則は、アプリケーション層インターフェイス仮想化 (API リモート処理) を使用することです。 API リダイレクトとは、アプリケーション層で GPU 関連のアプリケーション プログラミング インターフェイス (API) をインターセプトし、リダイレクトを通じて対応する機能を完了し (GPU を引き続き使用)、実行結果をアプリケーションに返すことを指します。

現在 Citrix が使用している 3D デスクトップ仮想化ソリューションのほとんどは、NVIDIA が提供するグラフィック カード仮想化テクノロジ、つまり vCUDA (仮想 CUDA) テクノロジを使用しています。 CUDA フレームワークについては以前に説明したので、ここでは説明しません。 vCUDA は、ユーザー レベルで CUDA API をインターセプトしてリダイレクトする方法を使用して、仮想マシン内の物理 GPU の論理イメージ (仮想 GPU) を確立し、GPU リソースのきめ細かい分割、再編成、再利用を実現し、マルチマシンの同時実行や一時停止と再開などの高度な仮想マシン機能をサポートします。

vCUDA の実装原理には、大まかに CUDA クライアント、CUDA サーバー、CUDA マネージャーの 3 つのモジュールが含まれます。 XenServer を例にとると、物理ハードウェア リソース上で VMM が実行され、上位層にハードウェア イメージが提供され、VMM 上で複数の仮想マシンが実行されます。仮想マシンの 1 つは特権仮想マシン (ホスト VM) であり、XenServer のドメイン 0 です。仮想マシンで実行されるオペレーティング システムはホスト OS と呼ばれます。

ホスト OS はハードウェアを直接制御できます。ネイティブ CUDA ライブラリと GPU ドライバーがシステムにインストールされ、ホスト OS が GPU に直接アクセスして CUDA を使用できるようになります。その他の仮想マシンは非特権仮想マシン (ゲスト VM) であり、その上で実行されているオペレーティング システム (ゲスト OS) は GPU を直接操作することはできません。ここでは、CUDA クライアントをクライアント ドライバー、CUDA サーバーをホスト ドライバー、CUDA マネージャーを GPU マネージャーと呼びます。

2.3.1、クライアント

クライアント ドライバーの本質は、Windows 7 などの仮想マシンにインストールするグラフィック ドライバーです。主な機能は、ユーザー レベルで CUDA API のライブラリと、CUDA 関連のソフトウェアおよびハードウェアの状態を維持する仮想 GPU (vGPU) を提供することです。クライアント ドライバーは CUDA アプリケーションを直接ターゲットとし、その機能には次のものが含まれます。

• 1) アプリケーション内の CUDA API 呼び出しをインターセプトします。
• 2) 仮想化に対するより高レベルのセマンティック サポートを提供するための通信戦略を選択します。
• 3) 呼び出されたインターフェースとパラメータをカプセル化してエンコードします。
• 4) サーバーから返されたデータをデコードし、アプリケーションに返します。

さらに、最初の API 呼び出しが到着する前に、クライアント ドライバーはまず管理側から GPU リソースを要求します。 GPU リソースとタスクのリアルタイム スケジューリングを実現するには、各独立した呼び出しプロセスがホスト管理ドライバーからリソースを申請する必要があります。

さらに、クライアント ドライバーは、グラフィック カードに関連するハードウェアとソフトウェアの状態を維持するために vGPU もセットアップします。 vGPU 自体は本質的には単なるキー値データ構造であり、現在使用されているアドレス空間、ビデオ メモリ オブジェクト、メモリ オブジェクトなどを格納し、API 呼び出しの順序も記録します。計算結果が返されると、クライアント ドライバーは結果に基づいて vGPU を更新します。

2.3.2 サーバー

サーバー側コンポーネントは、特権仮想マシン (XenServer 用語: 特権ドメイン) のアプリケーション層に存在します。特権仮想マシンはハードウェアと直接対話できるため、サーバー側のコンポーネントは物理 GPU を直接操作して一般的なコンピューティング タスクを完了できます。

サーバーは実際の G​​PU を対象としており、その機能には以下が含まれます。

• 1) クライアントのデータグラムを受信し、呼び出しとパラメータを解析します。
• 2) 呼び出しとパラメータを確認します。
• 3) CUDA と物理 GPU を使用して承認された呼び出しを計算します。
• 4) 結果をエンコードしてクライアントに返します。
• 5) コンピューティング システム内の CUDA 対応 GPU を管理します。

また、サーバーが最初に実行するタスクは、自身の CUDA 対応 GPU デバイスの情報を管理側に登録することです。サーバーはクライアントの要求に応答するときに、各アプリケーションに独立したサービス スレッドを割り当てます。サーバーは、ローカル GPU リソースを統一的に管理し、特定の戦略に従って GPU リソースを提供し、vGPU への API 呼び出しによって変更された関連するソフトウェアおよびハードウェアのステータスを更新します。

2.3.3 管理側

管理コンポーネントは特権ドメインに配置されます。 CUDA プログラミング インターフェイスの仮想化に基づいて、GPU の強力なコンピューティング能力とコンピューティング リソースが分離、分割され、より高い論理レベルでスケジュールされます。 CUDA サーバー側でコンピューティング スレッドとワーカー スレッドを使用すると、同じ物理マシン上の GPU 間の負荷をある程度分散できます。 CUDA 管理側コンポーネントは、同じ GPU 仮想クラスター内の GPU の負荷を分散するために、より高い論理レベルで負荷分散を実行するように設定されています。

管理側コンポーネント スケジューリングの原則は、同じ物理マシン上の GPU 需要を可能な限り自給自足にすることです。物理マシンに条件を満たす GPU リソースがある場合、通常、物理マシン上の仮想マシンの GPU 要求は、物理マシンの CUDA サーバーにリダイレクトされます。

管理側では、集中化された柔軟なメカニズムを使用して GPU リソースを統一的に管理し、次のことを実現します。

• 1) 動的スケジューリング: ユーザーが占有しているリソースのアイドル時間が一定のしきい値を超えるか、タスクが完了すると、管理側がリソースを回収します。ユーザーがコンピューティング タスクを再度公開すると、GPU リソースがタスクに再割り当てされます。
• 2) 負荷分散: ローカルのコンピューティング負荷が高すぎる場合は、動的スケジューリング中に適切な GPU リソースを選択してコンピューティング負荷を調整し、コンピューティング負荷を分散します。
• 3) 障害回復: 障害が発生すると、タスクは新しい利用可能な GPU リソースに転送されます。