Minecraft java edition. При прогрузке чанков используется видеокарта или процессор?

Па
4

На своем древнем ноутбуке запускаю Minecraft. В win 7 x64 fps 0-2. Что грузит - не ясно. Поставил легкую версию Linux mint. Fps скакнули под 15-30, но при прогрузке чанков падает-таки до нуля. У меня два варианта: оптимизировать 1) процессор или 2) видеокарту. Српзу и то, и то не желательно. Так вот, что выбрать, где прирост fps будет больший.
(Замена комплектующих невозможна).

Ва

Для чанков процессор, для графики и шейдеров видеокарта

Ма

Согласен с Васей

Ег

Для чанков конечно процессор потому что видеокарта нужна для выведения кадров а процессор все данные пропускает через себя и чанки грузит

Ал

Преимущественно процессор и оперативка, но и видеокарта тоже участвует.

Разберём подробнее, как работает алгоритм загрузки чанков, и откуда берётся нагрузка в процессе его работы:

• Игрок пересекает границу чанка. Внутренний сервер определяет новые чанки и, если они уже сгенерированы, начинает читать их данные, загружая их в ОЗУ. Это происходит довольно быстро, но скорость чтения зависит от степени сжатия данных (можно настроить в моде C2ME). Процесс тоже недолгий, однако низкая скорость работы оперативной памяти может в этот момент привести к кратковременным зависаниям. С этим поможет FerriteCore:

Если же чанки ещё не сгенерированы, в ход вступает движок, отвечающий за генерацию мира. Он вычисляет и записывает каждый блок в чанке сразу в оперативную память, минуя ПЗУ (чанки сохраняются позднее, при выгрузке или при общем сохранении мира). Однако это колоссальная нагрузка на ЦП, и при пересечении границы чанка в одиночной игре это основной источник лагов, так как приоритет для генерации у игры очень высокий. Процесс генерации можно кратно ускорить за счёт распараллеливания вычислений при помощи C2ME:

Для слабых устройств в настройках этого мода стоит понизить приоритет и поточность генерации, чтобы она не вызывала задержек.

• Затем игра запускает в работу серверную часть светового движка, который запускает с максимальной высоты "луч света", определяя уровень освещения для КАЖДОГО блока воздуха в чанке. Можно догадаться, насколько это ресурсозатратный процесс, ведь каждый такой луч не просто учитывает наличие/отсутствие каждого из 65 536 блоков в чанке (в действительности меньше, но не суть), но просчитывает смешивание уровня освещения с соседними блоками, кратно увеличивая время работы алгоритма. Это один из самых затратных по ресурсам процесс, и во многом именно он является причиной лагов при загрузке чанков. Очень хорошо нагрузку на световой движок можно увидеть при помощи мода LightBench: github.com/Spottedleaf/lightbench.
Существует мод от того же разработчика, который полностью переписывает алгоритм расчёта освещения, в десятки раз ускоряя его - Starlight. Об этом я писал здесь:
Данные об освещении отправляются на клиент.

• После завершения обработки света начинается процесс пре-рендеринга.
На этом этапе процессор обновляет всю 3D-модель местности с учётом новых полигонов, отсекая невидимые субчанки и грани блоков. Хотя этот процесс и выполняется на процессоре, он относится уже к графическому движку игры и сильно ускоряется при помощи мода Sodium (альтернативный графический движок):

• Затем снова в дело вступает световой движок, но уже его клиентская часть. Он распознаёт серверные данные освещения и совместно с графическим движком генерирует "карты освещения", которые вместе с обычными текстурами накладываются на 3D-модель. Это тоже задача ЦП, но лишь в математическом её исполнении. Графическая обработка 3D-модели выполняется графическим движком на видеокарте.

• Финал. Обновлённая модель местности обрабатывается на видеокарте по инструкциям графического движка. И от его оптимизированности зависит время отрисовки кадра. Sodium ускоряет это за счёт функций новых версий OpenGL и собственных оптимизаций.

Таким образом, тут важно всё, и почти все этапы можно оптимизировать. Об этом я писал здесь