開発者向けの主要プラットフォームであり続けるために
LinuxのGUIアプリへの対応が必要？
Microsoftは、WSL2（Windows Subsystem for Linux 2）でLinux GUIアプリケーションに対応することを計画している。以下の動画は昨年9月に開催されたXDC 2020のセッションのものだ。
上のWSLGのデモビデオより。GIMPや裏のウィンドウのタイトルバーはLinux GUIアプリケーションのもので、Windows 10とは明らかに違う。ただ、GIMPなどのアイコンがタスクバーに表示されていることから、Windowsのデスクトップのウィンドウになっていることがわかる
この改良はかなり大きなものと言える。以前紹介したWSL2のGPUコンピューティングへの対応も（「Windows 10のWSL2からGPUが使えるようになった」）、WSL2内でGPUによる描画（ただし表示ではない）の前段階の一部である。ちょっと大きめの話でもあるので、今回は前後編に分けて紹介していく予定だ。
ではなぜ、WSL2でLinux GUIアプリケーションに対応しなければならないのだろうか。それはおそらく、ChromebookやPC上の仮想マシン環境（Hyper-Vを含む）などとの関係からだと思われる。
まず仮想環境では、仮想ディスプレイデバイスを介して、Linuxのデスクトップを表示可能になっている。このためにはOSの「準仮想化」が必要で、Hyper-VやViraualBoxにはグラフィックス表示が可能なLinuxディストリビューションがある。
さらにChromebookでは、仮想マシン内でLinuxを動作させ、Linux GUIアプリケーションのウィンドウをChrome OSのデスクトップに表示・利用できるようになった。このことでAndroidのアプリ開発はChromebookだけで完結する。GoogleのGUI開発環境であるAndroid StudioがChromebookで動作するわけだ。それ以外にも、EclipseなどLinux上のGUIを持つ開発環境がある。
Microsoftとしては、Windowsが開発者向けの主要なプラットフォームであることを維持したい。そういう背景もあり、WSL2でLinux GUIアプリケーションを動作させることにしたのだと考えられる。
もう1つの理由として考えられるのが、Microsoftが進める.NET Frameworkのマルチプラットフォーム化だ。Linuxでも.NET Frameworkのアプリケーションを動作させることを考えると、Windowsと同じGPUコンピューティング（DirectML）やDirectXグラフィックスを利用するアプリケーションが動作することが望ましい。
物理デバイスの制御に関しては、Linuxの流儀に従うとしても、上位のAPIレベルでは、なんとか互換性を取りたいところ。そのためには、LinuxでもWindowsと同等のグラフィックス、GPU利用APIを動かしたい。そういう方向性でプレビューが開始されたのが、WSL2でGPUコンピューティングを可能にする機能というわけだ。
この際に導入されたのが、以下の図のようなDirectX GraphicsをWSL2内で動作させる仕組みだ。ただし、現時点でも、MESAなどの対応は完了しておらず、CUDAなどからGPUが利用できるに留まっている。
Microsoftは、WSL2でGPUコンピューティングを可能にしたプレビューを進めている。これは、図左上のCUDAが動作している。CUDAは、WSL2内でDirectX機能を使って実装されており、VMBusを経由してWin32側のDirectX Graphicsカーネル（DXGカーネル）に接続する。Win32側でも、ユーザーモードドライバーなどでGPU機能を使う場合、DXGカーネルと接続し、GPU機能を利用するようになっている
DirectX Graphicsでは、対応GUIアプリケーションは、DirectX GraphicsやOpenGLなどを使って自身のメモリ領域（バッファ）に描画指示や描画リソース（ビットマップなど）を置いて、GPUに処理させる。GPUコンピューティングではほぼ同じ仕組みだ。このとき、DirectXのユーザーモードドライバーを利用する。WPFなどの抽象度の高いグラフィックス描画でも下の部分は同じ。最終的にアプリのプロセスごとにウィンドウ内の描画を作る。
Windows 10ではDesktop Window Manager（DWM）が合成してデスクトップに表示する。ここにもGPUが使われている。こうした構造をCompositorあるいはComposit形式という。
そもそもCompositorを使ってデスクトップを「合成」するというのは2000年以降に普及し始めた。かつては、ウィンドウマネージャーがアプリケーションに通知（隠れていたウィンドウの一部が表示されたなどのイベント）してウィンドウを直接描画させていたが、アプリケーションにより、描画が遅い、あるいは描画をきちんとやらないといったことで、デスクトップ全体の応答速度が犠牲になったり、不完全なウィンドウのままになることがあった。
ウィンドウ内の描画が「完了」したかどうかは、アプリケーションにしかわからないためだ。そしてウィンドウマネージャー側は、描画の終了を待たねばならず、他のウィンドウを更新できなくなる。これが全体の足を引っ張ることがあった。
そこで、ほかに影響が出ないようにアプリケーションプロセスには自身のメモリなどに置いたバッファに描画をさせ、ウィンドウマネージャーは、描画が終了したものを合成して表示するようになった。こうすることでアプリケーション側がどう振る舞おうとも、自分の中で完結している処理なので、デスクトップの表示に影響を与えない。GPUを利用した描画は、アプリケーション側でユーザーモードドライバーなどを使って自分のところで処理するようになった。
アプリケーションの描画が問題でデスクトップ全体の速度が落ちてしまう問題は、Windowsにもあり、Windows VistaでDWMという形でCompositorが搭載された。Windows Vista以後、ウィンドウタイトルに「応答なし」と表示されるのをよく見かけるようになったのはこうした事情による。Windows Vistaからは、一定時間内（5秒）にDWMからのイベントに応答しないウィンドウの代わりに絵を描いただけのGhost Windowを表示し、そのタイトルバーに「応答なし」と表示しているのだ。
