ゲーム

提供: ArchWiki
2022年12月26日 (月) 23:32時点におけるKusanaginoturugi (トーク | 投稿記録)による版 (ゲーミングプラットフォームに変更)
ナビゲーションに移動 検索に移動

関連記事

Linux は「非公式」のゲーミングプラットフォームと見なされます。それに提供されるサポートとターゲットユーザーは、ほとんどのゲーム組織にとって最優先事項ではありません。これは、2021年以降、Valve などの大企業、CodeWeavers グループ、およびコミュニティが、過去数か月にわたって大幅な変更を行い、Linux が真にゲーム用の実行可能なプラットフォームになることを可能にするために、いくつかの変化が見られました。さらに、Linux でゲームをコンパイルして実行できるようにするために、クロスプラットフォームのレンダリング エンジンを使用しようとするインディー開発チームがますます増えています。

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

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

目次

Game technicality

There are ultimately two major problems that arise from attempting to play AAA games on Linux. They are:

  • Graphics SDK
    • Games written and compiled for an API that Linux does not recognize (such as DirectX).
  • Graphics Hardware
    • Drivers necessary to handle game rendering. (such as Nvidia Drivers)

From these problems, further two complications arise, in particular:

  • General Library Dependencies
    • Libraries necessary for doing general purpose operations during gameplay, such as saving ingame, loading config. (e.g Microsoft Visual C++, MFC, .NET)
  • Incompatible Interfaces
    • Aside from the frameworks mentioned above, there is a further problem with binary formats and compiled code generated by Windows which Linux does not recognize.
    • Lastly, lacking the appropriate driver to do the rendering results in a horseless cart situation.

The APIs above forward their graphical calls to the underlying driver which then proceeds to talking to the GPU hardware. AMD users fortunately have opensource drivers released by AMD itself. This is already a huge issue resolved. Nvidia users have to rely on other alternatives, which often comes packed as blobs. (microcode and firmware being fed through, as a result of Nvidia driver reverse engineering)

A huge amount of games use DirectX as their main driving SDK. Linux, natively supports only OpenGL and Vulkan. Linux by itself does not support DirectX or any of the aforementioned technologies (Visual C++, MFC, .NET).

Instead, several opensource equivalents have been written which attempt to provide identical functionality, ultimately achieving the same result from a graphics point of view. These equivalents have their "own" written substitutes which attempt to "re-invent" what the original SDK calls would possibly achieve from a black box point of view. Popular ones include:

  • Wine (Wine is Not Emulator) [provides a "loader vm", self written dependencies, interop and more]
  • Proton (forked Wine project, optimized for Steam by Valve)
  • Mono (.NET alternative)
  • MF-Media (media foundation dependencies)

For example, a call to load, transform and shade vertices on DirectX may be re-written from scratch in a new .dll/.so owned by Wine, providing their own "hypothetical" belief on what the function may be doing underneath, and forward it instead to an OpenGL alternative, effectively trying to achieve similar results. Since these calls are direct equivalents and treated "as if" DirectX was running, performance is not impacted. (with the exception of the starting overhead to interop with these)

These tools are often brought in the distribution together on the system at the same time. A prefix (Wine's terminology for a directory mimicking a Windows sandbox) is created and configured. Dependencies are installed inside the prefix (the "sandbox" still needs the game's redistributables), often with winetricks, followed by an attempt to run the game "as if" it was executed from Windows.

This, nowadays, fortunately works for most games (aside from anticheat protected ones, which require a kernel driver that Wine/Proton does not yet have). If a game does not work, it is usually as a result of incompatible packages, missing dependencies or unimplemented functionality by Wine/Proton.

If you are to run Wine/Proton, please make sure you use versions past 5.x as this is where most of the recent patches have been made into.

Lutris is a piece of software that provides runners and sandboxes that handle dependencies for you when you install games, if the above process is found tedious and/or complicated.

Common game dependencies

In order to gain a more in-depth understanding of what you will intend to do if you decide to go the Wine/Proton route, it is worthwhile to cover the common dependencies that games require in order to execute. Architecture also needs to be considered in mind, whether x86 or x64, preferably both.

A prefix would need to have the following populated into it in order to run most Windows games.

Mandatory (for high coverage)

この記事あるいはセクションで使われている用語や表現には問題が存在します。
議論: Links to wiki articles that contain package links (e.g. Fonts) should be used here (議論: トーク:ゲーム#)
  • Microsoft Core Fonts
  • Microsoft Visual C++ 2015 (2017 has the most coverage, recommended) [2005, 2008, 2010, 2012, 2013, 2015, 2017-2018, 2019]
  • DirectX 9.0 (11.0 has the most coverage, recommended) [June SDK update 2010] {which consists of, to name a few:}
    • Direct3D
    • Direct2D
    • DirectShow
    • DirectInput
    • DirectPlay
    • DirectSound
    • DXGI
    • XAudio2
  • .NET Framework (3.5 has most coverage)
  • OpenGL
    • OpenAL
    • OpenAI
    • OpenCL
  • Vulkan

Optional (but still common)

  • XNA
  • PhysX
  • Media Foundation
  • Quicktime
  • Adobe Reader 11
  • Java SRE (e.g Minecraft)

Rare (less common)

  • Gamespy
  • MIDI driver
  • ACDSee

Machine requirements

It is not enough to just populate a prefix with the dependencies the game will need. The kernel itself has to have the substitution it will provide to the calls the game will make. As already mentioned, drivers and alternatives are available.

Drivers

Dependency for the machine & substitutes

This is mostly informative. Some of these packages install themselves once you install the major ones.

ゲーム環境

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 パススルーによって直接ハードウェアを利用することも可能です。

ゲームの取得

ネイティブ

公式リポジトリや 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 システムにおける [1] のベンチマークでは、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 の値を増やしてください: [2][3]. この値を 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 はレイテンシのスパイクを発生させるかもしれません。[4][5] 

# 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 を無効化することは推奨されません。[6]

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

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

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

# 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 などを設定すると良いかもしれません。サポートされているデバイスの完全なリストはこのページを見てください。logitech デバイスだけの場合は solaar もあります。

LED

openrgbAUR を使ってマザーボードや RAM の点灯を変更できます。

参照

  • [12] - reddit.com 上の Linux ゲーミングに関するフォーラム。サブページ: Wiki, FAQ。
  • Linux Gaming Guide - Linux ゲーミングのエクスペリエンスの最適化に関するテクニック集
「https://wiki.archlinux.jp/index.php?title=ゲーム&oldid=28995」から取得