これら 4 つの問題に直面するまでは、NAS からゲームをストリーミングすることは素晴らしいアイデアのように思えました。

NAS を単にストレージとして使用するだけでなく、もっと面白いことができないか試してみたかったのです。そこでゲームを実行し、ローカル ネットワーク経由で別のコンピューターにストリーミングすることにしました。NAS がレンダリングを処理し、クライアントが表示とコントロールを処理するようにしました。私は TerraMaster F4–425 Pro NAS を使用し、専用のゲーミング PC の代替として使用するのではなく、ハードウェアに適合するゲームに重点を置きました。

Steam リモート プレイが私の始まりです

必要な設定はほとんどありません

私が Steam リモート プレイから始めたのは、それが Steam ライブラリの当然のオプションだったからです。 Steam にはすでにこの機能が含まれているため、ゲームのテストを開始する前に別のストリーミング スタックを構築する必要はありませんでした。 PC で直接ゲームをプレイする場合、コンピュータはフレームをレンダリングし、ディスプレイに直接送信します。リモート プレイでは、ホストは出力をキャプチャし、エンコードして、ネットワーク経由で送信し、クライアントからの入力を受信する必要があります。次に、クライアントはビデオをデコードして表示します。

Steam はそのほとんどを自動的に処理します。したがって、実験の最初の部分をストリーミング システムの構成に費やすのではなく、NAS が実際にゲームを実行できるかどうかに集中できました。

その後、ストリーミングできる内容をより詳細に制御したかったため、Sunshine と Moonlight に移行しました。 Sunshine は汎用ストリーミング ホストを提供し、Moonlight は幅広いデバイス用のクライアントを提供します。 Sunshine ではアプリケーションを直接起動することもできるので、Steam 経由で動作するゲームに限定されませんでした。この柔軟性は役に立ちましたが、それに伴う技術的な作業もさらに多くなります。

サンシャインはゲームストリーミングにどれだけ関わっているかを教えてくれました

オーディオはあまり目立たない問題の 1 つでした

私は当初、Sunshine を主にビデオ ストリーミング アプリケーションとして考えていましたが、オーディオも扱う必要がありました。ホストには、Sunshine がキャプチャしてクライアントに送信できるオーディオ ソースが必要ですが、ヘッドレス NAS では、スピーカーやモニターがすでに接続されている通常のデスクトップよりも複雑になります。

Sunshine は、仮想オーディオ デバイスを含むさまざまなオーディオ構成をサポートします。 Linux では、適切な PulseAudio または PipeWire シンクの選択が必要になる場合があります。従来のゲーミング PC には、すでにディスプレイとオーディオ デバイスが接続されています。ネットワーク上のどこかにある NAS は、通常、ゲーム ストリーミングをすぐに行えるように構成されていません。

同じ問題がディスプレイ キャプチャにも当てはまります。 Sunshine はヘッドレス構成をサポートしていますが、完全にヘッドレスの Linux ゲーム ホストを動作させるには追加の構成が必要です。これらの部分が機能すると、セットアップははるかに面倒ではなくなりましたが、実際の作業の一部でした。

遅延がネットワーク遅延を超えていることに気づきました

エンコードと表示には独自の遅延が追加されます

私が最初にゲーム ストリーミングについて考えたとき、主にネットワーク接続を検討しました。使用してみて、ネットワークはレイテンシー バジェットの一部にすぎないことに気づきました。

ゲームは最初にフレームをレンダリングする必要があります。 Sunshine はそれをキャプチャしてエンコードします。ネットワークはそれを Moonlight に運び、クライアントはそれをデコードしてディスプレイに表示します。その後、私の入力は反対方向に伝わる必要があります。また、V-Sync では別の表示間隔が導入されますが、バッファリングにより追加の遅延を犠牲にしてネットワークのジッターを滑らかにすることができます。したがって、同じネットワークでも設定によって感じ方が大きく異なることがわかりました。

また、ストリームとディスプレイを適度な一致するリフレッシュ レートに保つとエクスペリエンスが管理しやすくなりますが、積極的な V-Sync またはバッファリング設定では、応答性と引き換えにスムーズな出力が得られることにも気付きました。これが、私がこのセットアップを対戦シューティング ゲームよりもストラテジー ゲームや RPG に使用する方がはるかに快適である理由の 1 つです。

軽量の Steam ゲームが最も簡単なターゲットでした

古くて要求の低いタイトルでははるかに良い結果が得られました

ストリーミング側が機能するようになったら、NAS ハードウェアにとって現実的なゲームのテストを開始しました。 『Stardew Valley』、『Terraria』、『FTL: Faster Than Light』、『Into the Breach』、『Vampire Survivors』、および『Balatro』は、私が正当化するのがはるかに簡単だと感じた種類のゲームでした。 Half-Life 2 や Portal 2 などの古いゲームも、1080p で 60 fps でスムーズに動作します。

