ハクソク

世界を動かす技術を、日本語で。

Wine 11がLinux上でWindowsゲームをカーネルレベルで動作させる方法を刷新し、大幅な速度向上を実現

45日前原文(xda-developers.com)

概要

  • Linuxゲーム環境の進化とWine 11の大規模アップデート
  • NTSYNCによるカーネルレベルの同期処理の実現
  • WoW64アーキテクチャの完成で32bitアプリの互換性向上
  • Waylandドライバやグラフィック関連の多彩な改善
  • Wine 11がもたらす幅広いユーザー体験の向上

Linuxゲーミングの進化とWine 11の登場

  • ValveのProton登場 （2018年）以降、Linuxでのゲーム体験が大幅に向上
  • Wineのバージョンアップ （Wine 10、Wine 9など）で互換性とパフォーマンスが徐々に改善
  • Wine 11 は従来のアップデートとは異なり、NTSYNCやWoW64完成など根本的な刷新
  • Waylandドライバの成長 や細かな改善点も多数搭載
  • ProtonやSteamOS などの下流プロジェクトにも恩恵が波及

これまでの同期処理の課題とNTSYNCの意義

  • esyncやfsync はWineやProtonの設定でよく見かけるワークアラウンド
  • Windowsゲーム はマルチスレッド処理が主流で、同期処理が重要
  • 従来のWine はwineserverを介したRPCで同期を実現し、オーバーヘッドやパフォーマンス低下の原因
  • esync はeventfdを利用した改善策だが、ファイルディスクリプタの上限問題あり
  • fsync はfutexを活用し高速化したが、カスタムカーネルが必要で一般ユーザーには敷居が高かった
  • esyncやfsyncは本質的にはワークアラウンド で、WindowsのNT同期動作を完全には再現できなかった

NTSYNCによるカーネルレベル同期の実現

  • NTSYNC は独自のカーネルドライバによるWindows NT同期APIの実装
  • /dev/ntsyncデバイス を介してWineがカーネルと直接通信
  • wineserver不要・正確な同期動作・カーネル内での処理 が可能
  • Elizabeth Figura （esync・fsync開発者）が長年取り組み、Linux 6.14でメインラインに統合
  • パフォーマンス向上例
    • Dirt 3：110.6 FPS → 860.7 FPS（678%向上）
    • Resident Evil 2：26 FPS → 77 FPS
    • Call of Juarez：99.8 FPS → 224.1 FPS
    • Tiny Tina's Wonderlands：130 FPS → 360 FPS
  • fsync使用時との違い
    • fsync利用者は劇的な向上は限定的
    • NTSYNCは特に多スレッド同期がボトルネックなゲームで効果大
  • カーネル6.14以降のディストリビューション （Fedora 42、Ubuntu 25.04など）で標準対応
  • SteamOSやProton GEでもサポート開始
    • Valve公式ProtonがWine 11にリベースされれば、Steam Deck全ユーザーが恩恵を受ける

WoW64アーキテクチャの完成

  • WoW64 （Windows 32-bit on Windows 64-bit）のWine実装がついに完成
  • 32bitアプリ実行時に32bitシステムライブラリ不要
  • Wineが内部で32/64bitを自動判別し、単一バイナリで処理
  • マルチリブパッケージや32bit依存関係の煩雑な設定が不要
  • OpenGLメモリマッピングやSCSIパススルー、16bitアプリ対応も実現
  • レトロゲームや古い業務ソフトの動作性向上

Wine 11のその他の改善点

  • Waylandドライバの強化
    • クリップボードの双方向連携
    • WaylandアプリからWineウィンドウへのドラッグ&ドロップ対応
    • 低解像度切り替え時の表示崩れ対策
  • グラフィック面の強化
    • X11でのOpenGLレンダリングにEGLをデフォルト採用
    • Vulkan API 1.4対応
    • Direct3D 11経由でのH.264ハードウェアデコード初期サポート
  • 周辺機器・音楽・システム面の改善
    • レーシングホイールやフライトスティックのフォースフィードバック対応強化
    • Bluetooth BLEサービス対応・ペアリング改善
    • MIDIサウンドフォント管理強化
    • Zip64圧縮、Unicode 17.0.0、TWAIN 2.0、IPv6 pingなどの新機能追加
    • Linux/macOSでのスレッド優先度管理強化
    • ARM64での4Kページサイズエミュレーション

まとめ：Wine 11の意義

  • NTSYNCとWoW64の実装完了 により、Linux上のWindowsアプリ・ゲーム互換性が飛躍的に向上
  • パフォーマンス・安定性・使い勝手 の全方位的な進化
  • ProtonやSteamOSを通じて、すべてのLinuxゲーマーに恩恵
  • 今後のLinuxゲーミングの新たな基盤 として期待

Hackerたちの意見

Wineって、なんか逆効果な気がする。Linuxのゲームサポートが広がると、デスクトップとしてのLinuxの可能性が高まって、市場シェアも増える。それが開発者にLinux用のポートを作らせるかもしれないけど、それはWineなしで動くものになるかもね。

└

これこそ「持ってて嬉しい問題」の定義だね。

