Linuxゲームが速くなるのはNTSYNCがWindowsの待ち合わせをカーネルで処理するから
目次
Windows向けゲームをLinuxで動かすとき、重いのはDirectXからVulkanへの変換だけではない。
ゲーム内のスレッドが「この処理が終わるまで待つ」「複数のイベントのどれかを待つ」といった同期処理を大量に投げると、WineやProtonはWindows NTの待ち合わせの意味をLinux上で再現しなければならない。
XDAの「Linux gaming is getting faster because Windows APIs are becoming Linux kernel features」は、この流れをNTSYNC中心に取り上げていた。
表現としては「Windows APIがLinuxカーネル機能になっていく」だが、実際に見ているのはWindowsそのものの移植ではなく、Wine/Protonが苦労していた同期プリミティブをLinuxカーネル側に持ち込んでいる。
NTSYNCは汎用同期APIではなくWine向けの互換部品
LinuxカーネルのNTSYNCドキュメントは、用途をかなりはっきり書いている。
NTSYNCはユーザースペースのNTエミュレータがNT同期プリミティブを再現するための支援ドライバで、既存のユーザースペース実装ではWindows並みの性能と正確な意味を両立しにくい、という位置づけだ。
一般アプリの同期に使うものではなく、通常は futex(2) や poll(2) を使えとも明記されている。
ここでいう同期プリミティブは、セマフォ、ミューテックス、イベント。
Windowsゲームが内部で使う WaitForMultipleObjects 系の待ち合わせを、Wine側がLinuxの普通の仕組みだけで似せようとすると、コンテキストスイッチやwineserver経由の処理が増えやすい。
NTSYNCでは /dev/ntsync というキャラクタデバイスを通じて、WineがNT風の同期オブジェクトをカーネル側に持てる。
この手の「カーネル側の挙動がアプリの速度を変える」話は、サーバーでも普通に起きる。
以前書いた Linuxカーネル7.0のPREEMPT_NONE廃止でPostgreSQLスループット半減 は、スケジューラの変更でPostgreSQLのロック待ちが悪化した例だった。
NTSYNCは逆方向で、Windowsゲームが期待する待ち合わせに近い形をカーネル側へ持ち込んで、Wine/Protonの迂回を減らす。
Linux 6.14でカーネル側、Wine 11.0でユーザースペース側がそろった
NTSYNCのカーネル側はLinux 6.14で「実用できる状態」になった。
Kernel NewbiesのLinux 6.14まとめでも、目立つ機能として「NT synchronization primitive driver for faster games」が挙げられている。
Phoronixの記事では、6.13に入っていた枠組みが6.14で有効化され、SteamOS利用者に効くはずだというGreg Kroah-Hartmanのコメントも紹介されていた。
ただ、カーネルだけ新しくしてもゲームが勝手に速くなるわけではない。
Wine/Proton側がNTSYNCを使うビルドになっている必要がある。
Wine 11.0の公式リリースは、主な変更点としてNTSYNC対応と新しいWoW64アーキテクチャの完了を挙げている。
LWNもWine 11.0の変更点として、利用可能な場合にNTSync Linux kernel moduleを使う点を取り上げていた。
Steam側では、ValveのProton 11.0 betaが2026年4月に出ている。
GitHubのリリースノートを見ると、beta1はWine 11.0ベースへ更新され、beta3が2026年5月13日に出ている。
つまり2026年5月14日時点では、安定版Protonだけ見て「NTSYNC対応済み」と決め打ちするより、Proton 11 betaやProton Experimental、ディストリビューション側のProton派生ビルドまで確認する段階だ。
速くなるタイトルは同期待ちで詰まっていたゲーム
NTSYNCで大きく変わるのは、GPUが遅いゲームではなく、Windows式のスレッド同期で詰まっていたゲームだ。
平均FPSだけを見ても差が見えにくい場合がある。
フレーム時間のばらつき、入力遅延、ロード中やムービー後のスタッターのほうが変化として出やすい。
「最大で数倍速い」という数字だけ拾うと誤読しやすい。
過去のNTSYNCベンチは、素のWineと比較して大きな改善を示すものが多かった。
すでにesyncやfsyncで回避していた環境、GPUがボトルネックの環境、ゲーム側があまりWindows同期に依存しない環境では、差は小さくなる。
逆に、古めのWindowsゲームやマルチスレッド処理が雑なタイトルでは、同期の再現精度そのものが互換性を左右する。
Proton 11 betaのリリースノートでは、Resident Evil、Dino Crisis、SHOGUN: Total War、Deadly Premonitionなど、古いタイトルも新たに動作対象へ入っている。
これらすべてがNTSYNCだけの成果とは言えないが、ProtonがWine 11.0へ移ったタイミングで、同期、WoW64、DXVK、vkd3d-proton、ランチャー対応がまとめて進んだ。
手元で見るなら/dev/ntsyncとProtonの版を分けて見る
Linuxゲーム環境で確認するなら、最初にカーネルとデバイスをチェックする。
uname -r
ls -l /dev/ntsync
modinfo ntsync/dev/ntsync がなければ、カーネルにNTSYNCが入っていないか、モジュールがロードされていない。
ディストリビューションによってはWineやSteamパッケージの導入時に自動ロードされるよう調整されるが、常にそうとは限らない。
次にWine/Proton側を確認する。
Wineなら wine --version だけでなく、そのパッケージがNTSYNC有効でビルドされているかが問題になる。
ProtonならSteamの互換ツールでProton 11 betaを選んだのか、Proton 10系やExperimentalを選んだのかを分けて記録する。
計測は平均FPSだけでは足りない。
MangoHudやGamescopeのフレーム時間ログを取り、同じセーブデータ、同じ場所、同じ描画設定でProton 10系と11 betaを比べる。
GPU使用率が常に張り付いているタイトルなら、NTSYNCの差は出ない。
CPU側に余裕がない、フレーム時間に細かい山が出る、ロード直後に引っかかる、そういうタイトルのほうが差が見えやすい。
ゲームをSteamで配る側の話なら、Steamアーリーアクセス公開ガイドでSteamPipeやデポ管理を別にまとめている。
今回のNTSYNCは配信設定ではなく、ユーザーがLinuxやSteamOSでWindowsビルドを実行したときの互換レイヤー側の変化だ。
Windows版だけを出していても、Proton側の改善でSteam DeckやLinuxユーザーの体験が変わることがある。
ふと気になったのが、Godot EngineでWindows専用にコンパイルした実行ファイルをSteamに出したとき、Proton経由でどこまで動くのか。
Linux向けにビルドし直せばいい話ではある。ただ、Steam Deckはでかすぎるし、Windows搭載ハンドヘルドは選択肢が限られる。
Android系のハンドヘルドにUbuntuを入れて小型Linuxゲーム機にする場合、NTSYNCが有効なカーネルとProton 11の組み合わせでWindows専用ビルドがそこそこ動くなら、わざわざLinux向けにビルドし直さなくてもいいかもしれない。