ゲーム

提供: ArchWiki
2024年3月8日 (金) 19:36時点におけるAshMyzk (トーク | 投稿記録)による版 (→‎周辺機器: 同期)
ナビゲーションに移動 検索に移動

関連記事

Linux は長らく「非公式」のゲーミングプラットフォームと見なされてきました。ほとんどのゲーミング関連組織にとって、Linux へのサポートと Linux のターゲットユーザーは最優先事項ではありません。しかし、2021年以降、この状況に変化が現れ始めました。Valve などの大企業、CodeWeavers グループ、そしてコミュニティが、Linux エコシステムに多くの改善を行い、Linux が真にゲーム用として利用可能なプラットフォームになることが可能になりました。さらに、Linux 上でもゲームをコンパイルし実行できるようにするためにクロスプラットフォームのレンダリングエンジンに移行するインディーゲーム開発者が増えつつあります。

ゲームプレイに関して言えば、ユーザーの考えの大部分は、Microsoft Windows プラットフォーム専用に開発された人気のある AAA ゲームに向けられることがよくあります。これは理解できますが、Windows が唯一プレイ可能な環境であるわけではありません。このページのさらに下にある #ゲーム環境 と #ゲームの取得 章を見てください。これらの章では、他のプラットフォーム上でゲームを実行するためのソフトウェアが挙げられています。

しかし、Microsoft Windows 向けに書かれたゲームを Linux で動作させることに執着している場合は、別の考え方、ツール、およびアプローチが必要で、内部についての理解と機能の代替が必要になることがあります。以下の #ゲームの技術的情報 を読んでください。

目次

ゲームの技術的情報

Windows 用に開発された AAA ゲームを Linux 上でプレイしようとすると、最終的に3つの複雑な問題が立ち塞がります:

グラフィックス SDK
Linux が認識できない API (DirectX など) 用に開発されコンパイルされたゲーム。
汎用ライブラリの依存関係
ゲーム内でのセーブ、設定ファイルの読み込みなど、ゲームプレイ中に行うであろう一般的な操作に必要なライブラリ (例: Microsoft Visual C++、MFC、.NET)。
互換性のないインターフェイス
上記のフレームワークとは別に、Linux が認識できない、Windows によって生成されたバイナリフォーマットやコンパイル済みコードによる問題もあります。

グラフィックス SDK は、グラフィックの呼び出しを基底のグラフィックドライバに転送し、グラフィックドライバは GPU ハードウェアと対話します。

DirectX をメインの SDK として使用しているゲームは数多くあります。一方、Linux は OpenGL と Vulkan しかネイティブにサポートしていません。Linux それ自体は DirectX も前述の技術 (Visual C++、MFC、.NET) もサポートしていません。

代わりに、同一の機能を提供し、最終的にはグラフィックの観点から同一の結果を達成することを試みるオープンソースの代替ソフトウェアがいくつか存在します。これらには、ブラックボックスの観点から、オリジナルの SDK 呼び出しによって行われるであろう結果を「再発明」することを試みる独自の代替実装が含まれています。人気なものとしては以下があります:

  • Wine (Wine Is Not an Emulator): "ローダー VM"、依存関係の自己記述、相互運用性などを提供します
  • Proton: Wine プロジェクトからフォークされました。Valve の Steam 用に最適化されています。
  • Mono: .NET の代替
  • MF-Media: media foundation の依存関係

例えば、DirectX における頂点の読み込み、変換、シェーディングの呼び出しは、Wine の新しい .dll/.so でゼロから書き直され、その関数が水面下で何を行うかについての"仮説"に基づいて呼び出しを OpenGL に転送して、実質同じ結果を達成することを試みるかもしれません。これらの呼び出しは直接的には同じであり、DirectX が実行されているかのように扱われ、パフォーマスには影響しません (ただし、これらと対話する際の初期オーバーヘッドを除く)。

しばしば、これらのツールは同時にシステム上のディストリビューションに組み込まれます。prefix (Wine 用語で、Windows サンドボックスを模倣するディレクトリを指す) が作成・設定された後、依存関係は prefix 内にインストールされ ("サンドボックス"はゲームの再配布可能ライブラリが依然として必要です)、しばしば winetricks もインストールされます。その後、まるで Windows 内であるかのように、ゲームの実行を試みます。