└

WineのAPIはLinuxのAPIより安定してるから、Wineが第一級のターゲットになるのもあり得ると思う。

└

自分自身への解決策

└

実際、逆になると思う。ネイティブポートがあるゲームでも、私はほとんどいつもProtonでWindows版を動かしてる。そっちの方が安定してるからね。みんなWindows APIに対して開発するのは、馴染みがあって変わらないからで、それでいいと思う。Protonがそれをうまく動かしてくれるし。

└

ゲームやアプリがWineで動くなら、Linuxポートを開発するプレッシャーが減るんじゃない？

└

逆に静かだね。Wineが良いと、ゲームスタジオがネイティブLinuxポートを作るインセンティブが減っちゃうんだよね。

└

なんとかしてそこにたどり着かなきゃ。

└

Windows APIが事実上のLinuxゲームSDKになる可能性が高い気がする。ゲームをLinuxに移植するアイデア自体が意味を持たなくなるかもね。

└

もし自分にとって重要なすべてのWindowsアプリがWineで動くって保証があったら、次の日には切り替えるよ。今はWindowsを使って、ビジネスバックエンドがLinuxのアプリも開発してる。

└

これは大きな懸念じゃないと思う。Linuxネイティブのゲームがそこそこ揃っても、Wineの需要はまだまだあるだろうし。人々はゲーム以外の目的でもWineを使ってるし、もし明日すべての新しいゲームがネイティブLinux版になったとしても、少なくともあと20年は古いWindows専用ゲームをプレイし続けると思う。あと、WindowsのABIはLinuxのABIよりもまだ安定してるしね。Linux（非SteamDeck）のゲームシェアが50％以上になったとしても、Windows専用で開発する方が手間が少ないだろうし、Linux+Wineでのパフォーマンス差は大したことないから。

こういう投稿を読むと、いつも自分が偽物みたいに感じる。みんなはすごく低レベルなことに取り組んでるのに、私はここでシンプルなCRUDを作ってるだけ。

└

レイヤーを一つずつ理解していこう！普通の仕事から、難解な低レベルの実装の一部を理解するのは、すごくやりがいがあるよ。一度に一つのレベルで、そんなに悪くないけど、確かに難しいし努力がいる。私もほとんど何も知らないけど、数年前に同じように感じてたから、今はこういう投稿を見ると、ただ怖がるんじゃなくてワクワクするようになった。

└

いいよ。私は人にOutlookに別のメールボックスを追加する方法を教えてる、「ここをクリックして、次はあそこ」って。華やかじゃないけど、必要なことだしね。

└

みんながそんな低レベルのことを扱ってる間、私はここでシンプルなCRUDを作ってる。CRUDは生活費を稼いでくれるからね。

└

隣の芝生はいつも青いって言うけど、低レベルのプログラマーはCRUDアプリみたいな高レベルのシステムに関しては自分が詐欺師みたいに感じることが多いんだよね。

└

これらのことも、やる気があれば学べると思うけど、自分を過小評価しないでね。CRUDアプリは見た目以上に複雑になることもあるから。ビジネスは、やってることが分からないと自分のアーキテクチャを完全に無効にするような要件を出してくるからね。

└

このレベルのシステムで働いてる者として言わせてもらうけど、これは学べるスキルだよ。知識が必要ないこともあるけど、高いレベルで物事がどう進んでいくのかを理解するのは、知的にも価値があると思う。お金がもっと目的だったら、CRUDアプリも作ってたかもしれないけど、俺は変なパズルが好きなんだよねXD。

└

自分はコンパイラの仕事をしていて、個人プロジェクトのためにフルスタックのCRUDアプリを作ろうと何度も挑戦してきた（Rails、Phoenix、Djangoでやってみたこともある）。クロードの助けを借りてやっと進展があったけど、これは本当に独自のスキルセットなんだよね。始めるのは簡単だけど、うまくやるのは難しい。

└

一方で、仕事の市場がひどいから、こういうプロジェクトに自分が望むように貢献する時間がないんだよね。

└

同感。リアルなエンジニアに比べると、自分は配管工みたいなもんだ。

└

CRUDは価値があるだけじゃなくて、メンタルにもいいよね。ドットコム時代に知ってたやつがいて、すごいスキルのあるコーダーだったんだ。会社の中核を担ってた。奇跡を起こして、不可能な締切を守ってた。でもある日、突然辞めちゃった。技術系じゃない会社に転職して、キュービクルで8時5時のスケジュールでVisual BasicのCRUDを書いてた。変な締切もなくて、机の下で寝ることもなくなった。彼はそれを「有給休暇」って呼んでたよ。

Dirt 3は110.6 FPSから860.7 FPSに > Resident Evil 2は26 FPSから77 FPSにジャンプ > Call of Juarezは99.8 FPSから224.1 FPSに > Tiny Tina's Wonderlandsは130 FPSから360 FPSにアップした。すごいね。こんなに大きな速度向上がどうして可能だったのかはよくわからないけど、歓迎するよ！ValveがProtonにお金を注ぎ込んでくれてありがとうって感じかな。

└

