モニターのサイズはゲームのパフォーマンスに影響しますか？
新しいコンピューターを作成したばかりですが、Minecraftのプレイ中に問題が発生します。
新しいコンピューターは、32GBのRAMおよびIntelMatrixStorageを使用するRAID0の3つのWDBlack1TBドライブを備えたIneli7 3820Kです。グラフィックスカードは、1024MまたはVRAMを備えたNvidia GTX560です。 、eVGA製です。
とにかく、私が抱えている問題は、マップ上の友達のベースの近くに行くと（はい、これはサーバー上にあります）、私のキャラクター/カメラがほとんど再生できなくなることです。それは本当に途切れ途切れになり、コマンドとアクションが遅れることです。最初はネットワーク接続だけかもしれないと思っていましたが、彼の基地から離れると、すべてが再びスピードアップします。
確かに、彼は非常に狭いエリアで多くの複雑なマシンやその他の装置を実行しています。多分あまりにも多くのことが起こっていて、私のコンピューターのWi-Fiが詰まっていると思いましたが、そうではないと思います。私の友達のインターネットは私よりもかなり悪く、彼はアンティグアからのプレーに問題はなく、私はオハイオにいます。
考えられる唯一のことは、問題の原因はモニターである可能性があります。19インチのAcerディスプレイから30インチのDellUltraSharpに変更しました。マップの特定の領域の複雑さのレベルと、ゲームを実行している解像度の組み合わせが、GPUに少し負担をかけすぎて、遅れを引き起こしている可能性がありますか？
これは本当に面倒で、この問題を理解したいと思いますが、以前のコンピューターで多くの問題が発生した後、私はこれにかなり困惑しています。 SkyrimやDeusEx：HRのような他のゲームを試して、同じ問題が発生するかどうかを確認します。
これらはすべて非常に良い答えであると言うことから始めますが、時間をかけて、自分の2つの大きな画面でどのような数値を生成できるかを自分で確かめたかったのです。
少なくとも1つの回答がGPUのメモリに言及し、OPが多くのオブジェクトを含むシーンに言及しているため、さまざまなレベルのVRAM消費量を測定し、別の解像度に言及しているため、1つの画面でフルスクリーンレンダリングを実行し、それらの数値をフルスクリーンレンダリングと比較します両方の画面で。画面のスペースが2倍あるため、これはより高い解像度でより大きなモニターと考えることができます。また、同じ解像度を維持しながら、より大きな画面スペースをシミュレートする、2つのミラーリングされた画像の小さな例を実行します。
比較した数値を使用して、グラフィックカードに何が課税されるかを示すことができます。
リグ：
- Quadcore 2600k @ 5GHz
- MSI 580 GTX Lightning Xtreme
- このバージョンはMSIによって在庫よりも高くクロックされていますが、私自身はこのテストのためにオーバークロックしていません
- このバージョンには3ギガのDDR5があります
- ドライバーバージョン304.79;完全にクリーンインストール
- 16ギガDDR3システムRAM
- 1920x1080 で動作する2x32 "LEDスクリーン
- 1つはHDMIで接続され、もう1つはDPからパッシブアダプターを介してHDMI入力に接続されます
- MSI Afterburnerv2.2.1を使用してVRAMの使用状況を監視します
最初のテスト：
この最初のテストでは、アイドル状態のWindows 7Aero対応デスクトップに座ります。 Minecraftの外部でFPSを測定するユーティリティがありませんでした。
- 116〜118MBの使用量
- 両方の画面がオンで、1920x1080モード
- 89〜91 MBMBの使用量
- 1920x1080モードの1つの画面
- 78〜80MBの使用量
- 1つの画面がオンで、800x600モード
- 73〜74MBの使用量
- 両方の画面がオンで、800x600モード
-このテストは、2xモニターが2x VRAMの使用を意味しないことを示しています。したがって、フレームバッファリングだけでなく、はるかに多くのオーバーヘッドがあると予想できます。また、高解像度モードでは、1つのモニターが約77％を使用することにも注意してください。 2つのメモリ、および低解像度モードでは、1つのモニターが2つのメモリの約93％を使用し、オーバーヘッドコストをさらに例示します。 -これは、@ Huskehnの回答が誤解を招く可能性があることを意味します。つまり、解像度が高いだけではVRAMの使用に実際的な影響はありません。
2番目のテスト：
このテストでは、VLCを使用してフルスクリーンのBlu-ray再生を実行します（後世のためにTalladega Nights）。 Minecraftの外部でFPSを測定するユーティリティがありませんでした。
- 172MBの使用量
- 両方の画面がオン、単一のフルスクリーン、1920x1080モード
- 笑い声の場合、このモードで再生を8倍に増やし、2MBの使用量が増えました。
- 217MBの使用量
- ワンスクリーンオン、デュアルフルスクリーン、1920x1080モード
- 125MBの使用量
- 1920x1080モードの1つの画面
- 106MBの使用量
- 両方の画面がオン、単一のフルスクリーン、800x600モード
- 130MBの使用量
- 両方の画面がオン、デュアルフルスクリーンおよび800x600モード
- 94MBの使用量
- 1つの画面がオンで、800x600モード
-このテストで言うことはあまりありませんが、再生速度のみを変更するまで、VRAMの使用量はずっと安定していました-通常の速度に設定するとメモリ使用量は通常に戻り、フレームバッファが増加したことを示しました。もう1つのポイントは、どちらのビデオも途切れたり遅く見えたりすることはなく、3D以外のアプリケーションがいかに簡単であるかを示していることです。
3番目のテスト：
このテストでは、VirtualBoxv4.1.18を使用して2番目のモニターで32ビットWindows XP仮想マシンのフルスクリーンをオンにします。VM 128 MBのビデオメモリが与えられ（後のテストでは、VMはこれだけしか使用できない）であるとは限らないようです）、2Dおよび3Dアクセラレーションが有効になっています。
他のテストでは予測可能な違いが観察できることが示されているようであるため、いくつかのモードをスキップしました。
- 151〜156MBの使用量
- 両方の画面がオンで、1920x1080モード
- 127MBの使用量
- 両方の画面がオン、800x600モードではVM画面（およびVM自体））、1920x1080モードではホスト
-画面が@ 1080の場合、またはVMの解像度が内部で@ 800に変更された場合に、消費量が異なるかどうかは測定しませんでした。
4番目のテスト：
Minecraftをプレイ！
これにはたくさんの情報があり、おそらく@Solignisにとって最も重要なセクションです。
まず、Windowsがフルスクリーンアプリケーションを処理する方法のため、2つのMCクライアントを最大サイズで同時に実行できなかったため、前述のVM）内でもう一方を実行し、結果を測定しました。兄と私はいつもこのように並んでプレイしていて、プレイに問題はありません！次に、両方のクライアントが同じ世界をレンダリングするように、バックグラウンドでMinecraftサーバーを実行し、ほぼ同じビューを表示しました。両方のクライアントを実行し、両方のプレーヤーを同じ場所にテレポートし、同じ方向に向けてから、クライアントを閉じて以前にレンダリングされたものをすべてフラッシュし、バックアップを開始して移動しませんでした。最初にサーバーを起動しました。そして、VRAMが156MBから168MBになったことに気づきました。両方のクライアントとの最初の切断後、現在は安定した230MBが使用されていることに気付きました。サーバーも最大レンダリング距離に設定されました。
MCグラフィック設定は次のとおりです。「ファンシー」、スムーズな稲妻オン、3Dアナグリフオフ、GUIスケール自動、パーティクルALL、レンダリングFAR、パフォーマンスMAX、ボブオン、アドバンス。 OGLオフ、雲オン。ホストクライアントはadvで実行できますが。 OGLONは280fpsを超えても問題なく、これによりVMがクロールしていました。これは、VirtualBoxでの新しいOGL実装のサポートが現在制限されているためだと思います。FPSはMCから取得されました。 F3の統計。
特に明記されていない限り、すべてのテストは1920x1080で記録されました。
- 530MBの使用量@ 〜300 FPS（ホスト）
- 画面1のホストのクライアントフルスクリーン、画面2のアイドルデスクトップ、いいえVM実行中
- 530MBの使用量@ 〜305 FPS（ホスト）
- 画面1および2（重複画面）のホストのクライアントフルスクリーン、いいえVM実行中
- 482MBの使用量@ 〜330 FPS（ホスト）
- 画面1のホストのクライアントフルスクリーン、2番目の画面オフ、いいえVM実行中
- 482MBの使用量@ 〜330 FPS（ホスト）
- 画面1のホストのクライアントフルスクリーン、2番目の画面オフ、いいえVM実行中
- 480MBの使用量@ 〜430 FPS（ホスト）
- 画面1のホストのクライアントフルスクリーン、2番目の画面のアイドルデスクトップ、両方とも800x600、実行なしVM
- 547MBの使用量@ 〜250 FPS（ホスト）
- 画面1のホストのクライアントフルスクリーン、アイドルVM画面2のデスクトップ
- 408MBの使用量@ 〜70 FPS（VM）
- 画面2のVM）のクライアントフルスクリーン、画面1のアイドル状態のホストデスクトップ
- FPSは約60から始まり、ゆっくりと45に下がり、すべてのチャンクがフェッチされた後、81に上昇しました。
- 803〜805MBの使用量@ 〜200 FPS（ホスト）、@ 〜50 FPS（VM）
- 画面1のホストのクライアントフルスクリーン画面2のVM）のクライアントフルスクリーン
--MCは多くのキャッシュをキャッシュし、シーンが異なればVRAMの使用量も異なることに注意してください。そのため、多くの火と多くのピストンが動く複雑なシーンを選択しましたが、これはまだ「ベストケース」に近いシナリオです。画面の一部ではなく全体が変化しているため、より多くのものがフェッチ、キャッシュされ、特に再描画されます。ただし、これは、MCが必要なときにキャッシュをクリアしないということではありません。遠くのチャンクがレンダリングされるにつれてVRAMが着実に増加し、ホストシステムと比較してVMがブロックをロードするのにかかる時間に大きな違いがありました。復元チャンクがロードされた後のフレームレートの値は、少なくともMinecraftの場合、実際に表示するよりもフェッチで失われるFPSが多いことを示しています。最終テストでは、このセットアップの「MultiplayerChunkCache」が961であることが示され、その後、スワップが開始されますが、これはVRAMの上昇を妨げませんでした。このキャッシュは、クライアントの実行中に小さな解像度に切り替えた後、VRAMが大幅に低下しなかった理由も説明できます。
-@ Diogoによって提案されたパフォーマンスに関連して使用されているピクセル数に関して、最初の数回の実行は、ピクセル数の2倍/半分がパフォーマンスの2倍/半分に等しくないことを示しています。パフォーマンスの尺度としてFPSを使用すると、2番目の画面で何も問題が発生しなかったため、ピクセル数を半分に減らしても約10％しか得られませんでした。そこで、ディスプレイをミラーリングしましたが、VRAMの使用量は変わらず、FPSはわずかに変化しました。ホストとVMの両方で実行されているクライアントの両方を使用したテストでは、ホストもVMのMinecraftもFPSで50％低下しませんでしたが、両方で高度なフルスクリーンレンダリングが行われたにもかかわらず、約25％しか低下しませんでした。 ピクセル数はパフォーマンスにおいて実際には有用な識別子ではありません。
最終テスト：
ええと...どれだけ高いVRAMを取得できますか？！
VMとホストクライアントの両方でMinecraftのサーバーを何分も歩き回った後、物事が横ばいになり始めたときに最終的に1685 MBの使用量に達しましたハード。さらに数分後、私は1869 MBをヒットすることができました、そしてそれからそれは動揺しません。あらゆる方向にピストンがあり、私の周りに燃えるようなネザーラックがあっても。そのような高いメモリ使用量の後でも、ゲームはホストとVMの両方で100％プレイ可能でした。それぞれ〜233と〜52 FPSです。私はそれを実行しました。Minecraftをタップしました。2回。同じマシンで！
それで私はSkyrimを始めました。ホストのMCクライアントを最小化すると、VRAMは1837MBにしか低下しませんでした。
Skyrimの土地の外では、VMのMinecraftがまだ約50 FPSである間に、合計2636MBの使用量を達成することができました。 SkyrimのFPSは測定しませんでしたが、目に見えて高かったです。
ピークに達しないことに悩まされた後、Skyrimを最小化して2617 MBに落とし、DX11を使用するCiv5を開きました。ロードされると、VRAMは2884 MBに達し、Windows「Yourコンピュータのメモリが不足しています... "Javaプロセス（サーバーまたはクライアント）を指しているウィンドウですが、私のシステムRAMは9.77GBしかありませんでした保存したゲームをロードしましたが、完了しました！最大3072 MBに達しました！2番目の画面が空白になり、最初の画面が激しく点滅し始め、解像度が低下しました。カードを恐れて、すぐにPCの電源を切りましたが、「0x00で参照されていないメモリ...」に関する警告ダイアログが表示される前ではありませんでした。この時点まで、FPSは両方の画面でstill高でした。
結論：
あなたがこれまでにそれを成し遂げたならば、それから読むための称賛。これは言い方のラウンドアバウトですが、@ Solignisが抱える問題は、GPUベースまたはCPUベースではない可能性がありますが、サーバー接続が不十分であるか、Java /ヒープ設定が不十分である可能性があります。 @Philippeと@libertasは、正しい方向に進んでいます。
Minecraftのテストは800x600と1920x1080で実行され、それ自体で432％多いピクセルがあるにもかかわらず、パフォーマンスはそのような大きさでは影響を受けなかったことを示しています。
複製画面のMinecraftテストは、より大きな画面（2つの画面を組み合わせたもの）をシミュレートする方法でしたが、同じ解像度の画像1920x1080を使用し、より多くの画面スペースを使用しました。同じ解像度の別のより大きな画面があることを除けば、これはサイズだけではゲームのパフォーマンスに目立った影響を与えないであることを示す上で非常に決定的です。
デュアルMinecraftテストでは、高解像度の画像（2つの画面を組み合わせたもの）willのレンダリングがパフォーマンスに影響を与えることを示していますが、画像を2倍にしても、パフォーマンスが半分になったり、著しく遅いです。これは、小さなサイズの増加による小さな影響でゲームが非常に遅くなるために、Minecraftですでに速度が低下していることを意味します。
最終テストは、VRAMの消費量とパフォーマンスの間に関係があるかどうかを確認する方法でしたが、関係がないことがわかりました。つまり、最大VRAMに達するまで、パフォーマンスは即座に0になります。GPUが追跡している情報の量に関係なく、フレームレートに目立った影響はありませんでした。また、複数のゲームを並べて一度にプレイするなどのばかげたことを計画しない限り、3GBのビデオメモリは現世代のゲームではまったく意味がないことも間違いなく証明しました。メモリはGPUでは実質的に役に立たない仕様であり、1〜1.5GBで十分です。
Minecraftは、テクスチャのセットが1つしかないため、これらのテストに非常に適したプログラムでしたが、大規模なゲームでは、実行されている解像度に基づいてテクスチャのサイズが異なることが多く、テストを歪めるためにさまざまな変数が導入されます。マルチプレイヤーゲームであることは、ほぼ重複した画像を確実にレンダリングできたので、もう1つの恩恵でした。 MinecraftがVMの内部で実行できるほど軽量であるという事実は、極端なエッジケースを示し、2つのフルスクリーンアプリケーションを持ち、最終的にできるようになるためのもう1つの有用な利点でした。 VirtualBoxの「ビデオメモリ」設定が、a VMがホストGPUで使用できるメモリ量を実際に制限しているかどうかを判断します。
モニターのサイズは関係ありませんが、解像度は関係あります。以前のモニターよりも高解像度のモニターを使用しているため、フレームが大きいため、グラフィックカードは各フレームを保存するためにより多くのビデオメモリを必要とします。このため、モニターのフル解像度でプレイするすべてのゲームでパフォーマンスが全体的に低下することになります。ビデオカードには、より大きな画像を生成するためにやるべきことがたくさんあります。
Minecraftについては、 64ビットJava がインストールされていることを確認してください。 64ビットJavaがないと、Minecraftは使用可能なすべてのメモリを利用できず、ラグの問題の原因となる可能性があります。これが機能しない場合は、パフォーマンスを大幅に向上させることができるMinecraftのmod OptiFine を試してみることもできます。
私はあなたの質問のほとんどを読みませんでしたが、「サイズ」が「画面解像度」（ピクセル単位）を指す限り、タイトルの質問に対する答えははいです。
すべてのピクセルは、何らかの方法で個別に処理する必要があります...複雑な3Dレンダリングプログラムでは、さまざまな効果が適用されるときに、各ピクセルを何度も再計算して再処理する必要があります：シャドウ、ジオメトリシェーダー、照明、画面スペースの周囲のオクルージョン、カリング、アンチエイリアシングなど。これらの各操作は、効果的にピクセルの広い範囲（または実際には画面上のすべてのピクセル）を調べて、その色要素（赤/緑/青またはその他の配置）を変更する必要があります。
幅と高さの成分が対称的に増加する場合、画面上のピクセル数は増加します二次関数的に。したがって、単純な数値を使用するには（これらは一般的に使用されている実際の解像度ではありません）：500x500の画面があり、1000x1000の画面にアップグレードした場合、ピクセル数は2倍になるだけでなく、ピクセル数も増えます。もともと持っていた、4倍。したがって、500 * 500（乗算）は250,000です。 1000 * 1000は1,000,000です。これを論理的に極端に考えて、32000x24000のような解像度を見た場合、既存のグラフィックハードウェアがこのような高解像度でかなりのフレームレートで最新のゲームをプレイできるかどうかは正直わかりません。数字はそれほど大きくは見えませんが、32000に24000を掛けると、非常に複雑になり、処理するデータも多くなります。とてつもない量！
モニターの物理的なサイズは重要ではありません。画面の解像度（ピクセル数）直接パフォーマンスに影響します。データが多い（ピクセルが多い）ほど、レンダリングの各段階での処理が増えるためです。
グラフィックカードやモニターではなく、Java/Minecraftのように聞こえます。サーバーはVanillaまたはbukkitを実行していますか？
確かに、彼は非常に狭いエリアで多くの複雑なマシンやその他の装置を実行しています
これらの矛盾の周りで遅れを経験しているのはあなただけですか、それとも他の人も同様ですか？これは本当に良いことですが、他の設定でラグの問題がありますか？お使いのマシンがMinecraftの推奨値をはるかに上回っていることを考えると、これがハードウェアの問題であるとは非常に疑わしいです。他の人が同じ問題を抱えている場合は、bukkitパフォーマンスプラグインが適切である可能性があります。
（私は Minecraftサーバーを実行します。 ）
Huskehnが指摘しているように、64ビットJavaを実行していることを確認し、OptiFineを試してみてください。ただし、Optifineを実行していて、Radeonを実行しているときに大きな改善が見られたことを知らせてください。 HD 5770ですが、そのカードが最近おかしな動作を開始し、GTX 550 Tiを入手したとき、Optifineを取り外してバニラに戻すまで、Minecraftで奇妙なちらつきの問題が発生していました。
また、高度なOpenGL設定で遊んでみてください（Vanillaに戻った後は、ONが最適に機能していました）。
サイズ自体は影響しませんたとえば、2つの異なるモニターを比較する際に低解像度（800x600など）を使用している場合、影響はありません。ただし、画面の解像度が影響します：
たとえば1366x768などのより高い解像度を使用する場合、レンダリングされた各フレームには、ビデオカードがモニターに送信するために「作成」する必要がある800 * 600 = 480000ピクセルではなく、1366 * 768 = 1049088ピクセルが含まれることを意味します。この簡単な例に従うと、（理論的には）1366x768の解像度を使用すると、パフォーマンスが約45％低下することがわかります。
解像度を上げた場合（19 "から30"への切り替えで発生する可能性が高い）、はい、グラフィックカードが生成するピクセルをはるかに多く処理する必要があるため、パフォーマンスが低下します。しかし、あなたのスペックでは、主にMinecraftで問題は発生しないはずです。ほとんどの場合、この正確なサーバーまたはゲーム自体への接続に問題があります（Minecraftが少し遅い/パフォーマンスが最高ではない場合がよくあります）。 SkyrimまたはDeusXで同じ問題が発生する場合は、グラフィックカード（仕様ではなく、カード自体）に問題がある可能性があります。通常、それほど強力なカードを使用して大画面に切り替えると、それほど遅くなることはありません。