最近では、この方法はほとんどのゲームでうまく行きます (Wine/Proton にはまだ存在しないカーネルドライバが必要なアンチチートで保護されているゲームを除いて)。ゲームが動作しない場合、通常は、互換性のないパッケージや不足している依存関係、Wine/Proton の未実装の機能が原因です。

Lutris は、ゲームをインストールする際に、依存関係を管理してくれるランナーとサンドボックスを提供するソフトウェアです。上記の手順が退屈または複雑と感じる場合に便利です。

ゲームの一般的な依存関係

Wine/Proton を使用する場合、どのようなことをしなければならないか、より深く理解するために、ゲームを実行するために必要となる一般的な依存関係を説明します。アーキテクチャについても、x86 か x64 か、できれば両方か、ということを念頭に置く必要があります。

ほとんどの Windows ゲームでは、以下の依存関係を prefix にインストールする必要があるでしょう。

必須 (広く使用されている)

  • Microsoft Core フォント
  • Microsoft Visual C++ 2015 (2017 が広く使用されているので、推奨) [2005、2008、2010、2012、2013、2015、2017-2018、2019]
  • DirectX 9.0 (11.0 が広く使用されているので、推奨) [June SDK update 2010] {いくつかのコンポーネントの例を挙げると:}
    • Direct3D
    • Direct2D
    • DirectShow
    • DirectInput
    • DirectPlay
    • DirectSound
    • DXGI
    • XAudio2
  • .NET Framework (3.5 がよく使用されます)
  • OpenGL
    • OpenAL
    • OpenAI
    • OpenCL
  • Vulkan

任意 (しかし、よく使われている)

  • XNA
  • PhysX
  • Media Foundation
  • Quicktime
  • Adobe Reader 11
  • Java SRE (Minecraft などで)

稀 (あまり一般的でない)

  • Gamespy
  • MIDI driver
  • ACDSee

マシン要件

ゲームが必要とする依存関係をプレフィックスに入れるだけでは十分ではありません。カーネルそのものが、ゲームが行う呼び出しに対応する代替が必要です。すでに述べたように、ドライバと代替品が利用可能です。

ドライバー

  • AMD ドライバー: AMDGPU を参照。
  • Intel ドライバー: Intel graphics を参照。
  • NVIDIA ドライバー: NVIDIA を参照。

マシンと代替品への依存性

ノート: 以下の情報は参考程度です。これらのパッケージの一部は、主要なパッケージをインストールした際に一緒にインストールされます。
  • Wine
  • wine-gecko
  • wine-mono
  • Vulkan
  • OpenGL
  • Proton 再配布可能パッケージ (オプションですが、役立つ場合があります)
  • wine-ge-customAUR または TKG (オプション。失敗しないかぎり) : 特定のゲームのパッチを含む、特別にコンパイルされた wine バージョン。

ゲーム環境

