Nvidia RTX Mega Geometry 2.0 以按需流式传输取代固定几何数据

Nvidia 已发布 Nvidia RTX Mega Geometry 2.0，为超出显卡可用 VRAM 容量的光线追踪场景加入按需几何流式传输功能。该 SDK 不再要求所有源网格始终驻留于内存，而是在既定内存预算内选择连续的细节层级簇。

这种区别颠覆了一项熟悉的图形权衡。开发者不必再认定某个场景规模过大、无法进行光线追踪；他们可以让渲染器在影响最小的位置降低几何细节，同时保留镜头附近的较高细节。

此次更新发布于《Gears of War: E-Day》10 月 6 日发售前两周。Nvidia 表示该游戏使用 RTX Mega Geometry。不过，Nvidia 和开发商 The Coalition 均未公开确认该游戏使用的是 2.0 版本或其新的流式传输路径。

Nvidia RTX Mega Geometry 2.0 改变了必须装入 VRAM 的内容

关键变化并非又一次提升三角形容量，而是为每一帧决定哪些三角形值得占用内存提供了新方式。

Nvidia 推出 RTX Mega Geometry 的初衷，是降低为高细节、基于簇的网格构建光线追踪加速结构的成本。2.0 版本通过连续 LOD 流式传输扩展了这一设计。

连续细节层级，即 continuous LOD，会将网格组织为由小型几何簇构成的层级结构。渲染器可在同一个物体的不同区域选择不同细节级别，而不是在几个固定模型之间整体切换。

选定的簇会按需流式传入 VRAM。靠近镜头的几何数据可以使用高密度簇，远处或部分被遮挡的区域则获得较低细节。这形成的是持续变化的工作集，而不是永久保留每个源网格的副本。

Nvidia 在 SDK 更新日志中以异常直接的措辞概括了这一转变：场景的源几何数据不再需要装入 VRAM，而显示细节则由分配的内存预算限制，而非总网格数量限制。

这并不意味着 GPU 能够渲染无限量的几何数据。它意味着源数据可以大于可用显存，因为任一时刻只需让其中经过选择的一部分驻留。

当需求超出配置的预算时，系统会选择较低细节的簇。它不依赖于反复驱逐和重新加载完整网格——这种模式可能导致卡顿、帧时间不稳定或几何数据缺失。

默认示例配置为流式网格数据分配 2GB VRAM，另为光线追踪加速结构预留 2GB，并为材质纹理预留 4GB。开发者可根据自身内容和目标硬件调整这些分配。

这些数字是示例设置，并非通用要求。正式发售的游戏必须在几何数据与纹理、光照数据、渲染目标、帧生成资源以及共享同一内存池的其他所有内容之间取得平衡。

Nvidia 将 2.0 版本与 RTX Kit 2026.3 一同发布，但 RTX Mega Geometry 仍是该套件中的独立 SDK。同期 RTX Kit 更新还涵盖神经纹理、角色渲染、动态照明、神经着色和纹理过滤。

新的 SDK repository 包含参考路径追踪器，以及 Direct3D 12 和 Vulkan 的实现。它目前支持 Windows 构建，旨在为引擎开发者提供学习和集成资源。

该仓库提供两条几何路径。Cluster LOD 处理通过连续层级选择的预烘焙三角形簇；cluster tessellation 则在渲染期间动态细分并置换表面。

两条路径可以在同一场景内运行。这种灵活性很重要，因为刚性的建筑网格、发生变形的表面和高密度角色资产，未必都能从同一种表示方式中受益。

因此，2.0 版本改变了开发者面临的实际问题。旧问题是完整的光线追踪表示能否装入内存；新问题是在受控工作集内能维持多少可见几何细节。

Zorah 示例展示了规模与取舍

Nvidia 的演示之所以令人印象深刻，是因为其源场景远大于驻留网格分配量；但它仍是由厂商控制的示例，而非独立基准测试。

核心演示使用了 Nvidia 华丽路径追踪场景 Zorah 的带纹理 glTF 导出文件。可下载资源包含 16 亿个独特三角形，实例化后三角形数量达到 189 亿个。

它还包含 2,034 个网格和 4,357 张纹理。下载包约为 70GB，解压后约包含 31GB 网格数据和 48GB 纹理。

