aTNO

aTNO

一个过度复杂的优化整合包，专为26.1.2版本使用Fabric制作。

香草+

一个完全正常的优化整合包

aTNO（或简称“完全正常的优化整合包”）是一个专门为 26.1.2 版本制作的过度复杂的优化整合包，它试图在不牺牲太多基础质量的前提下进一步推动优化。

免责声明： 此整合包专为中高端 PC 设计，在低端 PC 上可能比原版表现更差（尚未测试）。

第二项免责声明： 在手机上运行效果更差（在一加 9 Pro 上测试过）。

数据

项目 原版 aTNO¹ Fabulously Optimized² Remarkably Optimized² Adrenaline² 胜者
平均 FPS³ ⁸ 232 344 281 283 280 aTNO
1% 低帧平均 FPS³ ⁸ 未修改 120-138 180-200 130-168 180-200 FO / Adrenaline
平均 Tick 时间 (ms)³ 14.8-16.2 7-7.7 11-12 12.5-13 11-12.5 aTNO
平均 CPS (chunky)⁴ 未修改 644.31 113.92 384.59 468.04 aTNO
加载时间 (秒)⁵ 6 15 11 10 9 原版
世界创建时间 (秒)⁶ 18 10 20 10 10 aTNO / RO / Adrenaline
内存占用 (MB)⁷ 580 650 670 520 450 Adrenaline
  1. 使用的是 Vulkan 版本
  2. 使用了这些整合包的最新 26.1.2 版本
  3. 测试是在 32 个区块的渲染距离和模拟距离下，不限制 FPS，并注视海洋进行的
  4. 使用了此命令：/chunky start minecraft:overworld circle 0 0 2500 2500
  5. 从点击启动到主菜单（未计算淡入时间）
  6. 从点击创建世界到完全加载完成（使用了 F3 + 2 图表）
  7. 创建新世界并等待其完全加载后（垃圾回收后）
  8. 取决于模组/整合包（此处是否适用未知），1% 低帧可能是假的

此测试使用了 Ryzen 5 5500、GTX 1060 6GB、6GB 分配内存、一块 SATA SSD，并在 CachyOS 系统上使用 1440p 显示器进行。

版本

该整合包有 3 个版本，每个版本都有所不同，因此选择最适合您的版本总是好的。

Vulkan 版本：

Vulkan 版本利用了 Vulkan、OpenCL 和 Rust 等多种先进技术，以在现代硬件上获得最佳效果。如果您的 PC 足够新且 GPU 有足够的余量用于 OpenCL 使用（请参阅高级部分中的 OpenCL 硬件建议），请使用此版本。

Sodium 版本：

Sodium 版本停留在 OpenGL 领域，使用 Sodium，不涉及 Vulkan、OpenCL 或 Rust。如果您的 PC 不够新、性能不够强大，或者您更喜欢 OpenGL，请使用此版本。

服务端版本：

服务端版本专为服务端制作（例如，通过自托管或服务端托管），它移除了与客户端相关的优化，这些优化在此场景下无关紧要。请仅在服务端使用此版本（不要在客户端上使用）。

问答

它与原版客户端/服务端兼容吗？

是的，它与原版客户端/服务端完全兼容。

我该如何使用您的整合包（不仅仅是为了游玩，如果你明白我的意思）？

您可以将我的整合包作为您自己整合包的基础（非强制要求，但如果您说明了使用了它，那就太好了），可以分叉它，可以用它来进行比较（注明使用的版本），以及基本上任何其他用途（除了抄袭，抄袭可不是好行为）。

将整合包作为基础时，我应该检查什么？

首先，由于兼容性原因，您需要在 Vulkan 和 Sodium（或服务端）之间做出选择，然后您需要测试模组之间的不兼容性。

我可以在哪里提出建议或报告错误？

您可以在 Discord 服务器上提出建议或报告错误（或者我想也可以在 CurseForge 评论区，尽管我在那里的活跃度可能比 Discord 还低）（此外，您也可以只是加入 Discord 服务器而不提出任何建议或报告错误，这样至少我在服务器里就不是一个人了）。

JVM 参数与 GC 选择 (Java 25)

JVM 参数和 GC 的选择可能很重要，在不同的选项之间进行选择可以改变游戏体验。

Garbage-First (G1) 垃圾回收器 (GC)