Linux でゲームを遊ぶための環境は様々なものが存在します:

  • ネイティブ – Linux 向けに書かれたゲーム (大抵はフリーでオープンソース)。
  • ブラウザ – この種のゲームをプレイするのに必要なのはブラウザとインターネット接続だけです。
    • プラグインベース – 遊ぶためにはプラグインのインストールが必要です。
      • Java Webstart – クロスプラットフォームのゲームを簡単にインストールするのに使われます。
      • Flash ゲームはウェブ上で最も一般的なゲームです。
    • HTML 5 によるゲームは新しい canvas と WebGL テクノロジーを使います。全てのモダンブラウザで動作しますがマシンの性能が低いと実行が非常に遅くなります。
  • 専用環境 (ソフトウェアエミュレータ) – 他のアーキテクチャや環境のために作られたソフトウェアを実行するのに必要です (あなたの国の著作権法に注意)。詳しくはエミュレータのリストを見て下さい。
    • Wine – 膨大な Windows ソフトウェアだけでなく、Windows のゲームの実行も可能にします。Wine ではゲームのパフォーマンスが下がらないため (むしろ高速に動作することもあります)、Windows で動作するシステム要件が低いゲームならば大抵は Wine でも動作します。ゲームごとの互換性の情報は Wine AppDB を見て下さい。
    • Crossover Games – Codeweavers チームのメンバーは Wine の主要なサポーターです。Crossover Games を使うことでゲームのインストールや設定を楽にしたり、他の方法を使うのと比べて信頼性を高めたりすることができます。Crossover は有料の市販品ですが、開発者がコミュニティと対話できるように フォーラム が用意されています。
    • DosBox – DOS エミュレータ。古典的な DOS タイトルを動かすのに使われます。
    • scummvm – 多数のクラシックなアドベンチャーゲームで使われていた SCUMM ゲームエンジンのゲームをエミュレートします。対応タイトルの完全なリストは ScummVM ウェブサイト を見て下さい。
  • ハードウェアエミュレータ – ソフトウェア環境ではなくデバイス全体をエミュレートします。著作権については同じです。仮想マシンを使うことで Windows 専用のゲームを遊ぶことができます。VirtualBox は 3D もサポートしています。Windows の KVM ゲストから OVMF による PCI パススルーによって直接ハードウェアを利用することも可能です。

ゲームの互換性

vm.max_map_count を増やす

デフォルトでは vm.max_map_count サイズ制限は 65530 となっていますが、一部のゲームにおいては小さすぎる可能性があります [1]。なので、以下のような sysctl 設定ファイルを作成してサイズを永続的に大きくしておきましょう: 

/etc/sysctl.d/80-gamecompatibility.conf
vm.max_map_count = 2147483642

再起動せずに変更を適用するには、以下を実行してください: 

# sysctl --system
ノート: これにより、コアダンプファイルを読み込もうとする古いプログラムとの互換性が壊れる可能性があります [2]。

ゲームの取得

ネイティブ

公式リポジトリや AUR からかなりの数が入手できます。Loki はいくつかのゲームのインストーラーを提供しています。

デジタル配信

  • Desura — インディーゲームに特化したデジタル配信プラットフォーム。豊富なゲームがあると考えてよいでしょう (セキュリティやバグがあまり気にならないならば)。
http://www.desura.com/ || desuraAUR[リンク切れ: パッケージが存在しません]
  • Steam — Valve によって開発されている著名なデジタル配信とコミュニケーションのプラットフォーム。最近 Linux に (開発会社によって) 移植された有名ゲームが揃っています。Source (Half-Life 2) や Goldsource (HL1) エンジンのゲーム, Serious Sam 3, Brutal Legend, 多数の Humble Bundles のゲームやその他のインディータイトルなどを含んだ巨大なライブラリが存在します。
https://store.steampowered.com || steam
  • lgogdownloaderAUR パッケージを使うことでコマンドラインから GOG タイトルをダウンロードすることができます。
  • GOG.com が公式でサポートしているのは Ubuntu と Linux Mint だけです。サポートを求めるときはこのことを覚えておきましょう。たとえ Arch でゲームが動かせなかったとしても返金してもらうことはできません。
  • ほとんどの GOG.com タイトルは DOSBox, ScummVM, Wine によってパッケージ化されています。

Java

Wine

  • Wine におけるゲーム (やその他のアプリケーション) の実行については Wine AppDB に情報が集積されています。
  • カテゴリ:Wine も参照。

playonlinux を使うのが (特に初心者には) おすすめです。必要な依存パッケージが全てインストールされ、最初の起動時に Windows ツールを自動でダウンロード、ネイティブの windows アプリケーションが正しく実行されるように設定を行います。詳しくは、公式ウェブサイトを見て下さい。

ゲームの設定

特定のゲームや、ゲームのタイプによっては実行するのに特別な設定を必要としたり、または設定されていることが前提になっていることがあります。大抵のゲームは、何も設定をしなくても Arch Linux で動作し、コンパイル時の最適化によって、他のディストリビューションよりもパフォーマンスが出ることもあります。しかしながら、特別な環境を使っている場合、希望通りにゲームをスムーズに実行するために多少の設定やスクリプトが必要になるでしょう。