这些数字让内存问题一目了然。没有任何传统消费级显卡能够同时让整个资产包、其渲染结构以及现代引擎的其余部分全部驻留。

Nvidia 公布的截图显示，在 GeForce RTX 5090 上以 4K、DLSS Quality 运行时，帧时间为 15.5 毫秒。画面中包含 5,600 万个独特三角形和 7.78 亿个实例化三角形。

对于该帧，示例报告约有 1.5GB 驻留网格数据和 2.3GB 簇加速结构。相较于源场景的总几何规模，这是显著的缩减。

不过，这一对比需要谨慎解读。源资产、驻留几何数据、实例化三角形数量和加速结构描述的是不同事物，不应将其视为可互换的内存效率指标。

实例化会复用重复物体的几何数据。因此，场景可以报告极高的实例化三角形数量，而无需为每个三角形储存独立副本。

同样，1.5GB 驻留网格数据这一数字并不包含生成该帧所需的全部资源。材质、纹理、光照状态、渲染目标、降噪缓冲区和引擎系统都会额外消耗 VRAM。

示例中的 15.5 毫秒结果同样来自运行 Nvidia 自身参考应用的 RTX 5090。它无法说明 2.0 版本在旧款 GPU、主机级硬件，或包含模拟和特效的完整游戏中的表现。

该演示所证明的是其机制：31GB 的源网格包可以供给规模小得多的驻留几何集，因为渲染器会为当前视角选择合适的簇层级。

当分配的预算无法在所有位置保留最高细节时，视觉上的取舍便会显现。远处、被遮挡或较不重要的表面，会先于附近的焦点几何数据使用更粗糙的簇。

这通常优于直接舍弃整个物体，或在大型网格载入内存时发生卡顿。然而，这依然代表一种画质取舍，选择算法的质量因此变得至关重要。

较差的选择策略可能导致明显的过渡、不稳定的轮廓，或镜头移动时的细节变化。良好的策略应将损失放在玩家最不可能注意到的位置。

Nvidia 对层级 Z 缓冲的使用有助于完成这种选择。层级 Z 缓冲会以多种分辨率汇总场景深度，使渲染器能够识别被更近表面遮挡的几何数据。

随后，系统可降低被遮挡簇的细节，而不是将内存耗费在对最终画面贡献很少或毫无贡献的表面上。这种方法将几何质量直接与可见性联系起来。

更困难的情况包括纤细轮廓、反射表面、快速变化的视角，以及经过多次光线反弹后可见的几何数据。光线追踪可能与镜头并不直接可见的物体发生交互。

因此，开发者在分配细节时必须考虑主画面以外的内容。低细节物体仍可能在反射、阴影或间接光照路径中显著出现。

Zorah 示例表明，这一架构能够处理极端的受控场景。正式发售的游戏将决定：在动画、破坏、流式加载、战斗和不可预测的玩家移动环境中，同样的选择能否保持稳定。

Nvidia Geometry Streaming 如何重建光线追踪工作集

RTX Mega Geometry 2.0 将光线追踪几何数据视为受预算控制的工作集，而非游戏源资产的固定副本。

光线追踪依赖加速结构，使 GPU 无需让每条光线与每个三角形逐一测试便能找到交点。底层加速结构，即 BLAS，会组织与物体或网格关联的几何数据。

当场景包含许多高密度物体或频繁变化的几何数据时，传统工作流程可能变得昂贵。重建大型结构会消耗处理时间，而保留它们则会消耗内存。

RTX Mega Geometry 将高密度网格拆分为更小的簇。它可以构建名为 CLAS 的簇加速结构，并在更大的光线追踪层级中组合或复用它们。

2.0 版本的 Cluster LOD 路径在运行时之前便已开始。开发者会将源网格烘焙为包含不同细节层级几何簇的连续层级结构。

在每一帧中，遍历代码会使用投影尺寸、距离、可见性和配置的内存预算等因素评估该层级，随后选择适合当前视角的簇。

所需簇进入驻留网格缓存。已不再有价值的簇可以离开，使工作集随镜头和场景变化而变化。

Nvidia 还使用 BLAS 共享、缓存和合并。这些技术旨在随着所选簇变化，限制构建更大加速层级的成本。

