FSX/P3D環境のチューニング その4 メモリ不足とは

oom2016012901

概要

本記事はその3に続く内容だが、チューニングそのものは前回の記事で十分だ。
今回は、メモリについて記載する。
※2016年1月29日 初版を記載している。
※2017年6月3日 Prepar3D v4に合わせて改版

 

最初に

32bitのFSX/Prepar3D v1/v2/v3で、メモリが足りないとエラーが表示されるからといって16GBや32GBのメモリをパソコンに積むのは、解決策にならない。
もちろんシミュレータ以外で多用途で同時に使い必要な場合は別である。

この記事では実際のメモリが足りない理由について読み解いていこう。
それで足りないと判断されるなら、追加を行うのが良い。
恐らくその場合は現在のメモリ搭載量がPrepar3D v3以前では4GB以下であることが多いだろう。
またPrepar3D v4.0以降では必要な分だけ追加する必要がある。

 

メモリ不足とはどのようなものがあるか?

この言葉には、3つの意味がある。

  • 論理的なプロセス実行容量が足りない
  • 物理的なRAMが足りない
  • VRAMが足りない

そのどちらであるかを認識することで、チューニングそのものやパーツ交換の選択に意味がでてくる。またFSX/Prepar3D v3で頻繁にでる問題だ。今回の記事では、使用量と判断基準についても説明を行っている。

epwa-load-inside01

 

RAMが足りないとはどういう状況か?

実はこれ自体も2種類がある。

  • パソコンに搭載されているメモリが足りない
  • プログラム1つが利用できる最大サイズに達している。

大抵は画面表示がされなくなったり、この画面のようなメッセージが表示されるが、場合によっては突然何も表示せずにダウンすることもある。これは通称OOM(Out Of Memory)と呼ばれる。

epwa-load-outside06

epwa-load-outside07

 

パソコン全体のメモリ使用量

メモリ使用量の確認方法について。タスクマネージャからパフォーマンスタブを見た場合はこのような表示になる。
青枠がパソコン全体に割り当てられているメモリの全体量だ。

例えて言うならば、スーパーの駐車場の広さ。この画像の場合は、青枠内の8GBがそれだ。

oom2016012903

まずはここが足りているか確認が必要だが、方法は簡単だ。
フライトシミュレータで重い空港やシーナリーをロードしている状態で、赤枠内の「利用可能」にメモリが0.5GBを切るようになると、ほぼメモリが足りない状況と言える。
これも駐車場と同じで、空きが無ければ移動のやりくりもできなくなるから注意する。
この考え方は、32bit版のFSX/Prepar3D v1/v2/v3でも同じだし、64bit版のPrepar3D v4以降でも同じだ。

oom2016012905

 

パソコンに搭載できる最大搭載量

最大搭載量は、OS毎に異なる。

  • Windows 10 32bit版
    最大4GB
  • Windows 10 64bit版
    最大128G~512GB

結論から先に言ってしまうと、32bit版のWindowsではアドオンを多くインストールしたFSX/Prepar3Dを稼働させるのはかなり厳しいということになる。OS+シミュレータ+その他で4GBに収める必要があるからだ。
これはこれから記載するプログラムのサイズとも関係する。

 

プログラム(プロセス)の実行時最大サイズ

次にシミュレータのプログラム自体の使用しているサイズだ。
これには4つのパターンがある。
なお、FSXもPrepar3D v3も32bitプログラム(OSのビット数は関係ない)だ。

  1. 32bit OSで32bitプロセスを動かす場合 – デフォルト設定時
    2GB(2048MB)
  2. 32bit OSで32bitプロセスを動かす場合 – PAE(/3GB)設定時
    3GB(3072MB)
    ※後述のリンカーオプションによる。
  3. 64bit OSで32bitプロセスを動かす場合
    2GB(2048MB)もしくは、4GB(4096GB)
    ※後述のリンカーオプションによる。
  4. 64bit OSで64bitプロセスを動かす場合
    8~128TB – 事実上の無制限。物理的に積んだ分だけ利用可能。