マルチスクリーン環境

マルチスクリーン環境ではフルスクリーンのゲームで問題が発生することがあります。そのようなときは、別の X サーバーを実行するのが一つの解決方法になりえます。他の方法は NVIDIA の記事を見てみて下さい (NVIDIA 以外を使っているユーザーも見る価値があります)。

キーボード操作

多くのゲームはキーボードの入力を横取りするため、ウィンドウの切り替え (alt-tab) ができなくなることがあります。

SDL のゲーム (例: Guacamelee) では Ctrl-g を押すことでキーボードの占有を無効にすることが可能です。

また、sdl-nokeyboardgrabAUR[リンク切れ: アーカイブ: aur-mirror] をダウンロードすることでも SDL のゲーム中にキーボードコマンドを使えるようにすることができます。さらに、libx11-nokeyboardgrabAUR[リンク切れ: パッケージが存在しません] を使うことで X11 レベルでキーボードの占有を無効にしたり、libx11-ldpreloadnograbAUR[リンク切れ: アーカイブ: aur-mirror] で LD_PRELOAD を使って特定の占有を止めるようにしてアプリケーションを実行するなど細かい制御をすることもできます。Wine/lib32 ユーザーは各 lib32 ライブラリにも気をつけて下さい。

ノート: SDL はときどき入力システムを使うことができなくなることが知られています。そのような場合は、数秒間待機すると入力できるようになることがあります。

別の X サーバーでゲームを起動する

上記のような場合だと、別の X サーバーを実行するのが必要もしくは望ましいかもしれません。二番目の X サーバーを実行することには複数の利点が存在します。より良いパフォーマンス、Ctrl+Alt+F7/Ctrl+Alt+F8 を使ってゲームを"最小化"することができる、ゲームがグラフィックドライバーと問題を起こしてもメインの X サーバーはクラッシュしないなどです。新しい X サーバーは ALSA へのリモートアクセスログインと同じく、ユーザーは音声を聞くために audio グループに入っている必要があります。

別の X サーバーを起動するには次のようにします (例として Xonotic を使っています): 

$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR

さらに、別の X 設定ファイルを使うことでちょっとしたスパイスを振りかけることができます: 

$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR

別の xorg.conf を使う理由としては、メインの設定では、NVIDIA の Twinview を使って Xonotic のような 3D ゲームをマルチスクリーンの中央、全ての画面にまたがって、レンダリングしているのが考えられます。これが望ましくない場合は、二番目の X を起動してセカンドスクリーンを無効にした設定を使うようにするというのが良いでしょう。

Openbox を利用してホームディレクトリや /usr/local/bin でゲームを起動するスクリプトは以下のようになります: 