自 Java 9 起，G1 垃圾回收器（或简称 G1 GC）一直是 Java 的默认垃圾回收器，它在吞吐量和延迟之间取得了平衡。

以下是我推荐的 JVM 参数：

-XX:+UnlockExperimentalVMOptions -XX:+UseG1GC -XX:G1NewSizePercent=20 -XX:G1ReservePercent=20 -XX:G1HeapRegionSize=16M -XX:+ParallelRefProcEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+UseStringDeduplication -XX:InitialCodeCacheSize=16M -XX:ReservedCodeCacheSize=384M -Xss2M --enable-preview --enable-native-access=ALL-UNNAMED

Z 垃圾回收器 (ZGC)

ZGC 是一个可扩展的低延迟垃圾回收器，其目标是实现近乎零延迟并支持数 TB 级别的堆大小。

以下是我推荐的 JVM 参数：

-XX:+UseZGC -XX:+ParallelRefProcEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+UseStringDeduplication -XX:InitialCodeCacheSize=16M -XX:ReservedCodeCacheSize=384M -Xss2M --enable-preview --enable-native-access=ALL-UNNAMED

Shenandoah GC

Shenandoah GC 同样是一个专注于低延迟的垃圾回收器，它类似于 ZGC，但更侧重于不是特别巨大的堆大小。

以下是我推荐的 JVM 参数：

-XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGarbageThreshold=25 -XX:ShenandoahMinFreeThreshold=20 -XX:+ParallelRefProcEnabled -XX:+ExplicitGCInvokesConcurrent -XX:+UseStringDeduplication -XX:InitialCodeCacheSize=16M -XX:ReservedCodeCacheSize=384M -Xss2M --enable-preview --enable-native-access=ALL-UNNAMED

对比表

特性 G1 GC ZGC Shenandoah
暂停行为 通常 20–200ms 通常 0.1–0.5ms 通常 1–5ms
吞吐量 高 中 中
延迟目标 中等 强 强
启动时间 快 中等 中等
支持的堆大小 大（最高约 4 TB） 非常大（数 TB） 中等（约 2 TB）
并发压缩 部分 完整 完整
内存开销 基准（约 10% 余量） 比 G1 GC 高 15–30% 比 G1 GC 高 10–20%
吞吐量成本 基准 比 G1 GC 低 5–15% 比 G1 GC 低 5–10%
CPU 开销 基准 +5–10% +5–15%

（感谢 javacodegeeks）

高级

本节本该放在 <details> 标签中，但 CurseForge 不支持，所以只能是一大堆不隐藏的文字。

本节包含 6 个部分：

  • OpenCL 硬件建议（来自 C2ME OpenCL）： 这部分基本是 C2ME OpenCL 的兼容性矩阵。
  • 测试硬件： 这部分提供更多关于测试所用系统的详细信息。
  • 模组参数： 这部分说明了模组配置文件中的更改及其原因。
  • 修改过的模组： 这部分说明了我如何以及为何修改了 StateStream。
  • GPU 工作负载与 P-State（仅限 NVIDIA 和 Vulkan 版本）： 这部分说明了 Vulkan 版本与 NVIDIA GPU 之间的特定交互。
  • 模组列表： 这部分列出了所有使用的模组（任何版本），并附有链接和作者。

OpenCL 硬件建议（来自 C2ME OpenCL）

最低硬件要求

  • 可用的 OpenCL 1.2+ 驱动程序
  • 支持 cl_khr_fp64（fp64 支持）

推荐硬件（基于 C2ME OpenCL 对 1200CPS+ 的建议，请谨慎参考）

独立 GPU：

  • Nvidia GTX 1060 或更高型号
  • AMD Radeon RX 6500 XT 或更高型号
  • Intel Arc B570 或更高型号

集成 GPU：

  • 不知道，抱歉各位

加分项

  • 可用的 OpenCL 3.0 驱动程序
  • 用于稳定设备匹配的 cl_khr_device_uuid
  • 用于最佳性能的 CL_QUEUE_OUT_OF_ORDER_EXEC_MODE_ENABLE。在 AMD GPU 上不可用。
  • 用于队列优先级的 cl_khr_priority_hints 和 cl_khr_throttle_hints。已知仅在 Intel GPU 上存在。
  • 非均匀工作组，在 Nvidia GPU 和一些 AMD GPU 上不可用。

