Я начну с того, что это все очень хорошие ответы, но я хотел потратить время и лично убедиться, какие числа я смогу сгенерировать на своих двух больших экранах.
Поскольку хотя бы в одном ответе упоминалась память графического процессора, а в ОП упоминались сцены со многими объектами, я буду измерять различные уровни потребления видеопамяти, а после другого упомянутого разрешения я буду выполнять полноэкранный рендеринг на одном экране и сравнивать эти числа с полноэкранным рендерингом. на обоих экранах. Это можно считать монитором большего размера с более высоким разрешением, поскольку площадь экрана в два раза выше. Я также сделаю небольшой пример двух зеркальных изображений, имитирующих большее пространство экрана при сохранении того же разрешения.
Используя сравниваемые цифры, я могу продемонстрировать, на что платит видеокарта.
Рог:
- Quadcore 2600k при 5 ГГц
- MSI 580 GTX Lightning Xtreme
- Эта версия работает на MSI выше, чем стоковая, но я сам не разгонял ее для этого теста
- Эта версия имеет 3 гигабайта DDR5
- Версия драйвера 304.79; полностью чистая установка
- 16 гигабайт оперативной памяти DDR3
- 2x 32 "светодиодные экраны с разрешением 1920x1080
- Один подключен через HDMI, другой подключен от DP-выхода через пассивный адаптер к HDMI-входу
- Я буду следить за использованием VRAM с помощью MSI Afterburner v2.2.1
Первый тест:
В этом первом тесте мы просто сядем за рабочий стол с поддержкой Windows 7 Aero. У меня не было утилиты для измерения FPS за пределами Minecraft.
- 116-118 МБ использования
- Оба экрана включены и в режиме 1920x1080
- Использование 89-91 МБ
- Один экран включен, и в режиме 1920x1080
- Использование 78-80 МБ
- Один экран включен, и в режиме 800x600
- Использование 73-74 МБ
- Оба экрана включены и в режиме 800х600
- Этот тест показывает, что 2x мониторы НЕ означают 2x использования VRAM, поэтому можно ожидать, что накладных расходов намного больше, чем просто буферизация кадров, и также стоит отметить, что в режиме высокого разрешения один монитор использует ~ 77% память двух, а в режиме низкого разрешения один монитор использует ~ 93% памяти двух, что дополнительно иллюстрирует накладные расходы.
- Это означает, что ответ, который дает @Huskehn, вводит в заблуждение, поскольку только более высокие разрешения не оказывают практического влияния на использование VRAM.
Второй тест:
В этом тесте VLC используется для полноэкранного воспроизведения Blu-ray (Talladega Nights, для потомков). У меня не было утилиты для измерения FPS за пределами Minecraft.
- 172 МБ использования
- Оба экрана включены, один полноэкранный и в режиме 1920x1080
- Для хихиканья я увеличил воспроизведение до 8x в этом режиме и увидел увеличение использования на 2 МБ
- Использование 217 МБ
- Один экран включен, двойной полноэкранный режим и режим 1920x1080
- 125 МБ использования
- Один экран включен, и в режиме 1920x1080
- 106 МБ использования
- Оба экрана включены, один полноэкранный и в режиме 800x600
- 130 МБ использования
- Оба экрана включены, двойной полноэкранный и в режиме 800x600
- 94 МБ использования
- Один экран включен, и в режиме 800x600
- Мало что можно сказать об этом тесте, за исключением того, что использование VRAM все время оставалось стабильным, пока я не изменил только скорость воспроизведения - использование памяти вернулось к нормальному, если установить постоянную скорость, что указывало на увеличение кадрового буфера. Еще одно замечание: ни одно из видео не стало нестабильным и не выглядело медленно, показывая, как не-3D-приложения тривиальны.
Третий тест:
В этом тесте я буду включать полноэкранный режим 32-разрядной виртуальной машины Windows XP на моем втором мониторе с использованием VirtualBox v4.1.18. Виртуальной машине было выделено 128 МБ видеопамяти (что, как представляется, последующие тесты не обязательно доказывают, что виртуальная машина может использовать только это), и было включено ускорение 2D и 3D.
Я пропустил несколько режимов, так как другие тесты, кажется, показывают предсказуемую разницу.
- 151-156 МБ использования
- Оба экрана включены и в режиме 1920x1080
- 127 МБ использования
- Оба экрана включены, экран виртуальной машины (и сама виртуальная машина) в режиме 800x600 и хост в режиме 1920x1080
- Я не измерял, было ли другое потребление, когда экран был @ 1080, или когда разрешение виртуальной машины было внутренне изменено на @ 800
Четвертый тест:
Играем в Майнкрафт!
В нем много информации, и, вероятно, это самый важный раздел для @Solignis.
Во-первых, из-за способа, которым Windows обрабатывает полноэкранные приложения, я не смог запустить два клиента MC в максимальном размере одновременно, поэтому я запустил другой внутри ранее упомянутой виртуальной машины и измерил результаты. Мы с братом все время играем бок о бок, и у нас никогда не возникает проблем с игрой! Во-вторых, я запустил сервер Minecraft в фоновом режиме, чтобы оба клиента отображали один и тот же мир и почти идентичный вид. Я запустил оба клиента, телепортировал обоих игроков в одно и то же место, посмотрел их в одном направлении, а затем закрыл клиенты, чтобы сбросить все ранее отрендеренные, затем запустил их обратно и не переместил их. Сначала я запустил сервер и заметил, что объем виртуальной памяти увеличился с 156 МБ до 168 МБ. После первого разрыва соединения с обоими клиентами я заметил, что теперь используются постоянные 230 МБ. Сервер также был настроен на максимальное расстояние рендеринга.
Графические настройки MC были следующими: "Причудливый", плавное включение молнии, 3D анаглиф выключен, масштабирование GUI AUTO, частицы ALL, рендеринг FAR, производительность MAX, боббинг ON, adv. OGL OFF, облака включены. Хотя хост-клиент может работать с adv. OGL ON чуть более 280 кадров в секунду, это вызывало ползание виртуальной машины. Я полагаю, что это из-за ограниченной поддержки новых реализаций OGL в VirtualBox. FPS был взят из MC по статистике "F3".
Все тесты были записаны в 1920x1080, если не указано иное.
- Использование 530 МБ при ~ 300 FPS (хост)
- Полный экран клиента в хосте на экране 1, рабочий стол в режиме ожидания на экране 2, виртуальная машина не работает
- Использование 530 МБ при ~ 305 FPS (хост)
- Полноэкранный режим клиента на хосте на экранах 1 и 2 (дублированный экран), виртуальная машина не работает
- Использование 482 МБ при ~ 330 FPS (хост)
- Полный экран клиента на хосте на экране 1, второй экран выключен, виртуальная машина не работает
- Использование 482 МБ при ~ 330 FPS (хост)
- Полный экран клиента на хосте на экране 1, второй экран выключен, виртуальная машина не работает
- Использование 480 МБ @ ~ 430 FPS (хост)
- Полноэкранный клиент на главном экране 1, второй рабочий стол, 800x600, виртуальная машина не запущена
- Использование 547 МБ при ~ 250 FPS (хост)
- Полный экран клиента в хосте на экране 1, рабочий стол виртуальной машины в режиме ожидания на экране 2
- Использование 408 МБ при ~ 70 FPS (ВМ)
- Полноэкранный режим клиента в виртуальной машине на экране 2, рабочий стол хост-компьютера на экране 1
- FPS начал около 60, затем медленно упал до 45, а затем поднялся до 81 после того, как все куски были получены
- Использование 803-805 МБ @ ~ 200 FPS (хост), @ ~ 50 FPS (виртуальная машина)
- Полноэкранный клиент в хосте на экране 1, полноэкранный клиент в виртуальной машине на экране 2
- Обратите внимание, что MC кэширует много, и разные сцены будут вызывать разное количество использования VRAM, поэтому, хотя я выбрал сложную сцену с большим количеством огня и движением многих поршней, это все еще почти сценарий «наилучшего случая», так как осмотр будет вызвать намного больше вещей, которые будут извлечены, кэшированы и особенно перерисованы, потому что меняется весь экран, а не только несколько частей. Однако это не означает, что MC не будет очищать кэш, когда это необходимо. Вы можете наблюдать постоянное увеличение VRAM по мере рендеринга удаленных фрагментов, и была огромная разница во времени, которое потребовалось виртуальной машине для загрузки блоков по сравнению с хост-системой. Восстановление частоты кадров после загрузки чанков демонстрирует, что, по крайней мере, для Minecraft больше FPS теряется при извлечении вещей, чем при их отображении. Финальный тест показал, что «MultiplayerChunkCache» для этой настройки равен 961, и затем он начинает менять местами, но это не мешало росту VRAM. Это кэширование также может объяснить, почему не было значительного падения VRAM после переключения на меньшее разрешение, пока клиент еще работал.
- Что касается количества пикселей, используемых по отношению к производительности, как предложено @Diogo, первые несколько прогонов показывают, что удвоение / половина количества пикселей не равно удвоению / половине производительности. Используя FPS в качестве показателя производительности, удалось получить только около 10%, сократив количество пикселей вдвое, поскольку второй экран не представлял ничего сложного. Затем я отразил свои дисплеи, и использование VRAM не изменилось, и FPS изменился в основном. В тестах с клиентом, работающим на хосте, а также с виртуальной машиной, ни хост, ни Minecraft не потеряли 50% в FPS, а вместо этого только примерно на 25%, несмотря на расширенный полноэкранный рендеринг на обоих, так что количество пикселей не очень полезный идентификатор в производительности.
Финальный тест:
Ну ... насколько высоко VRAM я могу получить ?!
После многих минут блуждания по моему серверу в Minecraft как на виртуальных машинах, так и на хост-клиентах, я, в конце концов, использовал 1685 МБ, когда все начало сильно выравниваться. Еще через много минут я смог набрать 1869 МБ, и тогда он не сдвинулся с места. Даже с поршнями в разные стороны и огненной чертой вокруг меня. Даже после такого ВЫСОКОГО использования памяти игра все еще игралась на 100% как на хосте, так и на виртуальной машине; ~ 233 и ~ 52 FPS соответственно. Я сделал это Я вытащил Minecraft. Дважды На одной машине!
Итак, я запустил Skyrim. Когда я свернул клиент MC своего хоста, мой VRAM только уменьшился до 1837 МБ.
Вне страны Скайрима мне удалось получить в общей сложности 2636 МБ памяти, в то время как Minecraft VM все еще работал со скоростью ~ 50 FPS. Я не измерял FPS Скайрима, но он был заметно высоким.
Раздраженный отсутствием пика, я свернул Skyrim, опустившись до 2617 МБ, и открыл Civ 5, использующий DX 11. Как только он был загружен, мой VRAM увеличил размер до 2884 МБ, и мне было предложено открыть окно «У вашего компьютера недостаточно памяти ...», которое указывало на процесс Java (сервер или клиент), однако системная память была только 9,77 ГБ из 16. Я загрузил свою сохраненную игру, и она сделала это! Я получил максимум 3072 МБ! Мой второй экран стал пустым, и мой первый экран начал яростно мигать и имел уменьшенное разрешение. Опасаясь за свою карту, я быстро выключил компьютер, но не раньше, чем увидел какое-то диалоговое окно с предупреждением «Необращенная память в 0x00 ...». До этого момента FPS оставался высоким на обоих экранах.
Вывод:
Если вы сделали это так далеко, то слава для чтения. Это обходной способ сказать что-то, но проблема, с которой сталкивается @Solignis, вряд ли основана на GPU или CPU, но, возможно, плохое соединение с сервером или недостаточные настройки Java/heap. @Philippe и @libertas находятся на правильном пути со своими ответами.
Тесты Minecraft, выполненные в 800x600 и 1920x1080, сами по себе показывают, что, несмотря на увеличение пикселей на 432%, производительность не пострадала с такой величиной.
Тест Minecraft с дублированным экраном был способом имитации экрана большего размера (два экрана объединены), но с использованием изображения с тем же разрешением, 1920x1080, только с использованием большего пространства на экране. Если не считать другого, более крупного экрана с тем же разрешением, это очень убедительно, поскольку показывает, что один только размер не оказывает заметного влияния на производительность игры.
Двойные тесты Minecraft показывают, что рендеринг изображения с более высоким разрешением (два экрана вместе) будет влиять на производительность, но удвоение изображения не уменьшит производительность вдвое и не сделает ее заметно медленной. Это подразумевает, что вы уже испытываете медлительность в Minecraft, чтобы небольшое влияние небольшого увеличения размера сделало игру очень медленной.
Заключительный тест позволил выяснить, существует ли связь между потреблением VRAM и производительностью, и я обнаружил, что такой связи нет. То есть до тех пор, пока вы не достигнете максимального значения VRAM - тогда ваша производительность мгновенно падает до 0. Независимо от того, сколько информации отслеживает графический процессор, она не оказывает заметного влияния на частоту кадров. Я также доказал, что, без сомнения, если вы не планируете делать смешные вещи, такие как одновременная игра в несколько игр, то 3 ГБ видеопамяти абсолютно бессмысленны в нынешнем поколении игр; Память - это практически бесполезная спецификация на GPU, а 1-1,5 ГБ подойдет любому более чем достаточно.
Minecraft был очень хорошей программой для этих тестов, потому что существует только один набор текстур, в то время как большие игры часто могут иметь текстуры разного размера в зависимости от того, в каком разрешении он запускается, что может привести к различным переменным для искажения тестов. Многопользовательская игра была еще одним благом, поскольку я смог надежно отобразить почти дублированное изображение. Тот факт, что Minecraft достаточно легок для запуска внутри виртуальной машины, был еще одним полезным преимуществом, поэтому я смог продемонстрировать крайние крайние случаи, иметь два полноэкранных приложения и, наконец, определить, действительно ли параметр VirtualBox "Видеопамять" на самом деле ограничено, сколько памяти виртуальная машина может использовать на своем графическом процессоре.