由此形成的管线类似于用于光栅化的虚拟化几何系统，尤其是 Unreal Engine 5 的 Nanite。两种方法都会将复杂网格分解为簇，并根据屏幕空间需求选择细节。

Nvidia 明确将原始技术定位为一种加速 Nanite 等基于簇系统加速结构构建的方法。其最初的 RTX 概览将跨帧压缩与缓存描述为设计核心。

这种相似性也有边界。Nanite 的核心任务是光栅化虚拟化几何数据，而 RTX Mega Geometry 专注于让光线与高密度几何数据相交所需的加速结构。

同时使用两者的游戏，仍需协调两种表示方式，或通过其引擎将它们整合。可见的光栅化表面和可供次级光线使用的几何数据必须保持足够接近，以避免光照或反射不匹配。

这种协调正是该技术的重要性超越头条三角形数量的原因之一。高密度几何数据已在光栅化场景中变得实用，但以同样细节进行光线追踪会带来额外的内存和更新成本。

后备网格经常用来弥合这一差距。游戏可以光栅化高密度模型，同时让光线与简化表示相交，以降低负担，但代价是几何精度。

这种差异可能出现在反射、阴影、环境光遮蔽和间接光照中。主画面中可见的微小表面特征，可能不存在于光线追踪结构中。

RTX Mega Geometry 试图让可见几何体与用于追踪的几何体保持更紧密的对应关系，同时无需让最高细节层级的表示始终完整驻留在内存中。

最初版本已支持基于簇的加速结构、动态细分和置换表面。Nvidia 的 Vulkan 示例也在 2.0 版本将其整合进主 SDK 前，演示了连续 LOD 概念。

2.0 版本将流式传输路径变为参考实现中核心且可实际使用的一部分。它包含资产烘焙、层级遍历、缓存和场景级预算管理，而不是只留给开发者零散的技术示例。

这才是真正的进步。如果每家工作室都必须自行构建配套的内容管线和内存管理器，硬件功能或 API 扩展的价值就会十分有限。

该 SDK 为引擎团队提供了一套可供研究的具体架构。他们可以直接采用、修改其中的组件，或将其作为专有系统的性能参考。

集成仍将需要大量工作。工作室必须处理资产、管理存储带宽、协调材质流送、调校质量阈值，并在受支持的 GPU 上测试过渡效果。

他们还必须决定系统应如何平稳扩展。在高端 Blackwell GPU 上看似稳定的配置，在较早的 RTX 显卡上可能需要不同的簇预算或质量目标。

Nvidia 表示，该 SDK 支持 Windows 上的 Direct3D 12 和 Vulkan。底层技术可运行于 RTX 20 系列以来的 RTX GPU，而 Blackwell 则针对 Mega Geometry 提供了专门的硬件和 RT Core 优化。

这种广泛兼容性有助于实验，但兼容并不意味着性能相同。各代产品上的实际价值将取决于构建吞吐量、内存带宽、缓存行为和场景复杂度。

真正的对手是固定驻留，而不是另一家 GPU 厂商

核心竞争在于固定驻留的光线追踪几何体，与接受可变细节的流式、预算受限表示之间的较量。

人们很容易将 Nvidia RTX Mega Geometry 2.0 描述为 Nvidia 与 AMD 的又一轮竞争。但这种比较为时尚早，因为该公告没有提供等效的跨厂商测试或统一工作负载。

更有意义的比较涉及渲染架构。传统光线追踪管线假设所需的几何体表示及其加速结构能够装入可用内存预算。

开发者可以简化资产、限制参与光线追踪的物体、使用后备网格，或降低场景密度来满足这一假设。每种选择都会在内容管线的某处设定固定上限。

流式传输改变了这个上限。源场景可以变得更大，因为渲染器只维护经过选择的几何工作集。

代价是细节变得有条件。它取决于当前视角、可用预算、层级结构质量，以及新簇抵达的速度。

这呼应了图形技术更广泛的变化。现代引擎越来越多地对资源进行虚拟化，而不是将纹理和几何体视为必须始终完全驻留的单体资产。

虚拟纹理将大型纹理划分为页面，只加载所需区域。网格流送和 Nanite 将类似思路应用于可见几何体。

RTX Mega Geometry 2.0 将这一逻辑延伸到光线追踪所使用的结构。它为开发者提供了另一种在存储与流送工作之间权衡稀缺本地显存的方式。