平台兼容性矩阵

  • 支持： 已知通常完全正常工作。
  • 部分支持： 已知可以工作，但存在一些重大限制。
  • 不支持： 已知完全无法工作。
  • N/A： 不适用，因为该组合不存在。
厂商 世代 驱动 Windows Linux MacOS
NVIDIA Maxwell 及更新 专有和开源 支持 部分支持¹ 未知
NVIDIA Kepler 专有 未知 支持 未知
NVIDIA 更老的显卡 任意 未知 未知 未知
NVIDIA nouveau 支持的 GPU Rusticl on nouveau N/A 未知 N/A
Intel Gen9, Gen9.5⁵ 官方² 部分支持³ 部分支持⁴ 未知
Intel Gen11, Gen12, Gen12.5⁶ 官方² 不支持¹² 不支持¹² 未知
Intel Gen12.7, Xe2, Xe3 及更新⁷ 官方² 部分支持³ 部分支持⁴ 未知
Intel 更老的核显 官方² 未知 未知 未知
Intel iris 支持的 GPU Rusticl on iris N/A 未知 N/A
AMD RDNA1 及更新¹⁴ 官方⁸ 支持⁹ 支持 未知
AMD GCN 官方¹⁰ 不支持¹³ 不支持¹³ 未知
AMD radeonsi 支持的 GPU Rusticl on radeonsi N/A 部分支持¹¹ N/A
Qualcomm 任意 官方 不支持¹² 不支持¹² N/A
Apple 任意 MacOS 驱动 N/A N/A 不支持¹²
Apple 任意 Rusticl on asahi N/A 未知 N/A
  • ¹ 已知该驱动运行一段时间后会挂起。535 LTS 驱动分支似乎工作正常。
  • ² Windows 上的官方驱动包。Gen9 和 Gen9.5 需要最新的驱动：Gen9 下载链接，Gen9.5 下载链接。对于 Linux：https://github.com/intel/compute-runtime。
  • ³ 已知 GPU 在几乎所有非原版世界生成中会崩溃。您的体验可能有所不同。
  • ⁴ 已知 GPU 在某些复杂的世界生成数据包（如 Terralith）中会崩溃。您的体验可能有所不同。
  • ⁵ Gen9 和 Gen9.5 是第 6 至 9 代酷睿处理器以及第 10 代非 G 系列酷睿处理器中的集成显卡。
  • ⁶ 这里的 Gen11、Gen12 和 Gen12.5 是第 10 代 G 系列酷睿处理器、第 11 至 14 代酷睿处理器以及 Arc DG1、Arc A 系列中的集成显卡。
  • ⁷ Gen12.7 指的是 Meteor Lake 和 Arrow Lake 的集成显卡。此时，它涉及 Core Ultra 100 系列及以上的集成显卡，以及 Battlemage 及以上的独立显卡。
  • ⁸ Windows 上的官方驱动包。Linux 上的 ROCm 运行时。
  • ⁹ 已知驱动版本 26.5.1 总是崩溃。升级到 26.6.1+ 的现有安装也可能崩溃。如果您在 26.6.1+ 上遇到崩溃，建议使用 DDU 然后进行全新安装。
  • ¹⁰ Windows 上的官方驱动包。Linux 上的 AMDGPU-Pro 运行时。
  • ¹¹ 已知 Mesa 26.1.x 分支在 RDNA3/4 上可工作。任何硬件组合都可能发生任何事情，包括损坏的世界生成。您的体验可能有所不同。
  • ¹² 缺少 FP64 支持。
  • ¹³ 驱动崩溃。
  • ¹⁴ 不包括 Ryzen 7000 系列和 9000 系列的集成显卡。它们对于此任务来说太慢了。

（感谢 ishland）

测试硬件

简略：

  • 操作系统：CachyOS
  • 主板：B550M Phantom Gaming 4
  • CPU：AMD Ryzen 5 5500
  • GPU：GTX 1060 6GB
  • 分配内存：6GiB
  • 磁盘：SSD
  • 启动器：PrismLauncher
  • Java：Azul Zulu JRE 25

