WSLgのアーキテクチャーと仕組み
以前紹介したように「WSLg」は「WSL」上でLinuxのGUIアプリを動かすための仕組みです。
以下で「WSLg」のアーキテクチャーが紹介されています。
WSLgの紹介と利用について
「WSLg」の紹介と利用は、以下を参照してください。Waylandの実装
「WSLg」は「Wayland」を実装しており、「Wayland」コンポジターの役割を担います。「Wayland」に対応したアプリはそのまま「Wayland」上で動作し、X11で動作するアプリは「XWayland」上で動作します。
Westonがベース
「WSLg」の「Wayland」の実装は、Waylandコンポジターのリファレンス実装である「Weston」がベースになっています。また「WSLg」の「Wayland」の実装は、不具合の修正とアプリケーションのリモートに関連する部分以外、「Weston」の実装が採用されています。
Weston上で動作するアプリはWSLgでも動作する
「Wayland」は独自プロトコルの定義や実装が可能ですが、これらの実装は行われていません。そのため「Wayland」もしくは「XWayland」上で動作するアプリは、「Weston」上で動作するのとほぼ同等の動作になります。
言い換えれば「Weston」上で動作するアプリは、「WSLg」でも期待通りに動作するでしょう。
RDPで仮想マシンとホストが通信
「Weston」にはすでに「RDP（Remote Desktop Protocol）」バックエンドが実装されており、「FreeRDP」を利用した「Microsoft」の標準的な「RDP」を通じてホストと通信することができます。RDPバックエンドを拡張
さて「Windows」には「Windows Virtual Desktop（WVD）」というリモートデスクトップを実現するソフトウェアがあり、「WVD」はリモートアプリケーションをユーザーのローカルデスクトップに統合するため、「RDP RAIL（Remote Application Integrated Locally）」と言う仕組みを利用しています。また「Windows Defender Application Guard」のように仮想マシンの境界を超えて通信する「RDP」の技術を活用した「VAIL（Virtualized Application Integrated Locally）」と呼ばれる仕組みもあります。
そこで「Weston」の「RDP」バックエンドを「RAIL」や「VAIL」を活用して拡張し、アプリのリモート処理を実現することになりました。
WSLgのWestonコンポジター
「Weston」コンポジターは「WSLg」の核となる部分です。RDPバックエンドの大幅な拡張
「WSLg」が提供する「Weston」コンポジターは、「Weston」の「RDP」バックエンド部分を大幅に拡張した「Weston」コンポジターです。新しいRAIL及びVAILシェルが実装され、様々な不具合が修正されています。
RAILシェルの目的は、アプリのウィンドウを個別にLinuxからWindowsへリモート処理する際にそれを支援することです。
また「RAIL」や「VAIL（GrfxRedirection）」プロトコルでのアプリケーションのリモートがサポートされています。
これらによりデスクトップ全体ではなくアプリのウィンドウごとにリモートできるようになりました。
RAILとVAILの違い
「RAIL」と「VAIL」の違いは、RDPサーバー（WSLg）からホスト上のRDPクライアントへウィンドウのピクセルコンテンツをコピーする方法です。「RAIL」はネットワークを介して接続するRDPサーバーとRDPクライアント向けに最適化されています。
「VAIL」は「RAIL」と非常によく似ていますが、「VAIL」は仮想マシン（VM）の境界を超えた通信に最適化されています。
「VAIL」はホスト及びゲストVM間で共有メモリーを使用し、「RDP」を介したピクセルのコピーにかかる負荷の大きいコストを削減しています。
「libweston」の「RDP」バックエンドでは「RAIL」と「VAIL」の両方がサポートされていますが、「WSLg」にとって「VAIL」の利用が効果的であり「RAIL」の利用から「VAIL」の利用へと切り替えられました。
DPIスケーリングのサポート
また「RDP」バックエンドはマルチモニターをサポートするように拡張されています。これにはモニターごとのDPIスケーリングのサポートも含まれています。
DPIスケーリングは「Windows」の設定でユーザーが選択したスケーリング設定でLinuxのGUIがスケーリングされます。
コピー＆ペーストのサポート
LinuxとWindowsアプリ間でテキストやHTML、ビットマップといったデータのコピー＆ペーストがサポートされています。ドラッグ＆ドロップはまだ未サポート
LinuxとWindowsアプリ間のドラッグ＆ドロップはまだ未サポートです。オーディオの入出力
オーディオの入出力もサポートされています。オーディオの入出力には「PulseAudio」が利用されています。
sinkとsourceプラグインの開発
「PulseAudio」でオーディオの入出力をサポートするにあたり、「PulseAudio」で使用するsinkとsourceプラグインが開発されました。- microsoft / pulseaudio-mirror - module-rdp-sink.c
- microsoft / pulseaudio-mirror - module-rdp-source.c
これらのプラグインは「PulseAudio」と「RDP」バックエンド間でオーディオデータをやり取りするためのものであり、「RDP」を経由してローカルもしくはリモートの「RDP」クライアントとの連携を可能にします。
GUIアプリの環境を構築するWSLGd
「WSLGd」はデーモンのようなアプリケーションであり、「WSLg」環境において最初に実行されるプロセスです。「WSLGd」は「Weston」や「PulseAudio」を起動し、ホストとの「RDP」接続を確立します。
その後それらの動作状況を監視し、もしクラッシュや機能停止状態になったら、それらを再起動します。
スタートメニューとの連携
「Windows」のスタートメニューとの統合を実現するRDPプラグインが開発されました。
Linuxのアプリケーションをスタートメニューに追加
「Weston」内にあるプラグインは、ユーザーディストリビューション内にインストールされたアプリをデスクトップファイルを検索することで列挙します。そのアプリの一覧はアプリを起動するためのコマンドラインやアプリのアイコン情報と共にホストへ送信されます。
そしてホスト側のプラグインはその情報を元にLinux GUIアプリケーションをユーザーのスタートメニューに追加します。
これによりLinuxのアプリケーションを「Windows」のスタートメニューから直接起動できるようになります。
デスクトップファイルの監視
デスクトップファイルを配置する標準的なディレクトリーのいくつかは監視され、Linuxディストリビューション内でアプリのインストールやアンインストールを実行すると、その内容が数秒遅れてスタートメニューに反映されるようになっています。FreeRDPの拡張と修正
「FreeRDP」は新しいプロトコルをサポートするように拡張され、「mstsc」と通信する時に発生する互換性の問題が修正されています。システムディストリビューション
システムディストリビューションは「WSLg」のためのLinuxディストリビューションです。システムディストリビューションとユーザーディストリビューション
一方でユーザーがインストールしたLinuxディストリビューションはこれと区別され、ユーザーディストリビューションと呼ばれます。システムディストリビューションはLinux環境をコンテナー化したものと考えれば分かりやすいでしょう。
GUIアプリに必要なソフトウェアが動作する
システムディストリビューションでは、「Weston」を始めユーザーディストリビューションのGUIアプリを動作させるのに必要なサーバー群が動作しています。ユーザーディストリビューションはデフォルトでこれらのサーバーが受け持つソケットに接続するように設定されています。
GUIアプリはシステムディストリビューションを介してホストと連携することになります。
様々なユーザーディストリビューションに一貫した振る舞いを
システムディストリビューションを別途用意しユーザーディストリビューションと切り離して動作させることで、様々なユーザーディストリビューションに一貫した振る舞いを提供できます。CBL-Marinerを利用
「WSLg」をホストするために「CBL-Mariner」が利用されています。「CBL-Mariner」は軽量でカスタマイズ可能なLinuxディストリビューションであり、「Microsoft」によってメンテナンスされています。
システムディストリビューションは無効化できる
もしLinux GUIアプリを使用せずシステムディストリビューションを無効化したい場合は、「c:\users\ユーザー名\.wslconfig」ファイルに以下の設定を記述します。[wsl2]
guiApplications=false
guiApplications=false
OpenGLのハードウェアアクセラレーション
以前ほぼネイティブと同等の速度で動作するコンピューティングAPIを「WSL」で利用できるようにするとのアナウンスがありました。（vGPU）さらに幅広いハードウェア群で横断的に「WSL」でAIトレーニングを利用できるようにする「TensorFlow」向けDirectMLバックエンドのアナウンスもありました。
新しいd3d12 galliumドライバー
「Microsoft」は「Mesa」と連携し「Mesa」向けに新しいd3d12 Galliumドライバーを開発しました。またARMベースの「Windows」で今までサポートが欠けていた「OpenGL」や「OpenCL」のハードウェアアクセラレーションを実現する仕組みもアナウンスされました。
Linuxをサポートするための新しいd3d12 galliumGalliumは数週間前にアップストリームの「Mesa」に取り込まれ、「Mesa 21.0」の公式リリースでこのドライバーが含まれるようになりました。
OpenGLでハードウェアアクセラレーションが有効に
これにより「WSLg」で動作するLinux GUIアプリはハードウェアアクセラレーションに対応した「OpenGL」を利用できるようになりました。ちなみに「WSLg」は「vGPU」やハードウェアアクセラレーションに対応した「OpenGL」を利用できなくても動作します。
例えば2Dのアプリはハードウェアアクセラレーションに対応した「OpenGL」の有無に関わらず問題なく動作します。
ただその一方で「Blender」や「Gazebo」といった複雑な3Dの処理を行うアプリは、「WDDMv3.0」をサポートし「vGPU」に対応したGPUを利用可能な環境であれば、「Mesa」を通じて自動的にハードウェアアクセラレーションに対応した「OpenGL」を活用でき、パフォーマンスを大幅に向上させることができます。
WDDMv3.0ドライバー
各ベンダーから「WDDMv3.0」に対応したプレビュー版ドライバーがリリースされています。これらのドライバーは次期バーションの「Windows」がリリースされた時に、最終的に新しいシステムと共に「Windows Update」を通じて配布されるようになります。
Linuxディストリビューションが提供するMesaのバージョン
多くのLinuxディストリビューションでは、まだ「Mesa 20.x」を提供しています。「Microsoft」は、「Mesa 21.x」に加え新しいd3d12 Galliumドライバーをビルドして提供するよう、WSL向けLinuxディストリビューションを提供する様々なディストリビューターに働きかけています。
ちなみに「Ubuntu on Windows Community Preview」は「Mesa 21.0」を提供しています。
パフォーマンスは改善の余地あり
「OpenGL」がハードウェアアクセラレーションに対応したといっても「dGPU」（CPU内臓ではない外付けのGPU）では、ネイティブなパフォーマンスに比べれば特に非常に高いフレームレートで動作するアプリは、ネイティブのパフォーマンスに及びません。これはレンダリングデータがVRAMからシステムメモリーにコピーされ、さらにそこからGPUに返されるためです。
例えばWindowsネイティブで540fps動作するアプリは、350fps程度の性能に落ちます。
フレームレートが高くなればなるほどこの乖離は大きくなりますが、そうでなければここまで大きな乖離は見られないでしょう。
そしてソフトウェアレンダリング（4fps）に比べれば圧倒的高いパフォーマンスで動作します。
内蔵GPUでは上記のようなコピーが発生しないため、ワークロードにも寄りますがネイティブに近いフレームレートが得られるでしょう。
この点は次期バージョンの「WSLg v2」及びそれ以降で改善が予定されています。