这一方案尤其重要，因为光线追踪还要与其他成本日益高昂的 GPU 工作负载竞争。高分辨率纹理、路径追踪缓冲区、神经渲染模型、帧生成和降噪器都需要内存。

增加更多 VRAM 能解决部分问题，但会提高显卡成本，也无法消除低效驻留。即使预算更大，也仍可能被细节足够丰富的世界压垮。

预算感知型渲染器提供了另一种答案。它试图让视觉质量随可用资源扩展，而不是让一次过大的分配引发严重的性能崩溃。

早期证据表明，更广义的 Mega Geometry 方法能够带来实际节省。独立技术测试发现，《Alan Wake 2》在 RTX 4090 上的 VRAM 占用约减少了 1GB。

同一测试测得，在原生 4K 和启用 DLSS Quality 的 4K 下，性能提升了 13%。它比较的是原始 Mega Geometry 集成前后的游戏版本，而不是 2.0 版本的新流式传输系统。

这一区别至关重要。该结果支持基于簇的光线追踪结构具有实用价值，但并不能验证连续 LOD 流送的性能或图像质量。

《Alan Wake 2》也展示了采用该技术的两种不同原因。开发者可以将节省的内存和处理时间用于提升细节，或在保持现有质量的同时改善性能。

对许多已发布游戏而言，第二种选择可能更有价值。玩家往往更偏好稳定的帧输出，而不是在运动中难以察觉的几何密度提升。

对于开发者而言，该架构可能减少构建独立且大幅简化的光线追踪网格的需求。它也可能支持更密集的世界，同时避免加速结构吞噬不受控比例的 VRAM。

不过，没有任何 SDK 能免除内容决策的需要。美术师和引擎团队仍需要优质的源网格、有意义的簇层级、可预测的流送行为，以及能在整个游戏过程中保持稳定的视觉阈值。

该技术仍由 Nvidia 主导。面向主机和多家 PC GPU 厂商发布作品的工作室，必须考虑 Nvidia 专用路径是否带来足以证明额外集成与测试成本合理的收益。

标准和可比的厂商实现将影响其采用。一项能够自然融入共享引擎抽象的技术，比需要独立渲染路径的技术更有机会成为常规方案。

目前，Nvidia 的优势在于提供了可运行代码、公开示例和针对相关簇操作调校的硬件。竞争压力首先落在固定驻留管线上，其次才是竞争对手的实现。

Gears of War: E-Day 是首次重大现实检验

Gears of War: E-Day 可以将 RTX Mega Geometry 从技术展示带入已发布游戏的测试，但 Nvidia 尚未说明该游戏使用的是哪个 SDK 版本。

Nvidia 表示，RTX Mega Geometry 将登陆 Gears of War: E-Day。它还发布了与 The Coalition 的讨论，介绍该游戏对 Mega Geometry 和 DLSS 技术的使用。

这一时间点值得关注。Nvidia 于 9 月 22 日宣布 2.0 版本，而 E-Day 在其 10 月 6 日全球发售前已完成压盘。

游戏完成压盘意味着其发布版本已完成一项重要的制作里程碑。SDK 在较晚阶段的公告，并不自动意味着新近发布的技术已进入该构建版本。

2.0 版本可能将 The Coalition 已可使用的工作正式化，也可能该游戏采用的是较早的 Mega Geometry 实现。它也可能只使用部分组件，而未采用完整的参考流送路径。

公开公告均未解答这一问题。Nvidia 的措辞将 Mega Geometry 与该游戏联系起来，但并未明确表示 E-Day 将搭载 2.0 版本。

因此，读者不应将 E-Day 视为新连续 LOD 流送系统已获确认的证据。它已确认采用的是更广义的 RTX Mega Geometry 技术家族。

这一区别会影响评测者能够测试的内容。如果 E-Day 使用流送路径，分析人员便可研究 VRAM 扩展性、视觉过渡、帧时间稳定性，以及多个 RTX 世代的性能表现。

如果它采用较早的实现，游戏仍可展示基于簇的加速结构的价值。只是无法验证 2.0 版本的主打功能。

10 月发售仍然重要，因为生产环境会暴露参考演示无法呈现的问题。一款完整游戏会结合动画、破坏效果、粒子、流送、脚本事件、多人系统和快速镜头移动。