详细：

  • 操作系统：CachyOS x86_64
  • 主板：B550M Phantom Gaming 4
  • 内核：linux-cachyos-bore-lto
  • Sched-ext 调度器：Lavd（游戏模式）
  • 显示器：2560x1440，120 Hz
  • 桌面环境：KDE Plasma
  • 窗口管理器：KWin (X11)
  • CPU：AMD Ryzen 5 5500 (12) @ 4.46 GHz
  • PBO：+200MHz
  • 核心降压：-6mV
  • GPU：NVIDIA GeForce GTX 1060 6GB
  • GPU 驱动：nvidia-580xx-dkms nvidia-580xx-settings nvidia-580xx-utils opencl-nvidia-580xx
  • 内存：31.21 GiB
  • 交换空间：33.21 GiB
  • 最小分配内存：1GiB
  • 最大分配内存：6GiB
  • 磁盘 (/)：110.00 GiB - btrfs
  • 压缩：ZSTD 级别 3
  • 启动器：PrismLauncher
  • Java：azul_zulu_jre25.0.3

模组参数

一些模组配置已被修改，所以我在这里说明（总体上）修改了什么以及为什么修改。

Async

  • enableAsyncSpawn 从 false 改为 true

为什么？为了减少实体生成时的卡顿。

Async Particle

  • "gpuAcceleration" 从 true 改为 false
  • "appendNewParticlesToRenderer" 从 true 改为 false

为什么？为了修复 Vulkan 和 Async Particle 之间的一个错误，该错误会导致在粒子数量较多时出现严重卡顿。

Beryl

  • "shadersOn" 从 true 改为 false

为什么？不强制所有人使用光影。

C2ME

  • threadPoolPriority 从 "default" (4) 改为 3
  • maxConcurrentChunkLoads 从 "default" (24) 改为 8
  • chunkSendingSpeedMultiplierPercentage 从 "default" (200) 改为 0
  • gcFreeChunkSerializer 从 "default" (false) 改为 true

[openclAccel]

  • allowIncompatibilityFallback 从 "default" (false) 改为 true

为什么？更快且减少卡顿的区块创建/加载，同时也启用了回退机制。

Fast Noise

  • tree 从 false 改为 true

为什么？避免在生成时多次调用线程。

Ixeris

  • aggressiveCaching 从 false 改为 true
  • keyboard 从 false 改为 true

为什么？提升事件轮询性能。

Modernica

  • perfChunkMeshing 从 true 改为 false
  • perfDeduplicateClimateParameters 从 false 改为 true
  • perfDeduplicateLocation 从 false 改为 true
  • perfNetworkEnhancements 从 true 改为 false
  • perfNetworkOptimizations 从 true 改为 false
  • perfRemoveBiomeTemperatureCache 从 true 改为 false
  • perfResourcepacks 从 true 改为 false
  • perfWorldgenAllocation 从 true 改为 false

为什么？为了模组/数据包兼容性和降低资源占用。

ServerCore

features:

  • prevent-moving-into-unloaded-chunks 从 false 改为 true
  • xp-merge-radius 从 0.5 改为 1
  • item-merge-radius 从 0.5 改为 1

lobotomize-villagers:

  • enabled 从 false 改为 true

Optimizations.yml

  • fast-biome-lookups: true

为什么？为了减少计算 Tick 的时间。

Structure Layout Optimizer

  • "deduplicateShuffledTemplatePoolElementList" 从 false 改为 true

为什么？让结构布局生成略微更快。

StateStream

  • update_culling_enabled 从 true 改为 false

为什么？因为 json 文件不起作用（或者是我笨，这两种可能都存在）。

TwinSession

  • autoOp 从 true 改为 false
  • spawnNearPlayer 从 true 改为 false

为什么？如果你和朋友一起玩过，你懂的，你懂的……

修改过的模组

对于整合包的 Vulkan 和 Sodium 版本，我不得不修改 StateStream 以使其也能在单人游戏中使用，以下是所做的修改：

  • 抑制了 quilt.mod.json（不知道为什么）
  • 修改了 fabric.mod.json 中的 "environment"：从 "server" 改为 "*"

GPU 工作负载与 P-State（仅限 NVIDIA 和 Vulkan 版本）

这部分更关心 NVIDIA GPU 方面。

通常，在 Minecraft 中，GPU 会自动从 P8-P5 状态切换到 P0 状态（最大性能）。但在 Vulkan 版本上，GPU 并不会如预期那样切换到 P0，而是切换到 P2 状态（工作负载模式）。

这是因为 NVIDIA 驱动检测到了 OpenCL 实现，并自动按预期切换到 P2 状态。

这通常不会对性能产生太大影响（在 Minecraft 中看不出差异），但显存时钟会比在 P0 状态下更低。

模组列表