Windows 11のデスクトップ画面を、GPUではなくIntelのNPU（Neural Processing Unit）で合成する研究用ドライバ「npu-render」が公開された。labscommunityがGitHubで公開しているnpu-renderは、各ウィンドウの画像を一つのデスクトップ画面にまとめる処理をNPUへ移し、実際のディスプレイに表示する仕組みを構築したものだ。NPUをAI以外の用途に活用する興味深い試みだが、画面を表示できることと、快適に操作できることは別問題である。開発者が公開した試験結果からは、技術的な成果とともに、実用化までの課題も明らかになっている。
Windowsのデスクトップ合成処理をNPUへ移す仕組み
Windowsでは、デスクトップ ウィンドウ マネージャー（DWM）が各アプリケーションのウィンドウ画像を管理し、それらを組み合わせて最終的なデスクトップ画面を生成する。Microsoftの公式ドキュメントによると、各アプリケーションがウィンドウ内の内容を描画する処理と、複数のウィンドウを一つの画面に合成する処理は別の工程である。通常、後者の合成処理にはGPUが使われる。
npu-renderがNPUへ移すのは、このうちデスクトップの合成処理だ。専用のユーザーモードドライバがDWMから送られるDirect3D 10の描画命令をフレーム単位でまとめ、別のワーカープロセスがNPU上で実行する。生成された画像は間接ディスプレイドライバを経由し、物理ディスプレイに表示される。ただし、各アプリケーションやDWMは従来どおりDirect3Dを使い続けるため、PCの描画処理全体をNPUへ移したわけではない。実際のディスプレイへの表示にもGPUによる処理が一部残っている。
特徴的なのは、AI向けのNPUで通常のグラフィックス処理を実行する方法だ。OpenVINOのIntel NPUプラグインは、一般にAIモデルをNPU向けの形式へコンパイルし、Level Zero APIを通じて実行する。npu-renderでは、まず小さな「ScatterElementsUpdate」モデルをコンパイルし、その実行コードの一部を独自の描画プログラムに差し替える。これにより、Intel NPUに搭載されるプログラム可能な演算コア「SHAVE」で、AI推論とは異なる処理を実行している。
独自の描画プログラムには、図形を画素に変換するラスタライザーのほか、頂点処理、テクスチャ参照、画像の合成処理などが含まれる。開発者はコード領域を24KBから48KBに拡張し、DWMやWinUIが使用する38組のシェーダーを事前にC言語の処理へ変換した。さらに、画像を小さな領域に分割し、それぞれの処理に必要なテクスチャデータだけをNPUへ渡す仕組みも構築している。各処理の出力は参照結果と照合され、不一致が生じた場合には別の処理経路へ切り替わる設計だ。ただし、Direct3Dの全機能をNPU上に実装したものではなく、対象は実際のデスクトップ合成で使用される処理に限られる。
画面表示には成功したが、更新速度は毎秒2.5回
開発者は、描画結果の正確性と実際の操作に必要な性能を分けて検証している。まず、bundle v23に含まれる234件の検証データを実機のNPUで処理し、参照結果と画素単位で比較した。さらに、継続動作を調べた「trial12」では、2,160秒間に744の描画命令群、合計9,363命令を処理し、自己テストで不一致は発生しなかった。この間、物理ディスプレイへの表示用に提出されたフレームは342枚だった。
ここで重要なのは、744という数字が実際に表示されたフレーム数ではないことだ。これは処理した描画命令群の数であり、物理画面への表示に使われたフレームとは区別する必要がある。今回の試験では、描画結果が参照画像と一致すること、NPU上で処理が実行されること、実際の画面へ画像が届くことを、それぞれ異なる段階で確認している。
操作時の応答性を測る試験では、1024×768ピクセルの画面に対し、30Hzで300回の更新を要求した。しかし、検証済みの画面更新速度は毎秒2.5回にとどまり、目標の30Hzには大きく届かなかった。マウス入力から画面表示までの遅延は中央値が94ミリ秒だった一方、95パーセンタイル値は1.5秒に達した。ぼかしを含む合成処理では秒単位の時間がかかる場合もあり、現状では一般的なWindowsデスクトップに求められる滑らかな操作性を確保できていない。
これらの結果は、開発者がIntel Panther Lake搭載ノートPCを使って測定したものだ。試験環境はWindows 11、Intel NPUドライバ5540、OpenVINO 2026.4.1で、独立した第三者による追試や査読付き論文での検証は行われていない。したがって、今回の性能をIntel NPU全般の能力とみなすことはできない。
GPU使用率は低下したが、性能向上や省電力効果は未実証
npu-renderの狙いの一つは、デスクトップ合成処理をNPUへ移すことでGPUの負荷を軽減することにある。実際、開発者の試験ではGPU使用率が低下した例が確認されている。しかし、それがほかのGPU処理の高速化やPC全体の消費電力削減につながるかどうかは、まだ明らかになっていない。
開発者が公開した試験記録とREADMEを基に、主な測定結果とその限界を整理すると次のようになる。
| 試験・条件 | 主な測定結果 | 分かること・限界 |
|---|---|---|
| 録画試験v126：560×360ピクセルのウィンドウを30Hzで再描画 | GPU 3D使用率が3.4%から0.6%へ低下。NPU使用率の中央値は約58%、実画面への到達は約1.6フレーム/秒 | GPUの処理負荷は低下したが、実際の表示速度は30Hzに届かない。GPUによる画面のミラー合成も残る |
| GPU側の対照試験：GDIウィンドウの30Hz色変化、270サンプル | GPU 3D使用率の99パーセンタイル値は0.37% | NPUのtrial12とは異なる刺激を使用した別試験 |
| NPU trial12：presenter relayを使った30Hz刺激 | GPU 3D使用率の99パーセンタイル値は0.37% | 対照試験と同じ数値だが、表示性能や刺激条件をそろえた直接比較ではない |
| 録画試験v126でGPU表示へ復旧した後 | GPU 3D使用率は開始前の3.37%に対して復旧後1.85% | ウィンドウ配置を元に戻せておらず、同一条件での比較にはならない |
録画試験v126では、GPUの3D使用率が約3.4%から0.6%へ低下し、NPU使用率の中央値は約58%となった。ただし、これはGPUからNPUへ処理の一部が移ったことを示すものであり、別のGPU作業が速くなった証拠ではない。この試験では、NPUが生成した1024×768ピクセルの画面を物理ディスプレイに合わせて拡大表示しており、その処理には引き続きGPUが使われている。また、30Hzという数値はウィンドウの再描画を要求する頻度であり、実際の表示速度ではない。NPUによって合成され、画面に届いたフレームは計969枚で、平均すると毎秒約1.6枚だった。
GPU使用率とNPU使用率は、そもそも同じ仕事量を表す指標ではない。両者の数値を単純に差し引いて処理効率や省電力効果を求めることはできず、今回の試験でも、同等の画質とフレームレートを維持した状態で消費電力を比較した結果は示されていない。開発者自身も、ほかのGPU処理に振り向けられる計算資源が実際に増えたかどうかは実証できていないと評価している。
測定条件にも注意が必要だ。録画試験では、NPUでの処理が終了する約90秒前に物理画面がGPU表示へ戻る区間があった。また、復旧後のGPU使用率が開始前より低かったのは、再描画を行うウィンドウを元の位置に復元できなかったためと説明されている。これらの結果を踏まえると、現時点で確認できるのはGPUの処理負荷が一部移ったという事実までであり、実用的な性能向上や電力削減が得られるかは今後の検証を待つ必要がある。なお、表の数値は開発者の公開資料を整理したもので、すべての生ログを独立して検証した結果ではない。
実用化に向けた課題は表示速度だけではない
実用化に向けては、画面の応答性に加え、障害発生時の復旧も大きな課題となる。npu-renderには、利用者の操作や障害をきっかけに通常のGPU表示へ戻す仕組みが用意されており、最長40分間の安定動作も記録されている。しかし、アプリケーションを開いた状態で実施した復旧試験では、14件のウィンドウ配置のうち7件しか復元できず、操作対象となっていた最前面のウィンドウも元に戻らなかった。画面を再び表示できても、作業環境まで完全に復元できるわけではない。
また、スリープからの復帰についても未解決の問題が残る。通常のPCではスリープや復帰が頻繁に行われるため、表示経路の切り替えによってウィンドウ配置や作業状態が失われるようでは、日常的な利用は難しい。開発者はGPU表示への復旧機構を整備しているものの、表示を正常な状態へ戻すことと、利用者が作業を中断した場所からそのまま再開できることは区別して評価する必要がある。
導入のハードルも高い。npu-renderはApache License 2.0でソースコードが公開されているが、利用にはWindows 11と対応するIntel NPUのほか、テスト署名モードと管理者権限が必要になる。さらに、指定バージョンのOpenVINO SDKやWindows Driver Kit（WDK）、リポジトリでは再配布されていないSHAVEツールチェーンも求められる。問題が発生した場合、デスクトップを数分間操作できなくなる可能性があるため、一般ユーザー向けの導入を想定した段階にはない。OpenVINOのNPUプラグイン自体は複数世代のIntel NPUをサポートしているが、npu-renderがそれらすべてで動作検証されているわけでもない。
開発者がnpu-renderを「製品ではなく研究用プロトタイプ」と位置付けているように、今回の成果はWindowsのデスクトップ合成処理をNPUで実行し、実際の画面表示までつなぐ技術的な経路を実証した点にある。一方、更新速度は実用水準に達しておらず、GPUの負荷軽減による性能面・電力面のメリットも確認されていない。今後は、GPUと同等の画質や応答性を確保した条件での性能・消費電力比較に加え、障害やスリープからの復旧時に作業状態を正しく維持できるかが、実用性を判断する重要な指標となる。