Windows10 64bit版で32bitのプログラムであるFSXとPrepar3D v3.4を動かしている場合は、3.の4GBになる。
また、64bit版であるPrepar3D v4以降は4.の8~128TBとなる。プログラム側で制限を書けない限り、OS側としてはこの通りだ。

ちなみにX-Planeの64bit版も4.となる。

1.と2.はWindows 2003/XP世代のため、現在はサポート期限が終了しており、事実上の対象外とする。古い資料を見て設定を悩むのではなく、さっさと新しい64bitのOSを利用するべき。

2.も3.もプログラムをソースからコンパイルし、リンカーでリンクする時に”IMAGE_FILE_LARGE_ADDRESS_AWARE”が指定されるかどうかで決定される。
Prepar3D v3の場合は、同指定がされていると考えられる。

上記リストの一次資料はこちら。PAEの公式解説はこちら

 

プログラム実行最大サイズの簡単な考え方

このサイズは車1台分のスペースの大きさで、プログラムが車のサイズと考えてよい。
なお3GB設定は古いハードウェアやマイナーなアプリケーションは正しく動かなくなる可能性があるので、設定すればOKというわけではない。

どんなに駐車場が広くても、プログラムは駐車スペース1台分のサイズを超えて駐車することができない。簡単なことだ。

正確な値を見るには、Process Explorerを利用し、Virtual Sizeも表示して正確な値を最終的には確認する。これが3GBを確実に超えないようにする。
※概要を確認する際に使いやすいツールは後半に紹介する。

この場合は、2658,444KB = 2596MBで、4096MBには達していないのでまだ余裕がある状態だ。

p3dv3perf04

これも駐車場に例えてみよう。駐車スペースギリギリでは車は移動ができない。
文字通り、クラッシュしてしまう可能性が大きい。目安として常に10%は最低限残るようにしよう。
チューニング時はメモリを大きく使用する機体アドオンや空港アドオンをロードしている時は、注意深く観察するのが望ましい。

例えば、この画像の環境は一つ前の画像のメモリ使用量となっているが、PMDG B777 for Prepar3Dをロードするとクラッシュしてしまうことが多い。3GBに達してしまうからだ。

oom2016012905

64bitで速くなるって本当?

ある意味YES。ある意味NO。
作業場所たるメモリが足らないことで、荷物(データ)を往復するロスがある場合は、YES。
効率よく作業ができれば、速くなる。
既に効率よく出来ているなら、ほぼ変わらない。

しかし計算速度では、整数+-約20億の範囲に収まる計算はあまり変わらない。
浮動小数点の計算も同様だ。
8bitから16bitや、16bitから32bitへの変更は、+-128を超える値、+-約32000を超える値の計算の際に速くなることはあったが、それは桁あふれの処理をするためだ。
現在の事務処理やフライトシミュレータでは、20億を超える整数はあまり取り扱わない(皆無ではないが)から、これはほぼNOだ。何倍も速くなるようなことは無い。

CPUの演算性能での謎の”ビット信仰”は、昭和生まれ世代(筆者含む)が1980~1990年代に体験した過去の事なので、大抵は無視してよい。
平成世代は気にしなくて良いし、説明が無い「速くなる」という言葉は無視してよい。
技術的な段階的なアップと利用シーンがその当時フィットして速くなっただけだ。

 

遅くなることも?

極端な例だが、大きな広場(メモリ)がより広くなると、手が届く机の上(CPUキャッシュ)に配置できるものの数は限られているので、計算は少し遅くなるということもありえる。
これはプログラムの書き方次第ではある。キャッシュの使い方をうまくできるようにコードを書くと10倍足になるような例は頻繁にあるのだ。ただし、これは大抵はあまり気にしなくても良い。

 

VRAMが足りないとはどういう状況か?

これは基本的には1種類だ。

  • グラフィックボード内のメモリか少ない

ただしグラフィックボードを搭載していないパソコンではRAMからVRAMを切りだして使っているので、32bit OSで3GBのメモリを最大に使いつつ描画も綺麗にするというのはサイズとして不可能なのだ。

VRAMが足りないとどうなるかというと、テクスチャや3Dオブジェクトが読み込みきれずに半端な表示なってしまう。
真っ黒であったり、そもそも物体が表示されなったりする。

oom2016012904

 