这些工作负载会争夺 CPU 时间、带宽、存储访问和 VRAM。一个在 Zorah 中表现良好的几何系统，必须在其他一切同时运行时仍保持这种表现。

该游戏还覆盖 Xbox Series 主机和 PC。Nvidia 专属 RTX 功能仅适用于相关 PC 硬件，而 The Coalition 必须在所有支持平台上保持一致的艺术呈现。

这使 E-Day 成为研究可选渲染路径的有用案例。PC 版本可能利用 Mega Geometry 提升光线追踪效率，同时不改变游戏的核心资产或设计。

Nvidia 声称，该集成可带来更高帧率、更好的图像质量和更灵敏的操作响应。在受控测试将 Mega Geometry 与 DLSS、帧生成、设置变更和驱动差异区分开之前，这些仍只是公司的说法。

官方 10 月 6 日发售将为评测者提供近期检验最终版本的机会。最具参考价值的测试将比较等效视觉设置，并提供详细的 VRAM 和帧时间测量。

仅凭截图并不足够。连续 LOD 系统必须在运动中评估，因为过渡、缓存未命中和流送压力会随着镜头在场景中移动而出现。

测试还应涵盖内存受限的显卡。当预算紧张时，旨在控制预算范围内运行的系统更具实际价值。

8GB 显卡是一个尤其具有揭示性的目标。在这里，节省或控制数 GB 内存比在拥有充足内存的旗舰显卡上更重要。

最佳结果不一定是最高平均帧率。稳定的帧时间、更少与内存有关的掉帧，以及移动过程中的一致几何表现，更能支撑 Nvidia 的核心主张。

在这些测量结果出现之前，E-Day 是一个有前景的测试案例，而非定论。其状态应与经过精心控制的 Zorah 演示分开看待。

2.0 版本发布后值得关注的事项

三个信号将表明 Nvidia RTX Mega Geometry 2.0 会成为实用的渲染层，还是仍停留在专门的参考技术阶段。

第一个信号是最终的 Gears of War: E-Day 实现。Nvidia 或 The Coalition 应说明游戏搭载哪个 Mega Geometry 版本、哪些模式使用它，以及玩家能否直接比较。

如果 2.0 版本流送处于启用状态，独立测量便可在真实游戏过程中检验 Nvidia 的内存预算主张。多个 RTX 世代上的稳定结果将强化采用该技术的理由。

如果游戏只使用早期的加速结构路径，2.0 版本仍需要一个生产环境的展示案例。这不会否定该 SDK，但会延后其主要新功能的独立证据。

第二个信号是内存压力上升时的图像表现。评测者应检查轮廓、反射、阴影、快速转向、场景移动，以及包含大量遮挡的场景。

成功的实现应当让几何细节逐步下降。明显的跳变、细节延迟、反射不匹配或突然的帧时间尖峰，都会暴露选择或流送机制的弱点。

测试应报告完整的 VRAM 使用量，而不仅是驻留网格内存。几何体只是单帧的一部分，只有整体分配变得更易于管理时，相关削减才真正有意义。

第三个信号是引擎与行业采用情况。Nvidia 已提供 Unreal Engine 集成和公开代码，但要实现常规应用，仍需具备可用于生产的工具链和跨平台策略。

若有更多商业游戏提供支持，将表明团队能够在不过度增加维护负担的前提下集成该技术。更广泛的 API 支持或可比的实现方案，则可降低围绕单一厂商构建技术栈的风险。

开发者还应关注公开代码库。平台支持、调试工具、资产烘焙、缓存管理和性能指导方面的变化，或许比又一个震撼的示例场景更重要。

Nvidia RTX Mega Geometry 2.0 提出了一个清晰的技术论点：即使源世界规模远超 VRAM，几何数据也应占用一组可控的工作集。这一论点可信，而参考实现如今也为开发者提供了可进行实际测试的具体对象。

尚未解决的问题是：当这一机制进入一款复杂、正式发售的游戏后，玩家能否获得稳定的细节表现与性能。关注 E-Day 的发布，检查动态画面而非静态图像，并比较多款 GPU 上的总内存占用。这些结果将表明，按需加载的光线追踪几何是否已准备好成为引擎的标准假设。