~/game.sh
if [ $# -ge 1 ]; then
        game="$(which $1)"
        openbox="$(which openbox)"
        tmpgame="/tmp/tmpgame.sh"
        DISPLAY=:1.0
        echo -e "${openbox} &\n${game}" > ${tmpgame}
        echo "starting ${game}"
        xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1
else
        echo "not a valid argument"
fi

chmod +x したら、次のようにしてスクリプトを使うことが可能です: 

$ ~/game.sh xonotic-glx

マウス検出の調整

マウスの素早い操作が鍵を握るゲームの場合、マウスのポーリングレートを調整することで精度を上げられます。

OpenAL とバイノーラル音声

OpenAL を使っているゲームでは、ヘッドフォンを使用している場合、OpenAL の HRTF フィルターを使ってより良いポジショナルオーディオを得ることができます。有効にするには、次のコマンドを実行して下さい: 

echo "hrtf = true" >> ~/.alsoftrc

または、AUR から openal-hrtfAUR をインストールして、/etc/openal/alsoftrc.conf のオプションを編集して下さい。

Source エンジンのゲームの場合、HRTF を有効にするにはゲーム内設定の `dsp_slow_cpu` を `1` に設定します。設定しなかった場合は代わりに自前の処理がゲームによって有効にされます。また、ネイティブランタイムを使うように Steam を設定するか、または openal.so のネイティブランタイムのコピーをローカルコピーにリンクさせる必要があります。完全性のために、以下のオプションを使って下さい: 

dsp_slow_cpu 1 # Disable in-game spatialiazation
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it doesn't interfere with your perception of the sound effects.
snd_pitchquality 1 # Use high quality sounds

Pulseaudio の調整

PulseAudio を使っている場合、最適な動作をさせるためにデフォルト設定から変更することができる部分がいくつかあります。

realtime プライオリティと負の nice レベルを有効にする

Pulseaudio はオーディオデーモンとしてリアルタイムの優先度で実行されるようにビルドされます。しかしながら、システムがロックアップする可能性があるというセキュリティ上のリスクのため、デフォルトでは標準のスレッドと同じようにスケジューリングされます。これを変更するには、まずユーザーを audio グループに追加してください。そして、/etc/pulse/daemon.conf の以下の行をアンコメント・編集してください: 

high-priority = yes
nice-level = -11

realtime-scheduling = yes
realtime-priority = 5

編集したら pulseaudio を再起動します。

高品質なリミックスを使ってサウンドを良くする

Arch の Pulseaudio ではリミックスチャンネルにデフォルトで speex-float-0 を使っていますが、これはやや低品質なリミックスとされています。あなたのシステムに負担を増やす余裕がある場合は、以下の設定をすることでサウンドを良くすることが可能です: 

resample-method = speex-float-10

ハードウェアバッファを Pulse のバッファリングに合わせる

バッファをあわせることで音の途切れを減らし、ほんの僅かですがパフォーマンスを向上させることができます。詳しくは ここ を見て下さい。

Cgroups

Cgroups はプロセスをグループでまとめてユーザースペースで優先順位を付けて、レイテンシーを最小限にすることができるカーネルのアジャストメントです。IO の優先順位や CPU の優先順位など、複数のファクターを調整することができます。Systemd は Cgroups を暗示的に管理することができ、多数のスレッドが実行しているシステムをスムーズに動作させます。systemd をインストールするだけでこの動作の改善が行われます。

CPU 周波数スケーリングの設定を確かめる

適切な cpu 周波数スケーリングドライバーを使うように正しく設定されている場合、システムはデフォルトの governor を Ondemand に設定します。デフォルトでは、この governor はシステムが CPU の 95% を利用しているときのみ、非常に短い時間だけ、クロックを変更します。この設定では、電力が節約され熱が少なめですむ代わりに、パフォーマンスにかなり影響を与えることになります。システムの governor をチューニングすることで、ダウンクロックするのをアイドル状態の時だけに限ることが可能です。詳しくは Cpufrequtils#ondemand governor を調整するを参照。

パフォーマンスを向上させる

メインの記事も参照してください: パフォーマンスの向上。Wine プログラムに関しては、Wine#パフォーマンス を見てください。素晴らしいゲーミング体験のためには、低遅延、安定した応答時間 (変動がない)、十分なスループット (FPS) が必要です。 小さな変動のある源が複数存在すると、それらが時々重なり合って、顕著なカクつきを生み出してしまうでしょう。ゆえに、ほとんどの場合、スループットを少し下げて、応答時間の安定性を増やすことが推奨されます。

clock_gettime のスループットを改善する

ユーザ空間のプログラム (特にゲーム) は、現在の時刻を取得する clock_gettime(2) をたくさん呼び出して、ゲームの物理演算や fps の計算などを行います。時間の使用頻度は以下を実行することで確認できます: 

# perf top

read_hept (または acpi_pm_read) のオーバーヘッドを見てください。

あなたが非常に正確なタイマーを必要としていないならば、hpet (high precision event timer) や acpi_pm (ACPI Power Management Timer) から、より高速な TSC (time stamp counter) タイマーに切り替えることができます。以下のカーネルパラメータを追加することで、TSC を利用可能にし有効化してください: 

tsc=reliable clocksource=tsc

その後、再起動し、以下を実行して clocksource を確認してください: 

# cat /sys/devices/system/clocksource/clocksource*/current_clocksource

以下を実行すれば、現在利用可能なタイマーすべてを確認できます: 

# cat /sys/devices/system/clocksource/clocksource*/available_clocksource

このコマンドで表示されたタイマー名を current_clocksource に echo する (つまり、書き込む) ことで、タイマーを変更することができます。Zen 3 システムにおける [3] のベンチマークでは、hpet や acpi_pm と比べて tsc のスループットのほうが約50倍良くなっています。

カーネルパラメータを調整して応答時間を安定化させる

リアルタイムカーネルをインストールすることで、CPU のスループットが大幅に低下しますが、何も設定せずに応答時間を飛躍的に安定化させることができます。ちなみに、リアルタイムカーネルは nvidia-open-dkms とは互換性がなく、デフォルトのプロセススケジューリングタイプである SCHED_NORMAL (SCHED_OTHER とも呼ばれる) のプロセスのスケジューラは変更しません。以下のようにカーネルパラメータを変更すると、リアルタイムカーネルおよび他のカーネル (デフォルトの linux カーネルなど) の応答時間をさらに安定化させます:

カーネルドキュメントによると Proactive Compaction は応答時間の揺れを発生させるので、無効化してください: 

# echo 0 > /proc/sys/vm/compaction_proactiveness

RAM の空き領域が十分にある場合、メモリアロケーション時に応答時間が悪化することを防ぐために、minimum free Kilobytes の値を増やしてください: [4][5]. この値を 1024 KB 以下、もしくはシステムメモリの 5% より大きい値に設定しないでください。1GB を予約するには: 

# echo 1048576 > /proc/sys/vm/min_free_kbytes

システムの空きメモリ領域が不足していない限りスワップを防ぐために (スワップはページをロックするので、レイテンシを増加させ、ディスク IO を使用します): 

# echo 10 > /proc/sys/vm/swappiness

zone reclaim を無効化してください (zone reclaim はメモリページをロック・移動するので、レイテンシのスパイクを発生させます): 

# echo 0 > /proc/sys/vm/zone_reclaim_mode

Transparent Huge Pages (THP) を無効化してください。デフラグメンテーションが無効化されている場合でも、THP はレイテンシのスパイクを発生させるかもしれません。[6][7] 

# echo never > /sys/kernel/mm/transparent_hugepage/enabled
# echo never > /sys/kernel/mm/transparent_hugepage/shmem_enabled
# echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag

あなたのゲームが TCMalloc を使用する場合 (例: Dota2、CS:GO)、パフォーマンスが大幅に低下してしまうので、THP を無効化することは推奨されません。[8]

適切なスループットを維持しつつ、ページロック取得のレイテンシの最大値を減らします [9][10][11]: 

# echo 1 > /proc/sys/vm/page_lock_unfairness

スケジューラの設定を調整します。以下のスケジューラの設定は cfs-zen-tweaksAUR と衝突するので、それぞれの設定に対してプロバイダを1つだけ選んでください。デフォルトでは、linux カーネルのスケジューラはレイテンシではなくスループットに対して最適化されています。以下のお手製の設定はそれを変更し、異なるゲームにおいてテストされ、顕著な改善が確認されています。これらの設定はあなたのユースケースに対しては最適ではないかもしれません。必要に応じてこれらの設定を変更することを検討してください [12][13]: 

# echo 0 > /proc/sys/kernel/sched_child_runs_first
# echo 1 > /proc/sys/kernel/sched_autogroup_enabled
# echo 500 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
# echo 1000000 > /sys/kernel/debug/sched/latency_ns
# echo 500000 > /sys/kernel/debug/sched/migration_cost_ns
# echo 500000 > /sys/kernel/debug/sched/min_granularity_ns
# echo 0 > /sys/kernel/debug/sched/wakeup_granularity_ns
# echo 8 > /sys/kernel/debug/sched/nr_migrate

設定の変更を永続化させる

通常、カーネルパラメータを永続的に変更するには、sysctl の設定ファイルを作成したり、ブートローダーの設定を変更したりすることが推奨されます。しかし、上記の設定の変更は procfs (/proc、sysctl を含む) と sysfs (/sys) の両方に渡っているので、最も便利な方法は systemd-tmpfiles を使用することです: 

/etc/tmpfiles.d/consistent-response-time-for-gaming.conf
#    Path                  Mode UID  GID  Age Argument
w /proc/sys/vm/compaction_proactiveness - - - - 0
w /proc/sys/vm/min_free_kbytes - - - - 1048576
w /proc/sys/vm/swappiness - - - - 10
w /proc/sys/vm/zone_reclaim_mode - - - - 0
w /sys/kernel/mm/transparent_hugepage/enabled - - - - never
w /sys/kernel/mm/transparent_hugepage/shmem_enabled - - - - never
w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag - - - - 0
w /proc/sys/vm/page_lock_unfairness - - - - 1
w /proc/sys/kernel/sched_child_runs_first - - - - 0
w /proc/sys/kernel/sched_autogroup_enabled - - - - 1
w /proc/sys/kernel/sched_cfs_bandwidth_slice_us - - - - 500
w /sys/kernel/debug/sched/latency_ns  - - - - 1000000
w /sys/kernel/debug/sched/migration_cost_ns - - - - 500000
w /sys/kernel/debug/sched/min_granularity_ns - - - - 500000
w /sys/kernel/debug/sched/wakeup_granularity_ns  - - - - 0
w /sys/kernel/debug/sched/nr_migrate - - - - 8

その後、再起動し、値が正しく反映されていることを確認してください。

共有オブジェクトを即座に読み込んで初回の遅延を減らす

使用するゲームに対して以下の環境変数を設定してください: 

LD_BIND_NOW=1

これにより、プログラムコードを実行時に読み込む必要性がなくなり (ld.so(8) を参照)、関数が初めて呼ばれたときの遅延をなくします。システム上に実際には存在せず決して呼ばれないライブラリにリンクしている startplasma-x11 やその他のプログラムに対してこの変数を設定しないでください。この場合、プログラムは起動時に存在しない共有オブジェクトにリンクしようとして失敗するので、問題の特定は簡単です。ほとんどのゲームはこの変数を有効化した状態で問題なく起動するはずです。

ユーティリティ

Gamemode

Gamemode は、ゲームがホスト OS に最適化のセットを一時的に適用するように要求できるようにする、Linux 用のデーモン/ライブラリの組です。これによりゲームのパフォーマンスを向上できます。

ACO コンパイラ

ノート: 以下の方法は、AMDGPU ドライバを動作させている AMD GPU でしか動作しません。

AMDGPU#ACO コンパイラ を参照。

fsync パッチ

Steam#Fsync パッチ を参照。

DRI の遅延を軽減する

Direct Rendering Infrastructure (DRI) の設定ファイルは、Mesa と Nouveau を含むすべての DRI ドライバに適用されます。/etc/drirc を編集することで DRI の設定をシステム全体に対して変更することができますし、$HOME/.drirc を編集すればユーザ単位で変更できます。これらのファイルが存在しない場合、まず作成する必要があります。両方のファイルは同じ構文を使用します。オプションに関するドキュメントは https://dri.freedesktop.org/wiki/ConfigurationOptions/ で見られます。vblank との同期を無効化することで入力の遅延を減らすには、以下を追加してください: 

<driconf>
   <device>
       <application name="Default">
           <option name="vblank_mode" value="0" />
       </application>
   </device>
</driconf>

スケジューリングポリシーによってフレームレートやレスポンスを改善する

カーネルがタスクを優先順位付けできるように適切なスケジューリングポリシーを与えれば、ほとんどのゲームにおいて利益を得られます。これらのポリシーは、理想的にはアプリケーション自体によってスレッドごとに設定されるべきです。

アプリケーション自体がスケジューリングポリシーを実装していない場合、schedtool というアプリケーションとそれに関連するデーモンの schedtooldAUR を使えば、これらのタスクの多くを自動的に処理できます。

どのプログラムがどのポリシーを使用するかを編集するには、/etc/schedtoold.conf を編集し、プログラム名の後に必要な schedtool 引数を追加してください。

ポリシー

SCHED_ISO (-pf や -ck カーネルで使用されている BFS/MuQSSPDS スケジューラでのみ実装されています) は、プロセスが CPU の最大80%まで使用できるようになるだけでなく、できるかぎり遅延とスタッタリングを減らすことにつながります。全てではなくとも多くのゲームで効果が得られます: 

bit.trip.runner -I

SCHED_FIFO は、より良く機能する代替を提供します。あなたのアプリケーションが SCHED_FIFO でよりスムーズに動作するかを確認してみるべきでしょう。スムーズに動作する場合は、SCHED_FIFO を代わりに使用すべきです。とはいえ、SCHED_FIFO はシステムのリソースを枯渇させるリスクがあるので、注意してください。以下のよな -I が使用されるケースでこれを使用します: 

bit.trip.runner -F -p 15

Nice レベル

次に、先に処理させる必要があるタスクを昇順に nice レベルを設定します。ゲームなど、マルチメディアのタスクは基本的に nice レベルを -4 にすることが推奨されています: 

bit.trip.runner -n -4

コアアフィニティ

ドライバーがマルチスレッドするべきか、あるいはプログラムがマルチスレッドするべきかは、開発において多少の混乱が存在します。ドライバとプログラムの両方に同時にマルチスレッドさせてしまうと、フレームレートの低下などの大幅なパフォーマンスの劣化が発生し、クラッシュのリスクを増加させてしまいます。

最近のゲームや、GLSL を無効にしないで実行される Wine プログラムなどがこの例に含まれます。単一のコアを選択して、ドライバーだけがプロセスを管理できるようにするには、-a 0x# フラグを使います。# はコアの番号に置き換えて下さい。例えば、1番目のコアを使うには: 

bit.trip.runner -a 0x1

CPU にはハイパースレッディングによって 2 または 4 のコアしか存在しないのに 4 あるいは 8 もコアがあるように認識されることがあります。その場合、仮想コア 0101 (1 と 3) を使うには: 

bit.trip.runner -a 0x5

一般的なケース

高いフレームレートと低遅延を必要とするほとんどのゲームでは、上記のフラグを全て使うのが一番良い結果になります。ただし、アフィニティはプログラムごとに確認してください。ほとんどのネイティブゲームは正しい使い方を理解しています。一般的なケースのフラグ例: 

bit.trip.runner -I -n -4
Amnesia.bin64 -I -n -4
hl2.exe -I -n -4 -a 0x1 #GLSL が有効化された状態の Wine

Optimus やその他の便利なプログラム

一般的に、ゲームが動作するのに必要なプロセスはゲーム自体のプロセスよりも上のレベルに renice されるべきです。奇妙なことに、Wine には reverse scheduling という既知の問題が存在し、重要なプロセスに nice レベルが高く設定されることがあります。そこで、スケジューリングポリシーを設定すると動作が改善します。Wineserver も CPU 全体を消費することはあまりなく、必要なときは優先度を高くする必要があるので、無条件で SCHED_FIFO を設定したほうが良いでしょう。 

optirun -I -n -5
wineserver -F -p 20 -n 19
steam.exe -I -n -5

周辺機器

マウス

マウスのアクセラレーションを設定して、マウスをより正確にコントロールできるようにすると良いかもしれません。

マウスに4つ以上のボタンが付いている場合、マウスボタン を参照すると良いかもしれません。

ゲーミングマウス (特に Logitech と Steelseries) を使用している場合、piper を使ってマウスのマウスのポーリングレート、DPI、LED などを設定すると良いかもしれません。piper によってサポートされているデバイスの完全なリストはこのページを見てください。logitech デバイスだけの場合は solaar も使えます。

LED

openrgb を使ってマザーボードや RAM の点灯を変更できます。現在サポートされているデバイスのリストは、[14] を見てください。

参照

  • linux_gaming - reddit.com 上の Linux ゲーミングに関するフォーラム。サブページ: Wiki、FAQ。
  • Linux Gaming Guide - Linux ゲーミングのエクスペリエンスの最適化に関するテクニック集。
  • are we anti cheat yet - アンチチートを使用するゲームとそのゲームの Gnu/Linux 及び Wine/Proton における互換性の、コミュニティによる包括的なリスト。
  • proton db - コミュニティによる Linux 互換性レポート集
「https://wiki.archlinux.jp/index.php?title=ゲーム&oldid=36486」から取得