2019年1月には安定版のバージョン4.0がリリースされているが、それ以外のことについて、2018年11月から2019年3月にかけてのWine関係の幾つかのメモをここにまとめる。
- ProtonとWineのXAudio2の実装が外部ライブラリを用いたものに変更される
- ProtonでWineよりもパフォーマンスが改善したゲーム
- ウディタ作品のキーボードの矢印キー問題のパッチがStaging版に入る
- VulkanによるDirect3D(11以下)の実装に関係したメモ
ProtonとWineのXAudio2の実装が外部ライブラリを用いたものに変更される
2018年の12月、Linux版Steam上のWindows用ゲームの実行に使われる派生版Wine “Proton” の最新のベータ版では “XAudio2” のオーディオAPIが “FAudio” という完全に新しいSDL2上のクロスプラットフォーム実装を用いるように変更された。
GitHubで公開されていたテスト用リポジトリを2018年の11月に試したときには複数の大きな不具合(ウディタ作品などで音の再生の挙動がおかしかったり、ゲーム自体が突然操作不能になったりした)があったのだが、前者は報告の結果改善され、後者についてもProtonに採用された段階のものでは(少なくともウディタ作品では)安定している。
この変更により、FAudioで実装されているオーディオAPIの互換性が向上して挙動が改善されたり、幾つかのゲームなどでMicrosoftのDLLの使用が不要になったりといったメリットがもたらされる。
本家のWineについても、バージョン4.3でこの変更が取り込まれて古いOpenAL Softによる実装は取り除かれた(Wine内のOpenALのDLL自体はこれを直接使用するプログラムのために提供され続ける)。
Protonのバイナリはビルド済みのFAudioが同梱された形で配布されている(Steamクライアントのインストールが必要で、同クライアントからWindows用のゲームをインストールして実行すると自動的に導入される他、 “ライブラリ - ツール” から単体で入れることも可)が、このライブラリは安定版としてリリースされたのが2019年1月の “19.01” からとなっており、Wineの場合は外部ライブラリとしてのFAudioに依存するため、ディストリのパッケージが整備されるまでは導入が面倒な状況となりそう。
ProtonでWineよりもパフォーマンスが改善したゲーム
前述のProtonは本家Wineと方向性の違いのある修正であってもゲームの動作に良い影響(動作速度の改善など)のあるものは積極的に取り込んでいるが、手元でProtonを試して本家Wineとの動作速度に違いが出たゲームとしては、DXVKによるものを除くとRPGツクールVX(無印)作品の動作がWineの4.0.x系より軽い(CPU使用率がそれなりに下がる)ということが判明した程度にとどまった。
なお、試した時点のProtonは4.0.x系や4.x系と比べて古いWineから派生しているものなので、この動作速度の違いがProton固有の変更によるものかどうかの正確なところは不明。
Proton固有の変更としてよく取り上げられるものとして “esync” と呼ばれるパッチ群があり、マルチスレッドのプログラムでCPUがネックになっている場合に動作速度を向上させるものとされるが、Wine 4.0にパッチを当てたもの(環境変数WINEESYNCを1にして実行する)と未パッチのものとを比較したところ、RPGツクールVX作品では目立った差はなく、Protonよりは遅かったため、前述の動作速度改善はProtonにのみ適用されている別のパッチによるものと考えられる。念のためにesyncの作者のリポジトリから2018年11月のパッチ適用済みのWineのソースツリーを取得したものでも試したが、結果は同じだった。
esync自体については “有効時と無効時のパフォーマンス比較” の類の複数の動画が動画サイトで見つかったが、フレームレートの微増など、ゲームによっては動作速度向上の効果は確かにあるようだ。
このパッチ群はパッチ作者のリポジトリからダウンロードできる。
ProtonのWine部分のソースツリーを調べたところ、eece6bbの修正がRPGツクールVX作品のCPU使用率を下げたことが判明し、この修正をWine 4.0のソースに適用したときに効果があることも確認した。これはCLOCK_MONOTONIC_RAWを指定した経過時間取得処理が低速なため、CLOCK_MONOTONICを代わりに用いることで速度低下を防ぐというもので、CLOCK_MONOTONIC_RAWを用いるWineとの微妙な内部的な挙動の違いが出るが、動作速度の差が大きいためにProtonにこの修正が入ったものと考えられる(修正のやり方が綺麗ではないため、このままの形でのWineへの採用はされにくいと思われる)。ただ、これは標準Cライブラリやカーネルの実装とも関わるため、それらの組み合わせやバージョンによっては動作速度およびその変化のしかたに違いが出る可能性もある。なお、試したときの環境はx86_64版のUbuntu 18.10(カーネルは4.18系で、Cライブラリはglibc 2.28系)。
(2019/3/7)どの変更が関係しているかの詳細を追記
ウディタ作品のキーボードの矢印キー問題のパッチがStaging版に入る
以前書いた “ゲームパッド接続時に矢印キーが利かない不具合” に対する修正は、仮パッチの作者がメーリングリストにこれを出していないためにこれまで取り込まれることがなかったが、2019年2月に突然Wine Stagingのパッチの1つとして取り込まれることになった。Stagingに入ったからといって公式版に入るかは分からない(ずっとStagingに入ったままのパッチもあるため)が、配布されるバイナリで動作が確認できる形になって少しは状況が良くなった。
VulkanによるDirect3D(11以下)の実装に関係したメモ
Wine独自の実装についての情報が明かされる
2019年1月、Wineのメーリングリストにて、Wine内のDirect3D(11以下)の新しい実装としてVulkanを用いたものが開発されていることが明かされた。これが完成すれば、Vulkan対応GPUを搭載したPCでGNU/Linux上のDirect3Dアプリケーションがこれまでより高速に動作したりCPU使用率が下がったりすることが期待できる。
VK9は2019年からに期待?
既に完成度の高いDXVK(Direct3D 11とDirect3D 10をVulkanで実装した外部プロジェクト)に対して、VulkanによるDirect3D 9実装のVK9は自分にとってはまだ実用段階ではないと考えていた。その主な理由としてIDirect3D9Exが未実装というのがあり、古いウディタ作品などではまだ使えない。
そのEx系APIの部分的な実装の動きが2018年末から始まり、本記事公開時点ではこの変更がリリース版のバイナリにまだ含まれていないことや自分でビルドするのには依存ライブラリの関係で非常に手間がかかることなどから、実際に試せてはいないものの、今後それらが動くようになる第一歩として期待ができる。
また、VK9のロードマップは以前から公開されているが、計画されていた機能実装が2019年で一通り完了しそうなのも、今後期待できる理由となる。
前述の “本家WineにおけるVulkanによるDirect3D実装について” の情報に対して、VK9の作者は “こちらは余った時間で少しずつ開発しているのに、向こうが複数人のフルタイム開発者でやられたら敵わない・プロジェクトが必要とされなくなったら中止する” との姿勢を示したが、個人的には “動かしたいプログラムがWine側の実装でうまく動かない場合のために選択肢は多いほうがよい” と考えており、DXVKや後述のd3vkも含めて本家Wineでの実装が出来上がった後も開発の継続を希望する。
DXVKの派生版がDirect3D 9をサポートする?
既に完成度の高いDXVKのプログラム基盤を利用してDirect3D 9を実装することを目指してDXUPの作者が “d9vk” の開発を開始した。開始時期が(前述の情報が公開されたより後の)2019年2月なので、今後の開発の継続についての心配はあまりないが、まだ3月上旬の時点では実装初期で、いつ頃から実用段階になるのかは分からない。DXVKの基盤が既にあるため、どこかで突然VK9を追い越して実用段階に達してしまう可能性もある。
名前は別だがDXVKのソースツリーを派生した形で開発されており、場合によっては将来DXVKの一部(d3d9.dllに相当する部分)となるかもしれないし、仮にそうなればProtonからも利用可能となるかもしれない。