VRAMの使用量のチェックは?

こちらもProcess Explorerで確認できる。
これもRAMと同様にフライトシミュレータが重い状況で確認する。
ツール上では”GPU Decicated Memory”の値が大凡90%の範囲を超えていないかがポイントだ。
これがグラフィックボードに積まれているメモリの使用率になる。

参考程度だが、”GPU Usage”とはグラフィックボードの負荷率だ。
CPU使用率と同様である。

epwa-load-outside05

 

筆者の場合はワルシャワ市と同市内にあるショパン空港が、負荷の大きい空港だが、ここで調べている。
PMDG B777をロードするとダウンするので、AEROSOFT A320でロードした際の画面だ。
この場合は、最大値に達しておらず落ちていない。
※本画面では別のツールでの値を表示しているが、見れる内容は同じものだ。

epwa-load-outside04

VASを簡単に確認できるツール

FSX及びPrepar3Dに限って言えば、“projectFLY Pilot Tools”の利用がお薦めだ。
ダウンロードはソフト名を選んで、画像をクリックするだけだ。
作者にDonate(寄付)をしたいところだが、”Paypal”での寄付は、現在では日本国内のPaypal利用規約に反するようだ。

便利なツールであるし、シミュレータ本体とは別プロセスで動くので特別影響を与えない。
そのため、OOMの確認用として常時起動をお薦めする。EXE.XMLに記載すると良いだろう。
下記はその例だ。

計測を開始するときは、”CONNECT”ボタンをクリックする。

すると、利用量のみならず空き容量の把握も簡単にできる。

例で示そう。Prepar3D v3.4の最初のエグリン空軍基地でF-22で出現した状態だ。
※各種アドオンは入っている。

別機体を読み込むと次のようになる。
700MBほど利用量が増えた。これが機体のメモリ使用量差という事になる。

本ソフトでは、設定は2つだけある。
シミュレータ起動時に常に上に表示するかを決めるオプション(赤枠内)。
そしてもう一つが、”Audio Alearts”だ。
これは音声でVASの残が少ないことを知らせてくれる。

今度はチューニングの結果の例を示そう。
ワルシャワ・ショパン空港で、FS LabsのA320-Xで出現してみた例だ。
ワルシャワ市街地のデータもあるので、筆者の環境では思い部類に入る空港だ。
まだメモリに余裕があるのが分かる。

 

まとめ

最初に書いた例でまとめてみよう。下記のようになる。

  • パソコン全体のメモリが足りない
    他プログラムを並行して沢山起動せずに駐車スペースを空ける。
    使っていないプログラムを閉じる。ブラウザでやたらと多くタブを開かない。それでも足りなければ、メモリを増設や交換をする。
    32bit OSの場合は64bitへの移行を考えるのも手だ。
    ただし32bitから64bitへのアップデートはできず、OSから再インストールなのでデータ移行に苦労するだろう。
  • プログラム1つが利用できる最大サイズに達している
    VASの最大に達している場合は、手の打ちようはない。
    アドオンの読み込み数(シーナリーライブラリでのオン/オフ)や、テクスチャの精度を下げる等使用量を下げる努力をするか、Prepar3D v4以降への移行を検討する。
  • VRAMが足りない
    ビデオカードを買い替える、もしくはテクスチャを精度の低いものに変えたりする。
    3Dのオブジェクトを沢山表示しないようにする。
    最近のグラフィックボードは4GBを搭載していることも多いが、筆者の環境は3GBで大規模なアドオンが複数ある地域を飛ぶと足りなくなることがある。

epwa-load-outside01

現在の環境を見て、パソコンの買い替えや部品の交換・追加を行う判断材料を見つけないと、せっかく購入しても変化が無いこともあり得るので気をつけたほうが良い。

ここまで読んだ方は、理解できると思うが、Photoshopを開きながら、別のアプリでビデオ編集している途中でフライトシミュレータを起動するといった酷使をしないかぎり、16GB搭載のPCを使ってもあまり変化はない。単に気にしなくてよいというだけだ。

それよりもフライトシミュレータではビデオカードのVRAM容量も大事であるということも確認・認識いただきたい。よく忘れられている要素である。

FSX/P3Dチューニング