Windows Virtual Desktop #36 AMD GPU を試す 後編

この記事のWVDは”Windows Virtual Desktop Spring 2020 Release”が対象です。

前編に続き Windows Virtual Desktop でGPU 仮想化をテストします。 WVD でのGPU 仮想化については過去にも2回( #13 , #14 )ほど記事にしています。 その時はNVIDIA のGPU を搭載する仮想マシンを利用していました。 今回はAMD Radeon Instinct MI25を搭載するNVv4-series を試してみます。  

3. VM 展開後のドライバインストール

元々あったworkspace にGPU仮想化のセッションホストを登録するhost pool を追加が出来ました。 リモートデスクトップクライアントから接続します。赤枠の”GPU Virtualization”が今回追加した host pool です。

3.1. ドライバインストール

仮想マシンをMarketplace から展開し初めてのサインインです。 従ってGPUは正しく認識されていません。

GPU をOSから正しく利用するには設定が必要です。 マニュアルを確認していきます。

  • AMD GPU drives のインストールは必ず必要
  • 手動でインストールするか、Azure Portal からextension を使ってインストールするか、Powershellのようなツールを使うか、ARM テンプレートを使うか、複数の方法でドライバのインストールは可能
  • このマニュアルでは手動でのインストールの手順を紹介
  • NVv4 向けにはMicrosoft が提供しているドライバだけがサポートされる。ほかで入手したドライバは使わないこと

あとはマニュアル(Microsoft Docs)の案内通りに進めていきます。同じページにドライバのダウンロードリンクとインストール手順があります。

WVD の仮想のWindows 10 でインストールモジュールをダウンロードします。

インストーラを実行します。

“Install” をクリックします。 フォルダが C:\AMD\ とC: ドライブ直下なのがちょっと気になりましたが今回はそのまま進めます。(直下はダメということはないです)

“Completed” まで進めば完了です。 ”Close” をクリックしますが、特に再起動は要求されません。 マニュアルでは”Reboot the VM” とのことで再起動の指示はあったのですが。

再起動する前に Device Manager で再度確認します。 すでに認識出来ているので再起動は不要そうです。 ただ Other devices に1つ Unknown device が残っているのが気持ち悪いですね。 意味は無いと思いますが一度再起動します。

再起動後も Other devices の Unknown device は残ったままでした。

また、ダメ元でOS パッチを最新化してみます。 不明なデバイスの有無にかかわらず実施する予定ではありましたが。

パッチを適用し、再起動しました。  最新化されました。

以下のオプションも有効にしています。

依然、Unknown Device は残っていますが、特に支障はないので調査と対応はここまでとします。

3.2. ドライバ動作確認

Microsoft Docs では “dxdiag” コマンドによる確認方法が案内されています。

コマンドプロンプトから “dxdiag”を実行します。

Windows 10 build 1903 以上ではDisplay タブに何も情報が表示されないとのこと。確かにその通り。 その場合は”Save All Information” からファイルに書き出し、そこで確認しましょう、とのこと。

書き出したテキストファイルからはGPUカードの情報やメモリサイズ、ドライバ情報など確認することが出来ました。

あとはタスクマネージャからもGPU の状態は確認可能です。

4. GPUへのオフロードの確認

WVD の仮想のWindows 10 にサインインします。

テストの条件は以下の通りです。 

  • 画面は全画面モード(物理ディスプレイのサイズは2560×1440 )
  • Chronium ベースのEdge からYoutube にアクセスします。 
  • コンテンツはAMD Instinct MI25 の紹介動画にしました。 
  • Full HD の60 FPS を指定します。

4.1. GPU アクセラレーション無

まずはGPUアクセラレーション無の場合です。 すべての処理をCPUで行います。

フレームレートは32 FPS (見た感じ30平均)です。さすがにインターネット経由のWVD で60 FPS は難しいようです。

CPU リソース使用率は40~50%です。 8 vCPU の50% というと4core 分です。 GPU 無しではYoutube のレンダリングおよび画面転送のエンコードは非常にCPUリソースを消費することがわかります。

GPU リソースは 0%のままです。 つまり、CPUリソースだけですべて処理している状況です。

4.2. GPU アクセラレーション有効化 (レンダリングのみ)

まずはGPU アクセラレーションを有効化します。  マニュアル

[コンピューターの構成] > [管理用テンプレート] > [Windows コンポーネント] > [リモート デスクトップ サービス] > [リモート デスクトップ セッション ホスト] > [リモート セッション環境] 

ポリシー [すべてのリモート デスクトップ サービス セッションにハードウェアの既定のグラフィックス アダプターを使用する] を選択し、このポリシーを [有効] に設定する。

上記ポリシーを設定後、gpupdate /force で強制適用しても有効はなりませんでした。 従ってVirtual Machine を再起動します。

再起動後、Task Manager ではGPU 0 のリソース使用を確認することが出来ました。

この状態でYoutube で動画視聴時にリソース状況を再確認します。

テストの条件は以下の通りです。 (4.1. と同じ)

  • 画面は全画面モード(物理ディスプレイのサイズは2560×1440 )
  • Chronium ベースのEdge からYoutube にアクセスします。 
  • コンテンツはAMD Instinct MI25 の紹介動画にしました。 
  • Full HD の60 FPS を指定します。

フレームレートは変わらず30 FPS 平均です。

CPUリソースは多くても30% です。 GPU無しと比べると15-20%は減っています。1-2 vCPU のリソースがGPU にオフロードされたとも言えます。

こちらがGPUリソースの使用状況。 まだまだ余裕がある感じです。

4.2. GPU アクセラレーション有効化 (レンダリング&フレームエンコード)

まずはフレームエンコードを有効化します。  マニュアル

  1. ポリシー [リモート デスクトップ接続で H.264/AVC 444 グラフィック モードを優先する] を選択し、このポリシーを [有効] に設定して、リモート セッションで H.264/AVC 444 コーデックを強制的に行います。
  2. ポリシー [リモート デスクトップ接続用に H.264/AVC ハードウェア エンコードを構成する] を選択し、このポリシーを [有効] に設定して、リモート セッションで AVC/H.264 に対するハードウェア エンコードを有効にします。

テストの条件は以下の通りです。 (4.1. と同じ)

  • 画面は全画面モード(物理ディスプレイのサイズは2560×1440 )
  • Chronium ベースのEdge からYoutube にアクセスします。 
  • コンテンツはAMD Instinct MI25 の紹介動画にしました。 
  • Full HD の60 FPS を指定します。

FPS は30FPS前後です。

CPUは40%を推移と4.2. のテストより増えています。 画面転送のエンコードをGPUにオフロードする分、CPUリソースは減少すると予測していたのですが逆の結果となりました。

GPUの使用状況は4.2. とあまり違いがわかりません。

マニュアルではフレームエンコードの有効化の確認はイベントログでおこなえるとのこと。

実際の環境で見てみると、Event ID:162 は見つかりましたが Event ID:170は見つかりません。  AMD が単純にH.264 のEncode/Decode に対応していない可能性もあります。 NVIDIA も初代のKepler ベースとなるGRID ではH.264 のオフロードは実装されておらず次のMaxwell 世代からでした。 時間を見て AMD のGPU のSpecification を眺めてみることにします。

5. まとめ

Windows Virtual Desktop の本格的な検討が増えていることは日々実感しています。 そんな中、より快適なデスクトップ環境をエンドユーザに届けるにはGPU仮想化の適用は避けて通れないと個人的には考えています。 

Windows Virtual Desktop を利用するメリットの1つにMulti-SessionがありますがどうしてもCPUリソースの枯渇はエンドユーザの操作レスポンスを劣化させます。 ただでさえGPUが必要な処理が増えているなか、それをすべてCPUで処理することはMulti-session での集約率を下げることになるでしょう。   最近のコロナウイルスを起因とするリモートワークの急激な広がりやそれに伴うリモート会議の一般化も非常に大きな要因です。 WVD にGPU仮想化技術を適用することでCPUの処理を出来る限りGPUへオフロードし、エンドユーザには快適なデスクトップ環境や動画・音声の実行環境を提供し、Multi-Sessionでの集約率を高める、それがWVDでの標準になっていくのではと考えています。

と言いつつ実は最近までAMDのGPU仮想化はほぼノーマークでした。 今回のテストで十分に使えることも確認でき、また、コスト面でも十分なメリットを出せそうです。 次回はMulti-Session でのサイジングに役立つベンチマークなどを実施出来ればと考えています。

以上