「ゲーム」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
325行目: 325行目:
 
== パフォーマンスを向上させる ==
  
== パフォーマンスを向上させる ==
   
−
メインの記事も参照してください: [[パフォーマンスの向上]]。Wine プログラムに関しては、[[Wine#パフォーマンス]] を見てください。素晴らしいゲーミング体験のためには、低遅延、安定した応答時間 (変動がない)、十分なスループット (FPS) が必要です。
 +
メインの記事 ([[パフォーマンスの向上]]) も参照してください。Wine プログラムに関しては、[[Wine#パフォーマンス]] を見てください。素晴らしいゲーミング体験のためには、低遅延、(変動のない) 安定した応答時間、十分なスループット (FPS) が必要です。
 
小さな変動のある源が複数存在すると、それらが時々重なり合って、顕著なカクつきを生み出してしまうでしょう。ゆえに、ほとんどの場合、スループットを少し下げて、応答時間の安定性を増やすことが推奨されます。
  
小さな変動のある源が複数存在すると、それらが時々重なり合って、顕著なカクつきを生み出してしまうでしょう。ゆえに、ほとんどの場合、スループットを少し下げて、応答時間の安定性を増やすことが推奨されます。
   
336行目: 336行目:
 
read_hept (または acpi_pm_read) のオーバーヘッドを見てください。
  
read_hept (または acpi_pm_read) のオーバーヘッドを見てください。
   
−
あなたが非常に正確なタイマーを必要としていないならば、hpet (high precision event timer) や acpi_pm (ACPI Power Management Timer) から、より高速な TSC (time stamp counter) タイマーに切り替えることができます。以下の[[カーネルパラメータ]]を追加することで、TSC を利用可能にし有効化してください:
 +
あなたが非常に正確なタイマーを必要としていないならば、hpet (high precision event timer) や acpi_pm (ACPI Power Management Timer) から、より高速な TSC (time stamp counter) タイマーに切り替えることができます。TSC を利用可能にし有効化するには、以下の[[カーネルパラメータ]]を追加してください:
   
 
tsc=reliable clocksource=tsc
  
tsc=reliable clocksource=tsc
349行目: 349行目:
   
 
このコマンドで表示されたタイマー名を current_clocksource に echo する (つまり、書き込む) ことで、タイマーを変更することができます。Zen 3 システムにおける [https://gist.github.com/weirddan455/eb807fa48915652abeca3b6421970ab4] のベンチマークでは、{{ic|hpet}} や {{ic|acpi_pm}} と比べて {{ic|tsc}} のスループットのほうが約50倍良くなっています。
  
このコマンドで表示されたタイマー名を current_clocksource に echo する (つまり、書き込む) ことで、タイマーを変更することができます。Zen 3 システムにおける [https://gist.github.com/weirddan455/eb807fa48915652abeca3b6421970ab4] のベンチマークでは、{{ic|hpet}} や {{ic|acpi_pm}} と比べて {{ic|tsc}} のスループットのほうが約50倍良くなっています。
  +
  +
{{Warning|{{ic|tsc}} タイマーの信頼性が乏しい場合にこのタイマーを強制すると、{{ic|clock_gettime(CLOCK_MONOTONIC)}}[https://mastodon.yuuta.moe/@coelacanthus/110996261222325004] の単調増加性 (Firefox はこれに依存しています) が破壊され、Firefox がランダムにクラッシュする原因になります。このタイマーは自己責任で使用してください!}}
   
 
=== カーネルパラメータを調整して応答時間を安定化させる ===
  
=== カーネルパラメータを調整して応答時間を安定化させる ===
   
−
[[リアルタイムカーネル]]をインストールすることで、CPU のスループットが大幅に低下しますが、何も設定せずに応答時間を飛躍的に安定化させることができます。ちなみに、リアルタイムカーネルは {{Pkg|nvidia-open-dkms}} とは互換性がなく、デフォルトのプロセススケジューリングタイプである SCHED_NORMAL (SCHED_OTHER とも呼ばれる) のプロセスのスケジューラは変更しません。以下のようにカーネルパラメータを変更すると、リアルタイムカーネルおよび他のカーネル (デフォルトの linux カーネルなど) の応答時間をさらに安定化させます:
 +
リアルタイムカーネルにはデフォルトでいくつかのメリット ([[リアルタイムカーネル]]の記事を参照) がありますが、CPU のスループットが犠牲になり、また割り込み処理が遅延する可能性もあります。ちなみに、リアルタイムカーネルは {{Pkg|nvidia-open-dkms}} とは互換性がなく、デフォルトのプロセススケジューリングタイプである SCHED_NORMAL (SCHED_OTHER とも呼ばれる) のプロセスのスケジューラは変更しません。以下のようにカーネルパラメータを変更すると、リアルタイムカーネルおよび他のカーネル (デフォルトの linux カーネルなど) の応答時間をさらに安定化させます:
   
−
[https://docs.kernel.org/admin-guide/sysctl/vm.html カーネルドキュメント]によると Proactive Compaction は応答時間の揺れを発生させるので、無効化してください:
 +
(Transparent) Hugepage の割り当てに対する proactive compaction は、割り当ての平均時間を減少させますが、最大時の時間を減らすとは限りません。Proactive compaction は、[https://docs.kernel.org/admin-guide/sysctl/vm.html カーネルのドキュメント]によると応答時間の揺れを生じさせるので ([https://nitingupta.dev/post/proactive-compaction/ 内部での動作])、無効化してください:
   
 
# echo 0 > /proc/sys/vm/compaction_proactiveness
  
# echo 0 > /proc/sys/vm/compaction_proactiveness
   
  +
メモリの断片化が発生した場合にページブロック1つ (x86_64 では 2MB) だけをデフラグするようにするために、watermark boost factor を減らしてください。こうすることで、メモリの断片化の発生後、アプリケーションのデータがプロセッサキャッシュの最終レベルに残りやすくなります。
−
RAM の空き領域が十分にある場合、メモリアロケーション時に応答時間が悪化することを防ぐために、minimum free Kilobytes の値を増やしてください: [http://highscalability.com/blog/2015/4/8/the-black-magic-of-systematically-reducing-linux-os-jitter.html][https://docs.kernel.org/admin-guide/sysctl/vm.html]. この値を 1024 KB 以下、もしくはシステムメモリの 5% より大きい値に設定しないでください。1GB を予約するには:
  
  +
  +
# echo 1 > /proc/sys/vm/watermark_boost_factor
  +
  +
RAM の空き領域が十分にある場合、メモリアロケーション時に応答時間が悪化することを防ぐために、minimum free Kilobytes の値を増やしてください: [http://highscalability.com/blog/2015/4/8/the-black-magic-of-systematically-reducing-linux-os-jitter.html][https://docs.kernel.org/admin-guide/sysctl/vm.html]。この値を 1024 KB 以下、もしくはシステムメモリの 5% より大きい値に設定しないでください。1GB を予約するには:
   
 
# echo 1048576 > /proc/sys/vm/min_free_kbytes
  
# echo 1048576 > /proc/sys/vm/min_free_kbytes
   
  +
RAM の空き領域が十分にある場合、アロケーション時に応答時間が増加する可能性をさらに減らすために、watermark scale factor を増やしてください (説明: [https://blogs.oracle.com/linux/post/anticipating-your-memory-needs][https://blogs.oracle.com/linux/post/anticipating-your-memory-needs-2])。Watermark の位置を RAM の 5% に設定するには:
−
システムの空きメモリ領域が不足していない限りスワップを防ぐために (スワップはページをロックするので、レイテンシを増加させ、ディスク IO を使用します):
  
  +
  +
# echo 500 > /proc/sys/vm/watermark_scale_factor
  +
  +
システムの空きメモリ領域が不足していない限りスワップを防ぐために (スワップはページをロックするので、レイテンシを増加させ、ディスク IO を使用します)、swappiness を減らしてください:
   
 
# echo 10 > /proc/sys/vm/swappiness
  
# echo 10 > /proc/sys/vm/swappiness
   
−
zone reclaim を無効化してください (zone reclaim はメモリページをロック・移動するので、レイテンシのスパイクを発生させます):
 +
Multi-Gen Least Recently Used (MGLRU) を有効化してください (小さなパフォーマンスコストでロック競合の可能性を減らします [https://docs.kernel.org/admin-guide/mm/multigen_lru.html]):
  +
  +
# echo 5 > /sys/kernel/mm/lru_gen/enabled
  +
  +
Zone reclaim を無効化してください (zone reclaim はメモリページをロック・移動するので、レイテンシのスパイクを発生させます):
   
 
# echo 0 > /proc/sys/vm/zone_reclaim_mode
  
# echo 0 > /proc/sys/vm/zone_reclaim_mode
   
−
Transparent Huge Pages (THP) を無効化してください。デフラグメンテーションが無効化されている場合でも、THP はレイテンシのスパイクを発生させるかもしれません。[https://docs.kernel.org/admin-guide/mm/transhuge.html][https://alexandrnikitin.github.io/blog/transparent-hugepages-measuring-the-performance-impact/]
 +
パフォーマンスコストの観点から Transparent HugePages (THP) を無効化してください。デフラグメンテーションが無効化されている場合でも、THP はレイテンシのスパイクを発生させるかもしれません。[https://docs.kernel.org/admin-guide/mm/transhuge.html][https://alexandrnikitin.github.io/blog/transparent-hugepages-measuring-the-performance-impact/] madvise と advise を使用することで、アプリケーションが明示的に要求した場合に限り有効化します:
   
 
{{bc|
  
{{bc|
−
# echo never > /sys/kernel/mm/transparent_hugepage/enabled
 +
# echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
−
# echo never > /sys/kernel/mm/transparent_hugepage/shmem_enabled
 +
# echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled
−
# echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag
 +
# echo never > /sys/kernel/mm/transparent_hugepage/defrag
 
}}
  
}}
   
384行目: 398行目:
 
# echo 1 > /proc/sys/vm/page_lock_unfairness
  
# echo 1 > /proc/sys/vm/page_lock_unfairness
   
−
スケジューラの設定を調整します。以下のスケジューラの設定は {{AUR|cfs-zen-tweaks}} と衝突するので、それぞれの設定に対してプロバイダを1つだけ選んでください。デフォルトでは、linux カーネルのスケジューラはレイテンシではなくスループットに対して最適化されています。以下のお手製の設定はそれを変更し、異なるゲームにおいてテストされ、顕著な改善が確認されています。これらの設定はあなたのユースケースに対しては最適ではないかもしれません。必要に応じてこれらの設定を変更することを検討してください [https://access.redhat.com/solutions/177953][https://doc.opensuse.org/documentation/leap/tuning/html/book-tuning/cha-tuning-taskscheduler.html]:
+
スケジューラの設定を調整します。以下のスケジューラの設定は {{AUR|cfs-zen-tweaks}} と衝突するので、それぞれの設定に対してプロバイダを1つだけ選んでください。デフォルトでは、linux カーネルのスケジューラはレイテンシではなくスループットに対して最適化されています。以下のお手製の設定はそれを変更し、異なるゲームにおいてテストされ、顕著な改善が確認されています。これらの設定はあなたのユースケースに対しては最適ではないかもしれません。必要に応じてこれらの設定を変更することを検討してください [https://access.redhat.com/solutions/177953][https://doc.opensuse.org/documentation/leap/tuning/html/book-tuning/cha-tuning-taskscheduler.html][https://www.amd.com/system/files/documents/58016-epyc-9004-tg-java.pdf#page=29]:
   
 
{{bc|
  
{{bc|
 
# echo 0 > /proc/sys/kernel/sched_child_runs_first
  
# echo 0 > /proc/sys/kernel/sched_child_runs_first
 
# echo 1 > /proc/sys/kernel/sched_autogroup_enabled
  
# echo 1 > /proc/sys/kernel/sched_autogroup_enabled
−
# echo 500 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
 +
# echo 3000 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
−
# echo 1000000 > /sys/kernel/debug/sched/latency_ns
 +
# echo 3000000 > /sys/kernel/debug/sched/base_slice_ns
 
# echo 500000 > /sys/kernel/debug/sched/migration_cost_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
  
# echo 8 > /sys/kernel/debug/sched/nr_migrate
 
}}
  
}}
402行目: 414行目:
   
 
{{hc|/etc/tmpfiles.d/consistent-response-time-for-gaming.conf|
  
{{hc|/etc/tmpfiles.d/consistent-response-time-for-gaming.conf|
−
# Path Mode UID GID Age Argument
 +
# Path Mode UID GID Age Argument # default value as of linux 6.6
−
w /proc/sys/vm/compaction_proactiveness - - - - 0
 +
w /proc/sys/vm/compaction_proactiveness - - - - 0 # 20
−
w /proc/sys/vm/min_free_kbytes - - - - 1048576
 +
w /proc/sys/vm/watermark_boost_factor - - - - 1 # 15000
−
w /proc/sys/vm/swappiness - - - - 10
 +
w /proc/sys/vm/min_free_kbytes - - - - 1048576 # 67584
−
w /proc/sys/vm/zone_reclaim_mode - - - - 0
 +
w /proc/sys/vm/watermark_scale_factor - - - - 500 # 10
−
w /sys/kernel/mm/transparent_hugepage/enabled - - - - never
 +
w /proc/sys/vm/swappiness - - - - 10 # 60
−
w /sys/kernel/mm/transparent_hugepage/shmem_enabled - - - - never
 +
w /sys/kernel/mm/lru_gen/enabled - - - - 5 # 7
−
w /sys/kernel/mm/transparent_hugepage/khugepaged/defrag - - - - 0
 +
w /proc/sys/vm/zone_reclaim_mode - - - - 0 # 0
−
w /proc/sys/vm/page_lock_unfairness - - - - 1
 +
w /sys/kernel/mm/transparent_hugepage/enabled - - - - madvise # always
−
w /proc/sys/kernel/sched_child_runs_first - - - - 0
 +
w /sys/kernel/mm/transparent_hugepage/shmem_enabled - - - - advise # never
−
w /proc/sys/kernel/sched_autogroup_enabled - - - - 1
 +
w /sys/kernel/mm/transparent_hugepage/defrag - - - - never # madvise
−
w /proc/sys/kernel/sched_cfs_bandwidth_slice_us - - - - 500
 +
w /proc/sys/vm/page_lock_unfairness - - - - 1 # 5
−
w /sys/kernel/debug/sched/latency_ns - - - - 1000000
 +
w /proc/sys/kernel/sched_child_runs_first - - - - 0 # 0
−
w /sys/kernel/debug/sched/migration_cost_ns - - - - 500000
 +
w /proc/sys/kernel/sched_autogroup_enabled - - - - 1 # 1
−
w /sys/kernel/debug/sched/min_granularity_ns - - - - 500000
 +
w /proc/sys/kernel/sched_cfs_bandwidth_slice_us - - - - 3000 # 5000
−
w /sys/kernel/debug/sched/wakeup_granularity_ns - - - - 0
 +
w /sys/kernel/debug/sched/base_slice_ns - - - - 3000000 # 3000000
−
w /sys/kernel/debug/sched/nr_migrate - - - - 8
 +
w /sys/kernel/debug/sched/migration_cost_ns - - - - 500000 # 500000
  +
w /sys/kernel/debug/sched/nr_migrate - - - - 8 # 32
 
}}
  
}}
   
429行目: 442行目:
 
LD_BIND_NOW=1
  
LD_BIND_NOW=1
   
−
これにより、プログラムコードを実行時に読み込む必要性がなくなり ({{man|8|ld.so}} を参照)、関数が初めて呼ばれたときの遅延をなくします。システム上に実際には存在せず決して呼ばれないライブラリにリンクしている ''startplasma-x11'' やその他のプログラムに対してこの変数を設定しないでください。この場合、プログラムは起動時に存在しない共有オブジェクトにリンクしようとして失敗するので、問題の特定は簡単です。ほとんどのゲームはこの変数を有効化した状態で問題なく起動するはずです。
 +
これにより、プログラムコードを実行時に読み込む必要性がなくなり ({{man|8|ld.so}} を参照)、関数が初めて呼ばれたときの遅延をなくします。システム上に実際には存在せず決して呼ばれないライブラリにリンクしている ''startplasma-x11'' などのプログラムに対してこの変数を設定しないでください。この場合、プログラムは起動時に存在しない共有オブジェクトにリンクしようとして失敗するので、問題の特定は簡単です。ほとんどのゲームはこの変数を有効化した状態で問題なく起動するはずです。
   
 
=== ユーティリティ ===
  
=== ユーティリティ ===
436行目: 449行目:
   
 
[[Gamemode]] は、ゲームがホスト OS に最適化のセットを一時的に適用するように要求できるようにする、Linux 用のデーモン/ライブラリの組です。これによりゲームのパフォーマンスを向上できます。
  
[[Gamemode]] は、ゲームがホスト OS に最適化のセットを一時的に適用するように要求できるようにする、Linux 用のデーモン/ライブラリの組です。これによりゲームのパフォーマンスを向上できます。
  +
  +
==== Gamescope ====
  +
  +
[[Gamescope]] は、Valve によって開発されているマイクロコンポジタです。Steam Deck で使用されています。このプロジェクトの目的は、ゲーミング向けに調整され、多くのゲーム中心の機能をサポートする独立したコンポジタを提供することです。
   
 
=== ACO コンパイラ ===
  
=== ACO コンパイラ ===
442行目: 459行目:
   
 
[[AMDGPU#ACO コンパイラ]] を参照。
  
[[AMDGPU#ACO コンパイラ]] を参照。
−  
−
=== fsync パッチ ===
  
−  
−
[[Steam#Fsync パッチ]] を参照。
  
   
 
=== DRI の遅延を軽減する ===
  
=== DRI の遅延を軽減する ===
485行目: 498行目:
 
==== コアアフィニティ ====
  
==== コアアフィニティ ====
   
−
ドライバーがマルチスレッドするべきか、あるいはプログラムがマルチスレッドするべきかは、開発において多少の混乱が存在します。ドライバとプログラムの両方に同時にマルチスレッドさせてしまうと、フレームレートの低下などの大幅なパフォーマンスの劣化が発生し、クラッシュのリスクを増加させてしまいます。
 +
ドライバーがマルチスレッドするべきか、あるいはプログラムがマルチスレッドするべきかは、開発において多少の混乱が存在します。ドライバとプログラムの両方に同時にマルチスレッドさせてしまうと、フレームレートの低下などの大幅なパフォーマンスの劣化が発生し、クラッシュのリスクを増加させてしまいます。最近のゲームや、[[Wikipedia:ja:GLSL|GLSL]] を無効にしないで実行される Wine プログラムなどがこの例に含まれます。単一のコアを選択して、ドライバーだけがプロセスを管理できるようにするには、{{ic|-a 0x''#''}} フラグを使います。''#'' はコアの番号に置き換えて下さい。例えば、1番目のコアを使うには:
−  
−
最近のゲームや、[[Wikipedia:ja:GLSL|GLSL]] を無効にしないで実行される Wine プログラムなどがこの例に含まれます。単一のコアを選択して、ドライバーだけがプロセスを管理できるようにするには、{{ic|-a 0x''#''}} フラグを使います。''#'' はコアの番号に置き換えて下さい。例えば、1番目のコアを使うには:
  
   
 
bit.trip.runner -a 0x1
  
bit.trip.runner -a 0x1

2024年3月11日 (月) 20:30時点における版

関連記事

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 バージョン。

ゲーム環境

Wine/Proton 以外にもゲームをプレイする方法はあります。Linux でゲームをプレイするための環境は様々あり、これらの環境では Windows と同じくらい (あるいはそれ以上) のゲームが存在します:

  • ネイティブ – Linux プラットフォーム向けのビルドが存在し、OpenGL や Vulkan グラフィックス API のサポートのあるゲーム。
  • エミュレータ – 他のアーキテクチャやシステム用に設計されたソフトウェアを実行する際に必要です。ほとんどのゲームは ROM をエミュレータに読み込ませれば特に設定せずとも動き、問題が発生することは稀です。エミュレータのリストは ビデオゲームプラットフォームエミュレーター を参照してください。
  • Java - Write once, run everywhere (一度書けば、どこでも動く) なプラットフォームです。Linux でも動く人気なゲームとしては、Minecraft、RuneScape、Wurm Online、Puzzle Pirates があります。
  • ウェブ – ウェブブラウザ内で動くゲームです。
    • HTML5 ゲームは canvas と WebGL の技術を使用し、最近のブラウザ全てで動作可能です。
    • Flash ベースのゲーム – プレイするにはプラグインをインストールする必要があります。
  • Wine – Windows 互換レイヤーです。Unix ライクなオペレーティングシステム上で Windows アプリケーション (だけでなく多くのゲームも) を動かせるようにします。Wine#DXVK を使用すれば、ランタイムで DirectX から Vulkan への変換もサポートし、DirectX しかサポートしていないゲームでパフォーマンスを向上させることができます。
  • 仮想マシン – ゲームと互換性のあるオペレーティングシステム (Windows など) をインストールするために使用できます。VirtualBox には優れた 3D サポートがあります。これに加えて、互換性のあるハードウェアを使用している場合は、Windows KVM ゲストへの VGA パススルー (キーワードは "virtual function I/O" (VFIO)) や OVMF による PCI パススルーも可能です。
  • Proton/DXVK – プロプライエタリな steam プラットフォームで使用するために設計された、Wine のフォークです。Wine よりも優れたゲームへのサポートを可能にします。詳細は Steam#Proton Steam-Play を参照してください。

ゲームの互換性

vm.max_map_count を増やす

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

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

2147483642 (MAX_INT - 5) は SteamOS でのデフォルト値です。Fedora では、1048576 が安全な値であるとされています [2]。

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

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

ゲームの取得

Linux で利用できるゲームであったとしても、それがネイティブに動作するとは限りません。Wine や Proton と一緒に事前にパッケージングされていることもあります。

公式リポジトリや AUR にある Arch 用にパッケージングされたゲームのリストは、ゲーム一覧 を見てください。

  • Athenaeum — Steam の代替自由ソフトウェア。
https://gitlab.com/librebob/athenaeum || athenaeum-gitAUR
  • Flathub — Flatpak の中央リポジトリ。ゲームセクションはまだ小さいですが、大きくなりつつあります。
https://flathub.org/apps/category/Game || flatpak、discover、gnome-software
  • GOG.com — DRM の無いゲームストア。
https://www.gog.com || lgogdownloaderAUR、wyvernAUR、minigalaxyAUR
  • Heroic Games Launcher — GOG と Legendary の GUI。Epic Games Launcher のオープンソースな代替ソフトウェア。
https://heroicgameslauncher.com/ || heroic-games-launcherAUR
  • itch.io — インディーゲームストア。
https://itch.io || itch-setup-binAUR
  • Legendary — Epic Games Launcher のフリーでオープンソースな代替ソフトウェア。
https://github.com/derrod/legendary || legendaryAUR
  • Lutris — Linux 用のオープンなゲーミングプラットフォーム。GOG、Steam、Battle.net、Origin、Uplay、その他多くのソースからゲームを取得できます。Lutris は、様々なゲームランナーを使用しており、完全にカスタマイズ可能な設定オプションを使用してゲームを起動することができます。
https://lutris.net || lutris
  • Play.it — ネイティブパッケージのビルドを自動化します。Wine、DOSBox、ScummVM のゲームもサポートしています。
https://www.dotslashplay.it/ || play.itAUR
  • Rare — Legendary のもう一つの GUI。PyQt5 をベースとしています。
https://github.com/Dummerle/Rare || rareAUR
  • Steam — Valve によって開発されている、デジタル配信及びコミュニケーションのためのプラットフォーム。
https://store.steampowered.com || steam

Wine のラッパーに関しては、Wine#サードパーティ製アプリケーション を参照してください。

ゲームの設定

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

マルチスクリーン環境

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

キーボード操作

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

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

ノート: 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 を起動するのが良いでしょう。注意点として、この X 設定ファイルの場所は /etc/X11 ディレクトリからの相対パスとなります。

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

ファイルを実行可能にしたら、次のようにしてスクリプトを使うことが可能です: 

$ ~/game.sh xonotic-glx
ノート: /etc/X11/xorg.conf.d 内の設定ファイルをロードさせたくない場合は、-configdir オプションを使って、空のディレクトリを指すようにすると良いでしょう。

マウス検出の調整

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

OpenAL とバイノーラル音声

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

~/.alsoftrc
hrtf = true

または、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 does not 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 の以下の行をアンコメント・編集してください: 

/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 のバッファリングに合わせる

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

リモートプレイ

クラウドゲームは、クライアント側のハードウェア要件が低いため、近年大きな人気を集めています。クラウドゲームにおいて唯一重要なことは、最低速度が 5 から 10 Mbit/s (ビデオ品質やフレームレートに依ります) の安定したインターネット接続です (イーサネットケーブル接続か 5 GHz WiFi を推奨)。

ネットワーク経由でのゲームパッドの使用を通常サポートしていないサービスで、ネットワーク経由でゲームパッドを使用する方法については、ゲームパッド#ネットワークを介して Gamepad を使う を見てください。

ノート: ブラウザで動作するサービスのほとんどは、たいてい google-chromeAUR との互換性しか保証していません。
サービス インストーラ ブラウザクライアントでの利用 自身のホストを使う ホストの貸出 フルデスクトップサポート コントローラサポート 備考
Dixper – Yes Windows のみ ? ? ? –
Reemo reemod-binAUR Chromium ベースブラウザのみ Yes Yes Yes Windows のみ ウェブサイトのダウンロードセクションにある公式インストールスクリプトでソフトウェアをインストールすることもできます。
Xbox Cloud xbox-cloud-gamingAUR Yes No No No Yes XCloud を使用するには Game Pass Ultimate が必要です。
GeForce Now – Yes No No Yes Yes このサービスを使用するには、Steam、Epic Client、あるいは GOG 上のゲームが必要です。
Moonlight moonlight-qtAUR No Yes No Yes Yes これは単なるクライアントです。ホストマシンは GeForce Experience (Windows のみ) か Sunshine (マルチプラットフォーム) を使用しなければなりません。
Parsec parsec-binAUR Yes (実験的) Windows のみ No Yes Yes クラウドホスティングはもはや利用できなくなっています[リンク切れ 2023-05-06]。
VDI Stream Client vdi-stream-clientAUR No Windows のみ No Yes No 3D GPU アクセラレーションと組み込みの USB リダイレクトをサポートしている VDI クライアント。
Playkey playkey-linuxAUR ? ? ? ? ? –
PlayStation Now Wine か Steam の Proton で動作します。 No No – No Yes PC 上で PS4、PS3、PS2 のゲームをプレイできます。あるいは、エミュレータを使うという手もあります。
PlayStation Remote Play chiakiAUR No Yes – Yes Yes PS4 や PS5 のゲームを PC でプレイできます。
Rainway 2019 Q3 に登場予定。 Yes Windows のみ No Yes ? –
Shadow 安定版: shadow-techAUR
ベータ版: shadow-betaAUR		 No No Yes Yes Yes コントローラサポートは USB over IP に依存しています。現在、AVC のみのサポートとなっており、HEVC はサポートされていません。
Steam Remote Play steam に含まれています No Yes No No Yes –
Stadia – Yes No No Yes Yes サービスは2023年1月18日に終了します。
Vortex[リンク切れ 2024-01-29] – Yes No – No ? –
VNC tigervnc or x11vnc No Yes No Yes No 汎用のリモートデスクトッププロトコル。LAN 経由でゲームする場合には、レイテンシは十分に低いはずです。ゲームパッドのサポートについては ゲームパッド#ネットワークを介して Gamepad を使う を見てください。
xrdp xrdpAUR No Yes No Yes No もう一つの汎用リモートデスクトッププロトコル。グラフィカルアクセラレーションを設定すれば、OpenGL 及び Vulkan の両方がサポートされます。LAN 経由でゲームをする場合におすすめです。ゲームパッドのサポートについては ゲームパッド#ネットワークを介して Gamepad を使う を見てください。
X11 フォワーディング openssh No Yes No No No VirtualGL による SSH 経由での X フォワーディングは OpenGL をサポートしており、全てではありませんが一部のゲームで動作します。ゲームパッドのサポートについては ゲームパッド#ネットワークを介して Gamepad を使う を見てください。
Boosteroid boosteroidAUR Yes No No Yes Yes このサービスを使用するにはデジタル配信プラットフォーム (Steam、EGS、Origin など) 上のゲームが必要です。全てのゲームが利用できるわけではありません。ゲームの完全なリストを見るにはサインアップ (無料) する必要があります。デジタル配信プラットフォーム上であなたが所有しているゲームを起動するには、サブスクリプションを購入する必要があります。
Blacknut blacknut-appimageAUR または Blacknut AppImage Yes No No Yes Yes このサービスを使用するにはサブスクリプションが必要です。全てのゲームが利用できるわけではありません。

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

メインの記事 (パフォーマンスの向上) も参照してください。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 システムにおける [4] のベンチマークでは、hpet や acpi_pm と比べて tsc のスループットのほうが約50倍良くなっています。

警告: tsc タイマーの信頼性が乏しい場合にこのタイマーを強制すると、clock_gettime(CLOCK_MONOTONIC)[5] の単調増加性 (Firefox はこれに依存しています) が破壊され、Firefox がランダムにクラッシュする原因になります。このタイマーは自己責任で使用してください!

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

リアルタイムカーネルにはデフォルトでいくつかのメリット (リアルタイムカーネルの記事を参照) がありますが、CPU のスループットが犠牲になり、また割り込み処理が遅延する可能性もあります。ちなみに、リアルタイムカーネルは nvidia-open-dkms とは互換性がなく、デフォルトのプロセススケジューリングタイプである SCHED_NORMAL (SCHED_OTHER とも呼ばれる) のプロセスのスケジューラは変更しません。以下のようにカーネルパラメータを変更すると、リアルタイムカーネルおよび他のカーネル (デフォルトの linux カーネルなど) の応答時間をさらに安定化させます:

(Transparent) Hugepage の割り当てに対する proactive compaction は、割り当ての平均時間を減少させますが、最大時の時間を減らすとは限りません。Proactive compaction は、カーネルのドキュメントによると応答時間の揺れを生じさせるので (内部での動作)、無効化してください: 

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

メモリの断片化が発生した場合にページブロック1つ (x86_64 では 2MB) だけをデフラグするようにするために、watermark boost factor を減らしてください。こうすることで、メモリの断片化の発生後、アプリケーションのデータがプロセッサキャッシュの最終レベルに残りやすくなります。 

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

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

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

RAM の空き領域が十分にある場合、アロケーション時に応答時間が増加する可能性をさらに減らすために、watermark scale factor を増やしてください (説明: [8][9])。Watermark の位置を RAM の 5% に設定するには: 

# echo 500 > /proc/sys/vm/watermark_scale_factor

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

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

Multi-Gen Least Recently Used (MGLRU) を有効化してください (小さなパフォーマンスコストでロック競合の可能性を減らします [10]): 

# echo 5 > /sys/kernel/mm/lru_gen/enabled

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

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

パフォーマンスコストの観点から Transparent HugePages (THP) を無効化してください。デフラグメンテーションが無効化されている場合でも、THP はレイテンシのスパイクを発生させるかもしれません。[11][12] madvise と advise を使用することで、アプリケーションが明示的に要求した場合に限り有効化します: 

# echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
# echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled
# echo never > /sys/kernel/mm/transparent_hugepage/defrag

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

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

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

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

# echo 0 > /proc/sys/kernel/sched_child_runs_first
# echo 1 > /proc/sys/kernel/sched_autogroup_enabled
# echo 3000 > /proc/sys/kernel/sched_cfs_bandwidth_slice_us
# echo 3000000 > /sys/kernel/debug/sched/base_slice_ns
# echo 500000 > /sys/kernel/debug/sched/migration_cost_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 # default value as of linux 6.6
w /proc/sys/vm/compaction_proactiveness - - - - 0 # 20
w /proc/sys/vm/watermark_boost_factor - - - - 1 # 15000
w /proc/sys/vm/min_free_kbytes - - - - 1048576 # 67584
w /proc/sys/vm/watermark_scale_factor - - - - 500 # 10
w /proc/sys/vm/swappiness - - - - 10 # 60
w /sys/kernel/mm/lru_gen/enabled - - - - 5 # 7
w /proc/sys/vm/zone_reclaim_mode - - - - 0 # 0 
w /sys/kernel/mm/transparent_hugepage/enabled - - - - madvise # always
w /sys/kernel/mm/transparent_hugepage/shmem_enabled - - - - advise # never
w /sys/kernel/mm/transparent_hugepage/defrag - - - - never # madvise
w /proc/sys/vm/page_lock_unfairness - - - - 1 # 5
w /proc/sys/kernel/sched_child_runs_first - - - - 0 # 0
w /proc/sys/kernel/sched_autogroup_enabled - - - - 1 # 1
w /proc/sys/kernel/sched_cfs_bandwidth_slice_us - - - - 3000 # 5000
w /sys/kernel/debug/sched/base_slice_ns  - - - - 3000000 # 3000000
w /sys/kernel/debug/sched/migration_cost_ns - - - - 500000 # 500000
w /sys/kernel/debug/sched/nr_migrate - - - - 8 # 32

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

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

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

LD_BIND_NOW=1

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

ユーティリティ

Gamemode

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

Gamescope

Gamescope は、Valve によって開発されているマイクロコンポジタです。Steam Deck で使用されています。このプロジェクトの目的は、ゲーミング向けに調整され、多くのゲーム中心の機能をサポートする独立したコンポジタを提供することです。

ACO コンパイラ

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

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

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 の点灯を変更できます。現在サポートされているデバイスのリストは、[20] を見てください。

参照

  • 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=36511」から取得