Lutris と Heroic も試しましたが、Wine と Proton の互換性は依然として個々のゲームに依存していました。 Destiny 2 などのタイトルは、アンチチート要件により依然として問題が発生していますが、異常なランチャーや Windows への依存関係を備えたゲームでは追加の作業が必要になる可能性があります。

私にとって最も説得力のあるゲーム ワークロードはエミュレーションでした。 RetroArch は、NES、SNES、Game Boy、Game Boy Advance、Sega Genesis、PlayStation などのシステムのさまざまなエミュレータ コアで使用できました。これは、各マシンで個別のライブラリを維持するのではなく、ゲーム ファイル、セーブ、エミュレータ構成を一元管理できるため、NAS のアイデアとうまく機能しました。

ただし、ハードウェア要件はシステムによって大きく異なるため、「エミュレーション」という言葉には注意する必要があると言わざるを得ません。 SNES エミュレータの実行は、RPCS3 の実行とはまったく異なります。 RPCS3 は PlayStation 3 をエミュレートし、最新の CPU パフォーマンスと Vulkan 対応グラフィックス ハードウェアに大きく依存しています。同様に要求が厳しい Ryujinx も試してみましたが、私には効果がありませんでした。また、エミュレータによって重要な CPU パフォーマンスが異なることもわかりました。エミュレータのワークロードが少数の高速 CPU コアに大きく依存している場合、コアを増やしても弱いシングル スレッド パフォーマンスは自動的に補正されません。

ゲームが NAS のワークロードを変えた

熱と資源の競合を考慮する必要がありました

ゲームのワークロードも、通常 NAS が処理すると予想していたものとは大きく異なりました。 NAS は、比較的短い CPU バースト、ストレージ操作、ネットワーキング、コンテナ、およびバックグラウンド サービスの処理に多くの時間を費やすことがあります。ゲームを継続的に実行すると、CPU またはグラフィックス ハードウェアの負荷が大幅に高まり、追加のエンコード ワークロードによってその圧力が増大します。

したがって、ゲームを無料の追加サービスとして扱うのではなく、温度とファンの騒音を考慮する必要がありました。 NAS が他の作業を同時に処理している場合、これはさらに重要になります。単独でゲームをしている間は完璧にパフォーマンスを発揮するマシンでも、ファイルの提供、コンテナの実行、バックアップの実行、または仮想マシンのホストを同時に行うと、動作が異なる場合があります。

また、最初にリソース使用率を確認せずに、ストレージを大量に使用する操作中に重いゲームを実行することにも抵抗があります。ゲームのワークロードは、NAS の他の部分が依存しているのと同じ CPU、メモリ、場合によっては GPU リソースと競合します。 NAS がすでに稼働しているという理由だけで、これは無視できない機会コストです。

GPU パススルーによりリモート ゲーム PC に早変わり

専用の GPU が関与すると、このアイデアを正当化するのがはるかに難しくなることがわかりました

また、NAS 上にゲーム VM を配置し、そこに GPU を渡すという、より野心的なアプローチも試しました。私は古い NVIDIA GeForce GTX 1070 8GB を使用しましたが、テストしていた軽量ゲームを十分に処理できました。 VM を実行することは難しい部分ではありませんでした。この問題は、パススルー GPU を通常のグラフィックス カードのように動作させようとしたときに始まりました。システム ファームウェアで IOMMU を有効にし、GPU とそのオーディオ機能を別個の PCI デバイスとして識別し、VM が起動する前にホストが NVIDIA ドライバーをロードしていないことを確認する必要がありました。ホストが最初にカードを要求したとき、VM はカードを適切に初期化できませんでした。

また、ヘッドレス VM でよくある表示の問題にも遭遇しました。 GPU は物理的にゲストにパススルーされましたが、それに接続されたモニターはありませんでした。結局、ダミーの HDMI プラグを使用し、期待されるディスプレイ解像度が表示されるようにゲストを構成する必要がありました。 HDMI オーディオ機能は GPU と同じ PCI デバイス グループに属していたため、オーディオについても別途注意が必要でした。

最終的に VM を実行すると、正常に動作しましたが、NAS 内で完全な Windows ゲーム マシンを維持することになりました。中古のゲーム PC から入手できるものと比較すると、同じ GTX 1070 を搭載したデスクトップでは、あまりにも多くのものをまとめる必要がなくプレイできます。

ゲーミング PC の代替としてではなく、集中ホストとして使用します。

セットアップ全体を終えた後、私の NAS の最も役立つ役割は、複数のデバイスからアクセスしたい軽量の PC ゲームやエミュレーターをホストすることだと思います。 NAS がすでに稼働していて、予備のリソースがある場合、この配置は理にかなっています。リビングルームのマシンにすべてをインストールする必要がなく、クライアントは小規模で安価なままで済み、集中ライブラリが得られます。最新のゲームをプレイするためだけに GPU を購入し、ゲーム VM を構築し、パススルーの問題を解決し、仮想オーディオおよびディスプレイ デバイスを構成し、ストリーミング スタックを調整する必要がある場合、私は NAS を完全にスキップして、代わりにゲーミング PC を購入するでしょう。