そのベンチマークの数字は少し誤解を招くかも。Wine+ntsyncとWine+nothingの比較だからね。Linuxのfutexを使った「fsync」ライブラリが比較的早く作られていて、Wine+fsyncに対する向上は控えめ（ほとんどの場合数パーセント）だよ。それでも、Wine+ntsyncは勝利だけど、Dirt 3のベンチマークが示すような8倍の改善ではないよ。（もしわからなければ、ntsyncはhttps://docs.kernel.org/userspace-api/ntsync.htmlで、Windowsのプリミティブにより近い同期プリミティブ（ミューテックス、セマフォ、イベント）を提供するLinux用のドライバだよ。Windows用にコンパイルされたコードをサポートするためにWineで直接実装するのが簡単になるんだ。）

└
  • esyncやfsyncを使っていない場合

Wineには本当に無限大のリスペクトを持ってる。確かではないけど、Wineの作業は退屈で感謝されないことが多いんじゃないかな。過去30年間のWindowsのドキュメント化された挙動とされていない挙動を正確に再現しようとするのは楽しそうじゃないけど、ちょっとした変なケースを見つけることがWineを実用的な製品にしてるんだよね。今ではWineが多くのゲームをWindowsよりも良く動かしてる（特に古いゲーム）っていうのは、細部に対する強い注意と高い耐性を示してる。彼らには拍手を送りたい。

└

ReactOSも名誉ある言及に値するね。そのプロジェクトからの知識がWineに大いに活かされてるんだ。

└

Wineには、互換性をチェックするためにプラットフォーム間で実行されるテストがたくさんあるんだよね。これが良い互換性を持つ大きな理由の一部なんだ。

└

エリザベスがやったことを、1ヶ月も続ける根気は自分にはないな、ましてや何年もなんて。ほんとにすごいよね。

└

そうだね、Wineは本当に奇跡だよ。Officeの完全サポートが実現したら、Linuxの普及が一気に進むと思う。

誰かがntsyncについてあまり興奮しないように言っておくけど、パフォーマンス向上は（例外はあるけど）控えめで、通常は1桁のパーセンテージの範囲だよ。この極端な向上は、fsyncなしのバニラWineとベンチマークを取った結果で、Linuxで要求の厳しいゲームをプレイしている人はfsyncを使っているはず。この記事でも触れられているけど、サイドノートのように扱われてる。両者のベンチマークを取ってみたけど、パフォーマンスの向上は確かにあるけど、期待は控えめにしてね。いくつかのタイトルは少し悪化するかもしれない。

└

この極端な向上はfsyncなしのバニラとベンチマークを取った結果で、Linuxでゲームをしている人はみんなこれを使ってる。これらのパッチなしのカーネルを使っている人には当てはまらないよ。ほとんどの人がそうだろうけど。

これってすごい成果だよね！LinuxがWindowsを再実装して、しかもそれをより良くやってるのを見るのは本当に驚きだわ。一方でMSは自社のソフトをどんどん悪化させようとしてるし。

└

ここでのフル16ビットサポートは大きなポイントだよ。64ビットWindows（今やどこにでもある）がそれを捨てちゃったからね。古いゲームには16ビットのものが何千もあって、32ビットのゲームでもインストーラーが16ビットっていう変なケースもあるし。

ユーザースペースで共有メモリを使ってデータ構造を保存し、スレッドごとに1つのeventfdを使ってパーク/アンパーク（他に待ってないならfutexを使う）する実装が可能そうだね。これなら完全に正しいし、似たようなかそれ以上のパフォーマンスが出るはずだけど、プロセスのクラッシュに対してはセキュアでもロバストでもないっていうコストがある（でもWineの使用が多いなら大した問題じゃない）。でも、esyncやfsyncはこれをやってないみたいだけど、なんでだろう？クロードは「95%のゲームで簡単な（でも正確ではない）アプローチがうまくいったから、複雑な共有メモリのウェイターリストロジックを書く動機が誰にもなかったし、正確さが重要になったときにはカーネルがより自然な場所だった」と考えてるけど、これって本当？

└

技術的な詳細はわからないけど、カーネルのドキュメントには「ユーザースペースでの実装は、既存のツールを使っても、正確なセマンティクスを提供しながらWindowsのパフォーマンスには及ばないから存在する」って書いてあるよ。 https://docs.kernel.org/userspace-api/ntsync.html

何年もValve Corporationに何千ドルも寄付してきたけど、その一部がみんなのためにWineの改善に使われてるって嬉しいな。プロジェクトに関わってる開発者や契約者は、Valveからどれくらいお金もらってるんだろう？

NTスタイルとPOSIXスタイルのセマフォの違いって、要はNT（と今のLinuxの新しいAPI）が最大値を設定できるってことだけなの？なんでPOSIXセマフォはこれをサポートしてないの？

WoW64の仕組みに関する技術的なメモに興味があるなら、Wineを掘り下げて、（かなり劣る）エミュレーターに似たようなことを実装して、ここに書いたよ。Wineのリソースへのリンクもいくつか載せてる： https://neugierig.org/software/blog/2023/08/x86-x64-aarch64....