前阵子接了一个电影级资产实时预览的活儿，单个角色模型上千万面，GPU算力其实没见底，但画面一顿一顿，帧数死活上不去。调试面板一开，卡住的不是像素填充，而是“微多边形”级别的几何提交——那一刻我彻底意识到，实时渲染真正要突破的极限，早在三角形到达光栅化器之前就已经写死了。这也是今天想聊透的主题：微多边形时代下，软硬协同光栅化架构到底应该怎么设计、怎么拆分工、又会在哪些细节上翻车。这篇文章我会从微多边形在离线渲染里成熟、在现代实时引擎里复活开始，拆解软件光栅化和硬件光栅化的边界，最后把工程量产时容易忽略的坑一并拉出来。适合正在做自研引擎、图形管线优化，以及被高模场景实时预览折磨的开发者。
1. 光栅化真正的瓶颈不是像素，而是三角形的“到达率”
1.1 传统管线为什么一到高模就现原形
大多数人提到 GPU 光栅化，第一反应是“每秒能处理几十亿三角形”，听起来很猛。但如果把一个真实场景跑一遍 profile，你会发现事情远没有那么美好。
传统管线的流程是这样：CPU 把顶点缓冲、索引缓冲提交给驱动，GPU 先做顶点着色，然后图元装配、裁剪、背面剔除，再进入光栅化，最后才是像素着色和混合。这整条链路上，真正属于“光栅化”的部分其实只是从扫描转换到像素输出的那一段。三角形数量一旦破千万甚至亿级，最吃紧的环节往往是最不起眼的两个：CPU 的 draw call 提交，以及顶点数据从显存到图形管线的搬运带宽。
我曾经在一个装配体可视化的项目里，看到场景三角形总数并不算夸张，大概两千万面，显卡的像素吞吐绰绰有余，但帧率只有 20 出头。把 profiler 拉出来一看，每个 frame 有接近八万个 draw call，驱动层的状态验证和命令缓冲解析占了整整 10ms。这就是典型的高模场景下传统架构的尴尬：GPU 能画，但喂不进去。
1.2 “硬件光栅化很快”为什么是一个容易误导的结论
硬件光栅化器确实快，但它的快是有前提的：三角形在屏幕上的覆盖面积足够大，且图元设置的开销能被充分摊销。真正容易出问题的是那些覆盖面积只有几个像素甚至不到一个像素的三角形。
显卡光栅化硬件内部往往是以 2x2 像素的 quad 为单位工作的，如果一个三角形只覆盖了 quad 里的一小块，其他三个像素依然要做无效的覆盖测试和处理。三角形的平均投影面积越小，这种无效工作占比越高。等三角形小到 1 像素级别时，传统硬件光栅化器的效率会断崖式下跌——不是算力不够，是固定功能单元的工作方式根本不适合这种粒度。
这就是“微多边形”概念开始有意义的起点：当几何碎片的尺寸接近像素尺度时，继续沿用传统的“顶点输入 + 固定光栅化器”路径，相当于用货车送快递，每一件都只有巴掌大，货车的装载率低得可怕。
1.3 微多边形带来的第一个范式转换
传统渲染里，三角形是“输入数据”，是模型文件里写死的东西。渲染器拿到几何就开始处理，处理完就扔。而微多边形范式完全反过来：几何不是最终输入，而是渲染过程中按需生成的一种临时数据结构。
一个曲面或一个高精度网格，可以在渲染时根据屏幕空间误差被实时细分成大量微多边形，每个微多边形的投影尺寸控制在接近一个像素。这个过程很像打印时按需分辨率输出：远处看不清楚的细节就不细分，近处需要极致细节就疯狂细分。换句话说，三角形从静态资产变成了动态计算的产物。
这个转换的直接结果就是：渲染器的关注点从“如何加速提交更多三角形”变成了“如何高效生成并处理与像素规模匹配的微多边形”。而这一点，恰恰决定了我们必须在架构层面引入软硬协同。
1.4 为什么软硬协同是必然答案
没有任何单一硬件单元能同时做到两件事：既能灵活地生成海量微多边形，又能高效地完成深度测试、像素合并和混合。GPU 的固定功能单元擅长后者，但缺乏前者需要的灵活性；通用计算单元擅长前者，但用软件去实现深度压缩、多采样、混合会很痛苦，而且很多硬件优化用不上。
所以微多边形时代最合理的架构，不是“软件替代硬件”，也不是“硬件吃掉一切”，而是软硬协同：通用计算生成几何、剔除、包装数据，固定功能单元负责像素级的最终合并与输出。整条流水线的设计重心，变成了这两种路径之间的数据交接和任务划分。
2. REYES留下的宝贵遗产：微多边形不只是“把三角形切小”
2.1 离线渲染早就验证过这条路
微多边形不是实时渲染领域的新发明，真正的老祖宗是 Pixar 的 RenderMan 采用的 REYES 架构。REYES 的全称是 Render Everything You Ever Saw，核心思路就是把复杂的曲面几何在渲染时切分成大量微多边形，每个微多边形的尺寸大约等于甚至小于一个像素，然后逐个微多边形做隐藏面消除、着色和采样。
我当时第一次看 REYES 的资料时，最大的震撼不是“切三角形”本身，而是它整个流程的取舍：传统离线渲染器追求几何与像素之间的精确对应，REYES 干脆把几何“磨”到像素粒度，再做逐微多边形的采样。这样一来，运动模糊和景深这类需要时间/空间采样的效果，可以直接作用在微多边形上，而不是在像素着色阶段硬凑。
在现代实时语境下，很多人一提“微多边形”就想到 Nanite 或 虚拟纹理几何，但如果你去翻图形学历史，会发现 REYES 才是那个把“几何稀疏化、按需生成、像素级粒度”三个关键词刻进 DNA 的架构。
2.2 实时引擎为什么重新捡起微多边形
过去十年，GPU 的通用计算能力和显存带宽大幅增长，但 CPU 的单核性能提升已经非常有限。这造成一个严重失衡：场景几何复杂度可以随美术资产无限膨胀，但 CPU 每帧可以提交的命令数量几乎原地踏步。传统 LOD 是一个缓解方案，但美术要手动维护多个版本的模型，还会出现远近切换时的细节跳变。
微多边形架构解决的是更本质的问题：把几何处理的粒度从“模型”和“三角形”下沉到“像素”，让负载自动跟着屏幕覆盖面积走。近处的物体虽然模型复杂，但在屏幕上占的面积大，微多边形数量也多；远处的物体即使载入的是同等精度的源几何，经过细分控制后，实际生成的微多边形数量会急剧减少。这实际上是一种动态 LOD，但不需要美术做多套模型，也不需要 CPU 参与逐三角形的挑拣。
2.3 从逐对象 LOD 到持续几何流
传统 LOD 还有一个隐性成本：切换时机的管理。切换太早，细节确实看不出来，但一旦被截图放大就会穿帮；切换太晚，帧率崩给你看。工程上为了规避这些问题，往往要做 morphing、dithering、渐进式过渡，每一样都是时间黑洞。
微多边形时代的做法其实非常“虚拟内存”：把几何数据拆成一块一块的 cluster，按需流送到显存，GPU 端的 compute shader 根据当前视角和屏幕空间误差动态决定每块 cluster 要细分成多少微多边形。整个过程是连续的，尺度随距离平滑变化，不存在传统 LOD 那种离散跳变。这种设计带来的另一个优势是：不需要一次性把所有高模都留在显存里，显存里只有当前帧真正用得到的几何数据。
这也是为什么微多边形架构通常和“虚拟化几何”“流送”“page cache”这些概念绑在一起出现——它们根本是一套完整方案的不同侧面。
3. 软硬协同光栅化到底怎么拆：两级流水线的分工模型
3.1 大三角形走硬件，微多边形走软件
如果让我用一句话概括微多边形时代的软硬协同分工，那就是：别让硬件光栅化器去处理比像素还小的三角形，也别让软件光栅化器去啃铺满屏幕的大三角形。
硬件光栅化在三角形覆盖面积足够大时，效率极高。图元装配、裁剪、保守光栅等固定功能全都是为这种场景设计的，而且还能白嫖硬件多采样、混合、深度压缩这些特性。可一旦三角形缩到覆盖面积只有 0.5 个像素，硬件光栅化每处理一个三角形，都要为一堆无效像素付出开销，这时候软件光栅化反而更划算：直接在 compute shader 里逐像素扫描，跳过无效区域，不需要经过顶点装配、图元设置那一整套固定管线。
下面这张表是我在实践中常用的一种经验分界，可以参考但不建议直接抄：
| 三角形平均屏幕覆盖面积 | 推荐路径 | 核心原因 |
|---|---|---|
| 大于 64 像素 | 硬件光栅化 | 固定功能的图元设置开销完全被摊薄，硬件效率最高 |
| 4 到 64 像素 | 硬件光栅化为主 | 硬件光栅化的 quad 利用率明显回升，软件光栅化没有优势 |
| 1 到 4 像素 | 两者交替 | 硬件光栅化已经开始出现碎片化，按具体场景 profile 决定 |
| 小于 1 像素 | 软件光栅化 | 硬件 quad 碎片化严重，compute 直接逐像素覆盖测试反而更省 |
这个阈值不是魔数，它的本质是“硬件固定开销”和“软件逐像素成本”的交叉点。实际项目里最好写一个 profiling 工具，统计三角形覆盖面积分布直方图，再结合平台差异去定阈值。
3.2 软件光栅化器的并行模型
软件光栅化听起来很高端，但核心实现逻辑其实很朴素。常见做法是让 compute shader 中一个 thread block 处理一个 cluster，先计算出包围盒，再对包围盒内的像素做覆盖测试。每个微多边形只需要几个顶点和重心坐标，写出的结果是像素位置的 cluster ID、三角形 ID 和深度值。
一段简化的核心逻辑差不多长这样：
// 每个线程处理一个微多边形 uint clusterId = getClusterId(...); uint triId = getTriId(...); Micropolygon mp = fetchMicropolygon(clusterId, triId); // 投影到屏幕空间并计算包围盒 vec4 screenBBox = projectAndGetBBox(mp); if (screenBBox.max.x < 0.0 || screenBBox.min.x > viewport.x) return; // 逐像素覆盖测试 for (uint y = screenBBox.min.y; y <= screenBBox.max.y; ++y) { for (uint x = screenBBox.min.x; x <= screenBBox.max.x; ++x) { vec2 pixelCenter = vec2(x + 0.5, y + 0.5); float coverage = edgeFunction(mp, pixelCenter); if (coverage > 0.0) { float depth = interpolateDepth(mp, pixelCenter); uint packedId = pack(clusterId, triId); writeVisibility(pixelCoord, packedId, depth); } } }这段伪代码看起来很直接，但真正要命的是两个点。第一，访存模式。微多边形的顶点数据要尽量在 thread block 内被反复使用，否则显存带宽会瞬间打满。第二，写入方式。如果直接往一张可见性缓冲图里原子写深度，竞争会非常激烈，所以实际工程里会先用粗粒度块做遮挡查询，再逐块写入，把原子操作次数降下来。
3.3 软硬合流的顺序与一致性
真正的架构难点在于，软件光栅化和硬件光栅化不是两条各跑各的独立管线，它们最终要把结果写进同一张可见性缓冲或深度缓冲里。
顺序上，不透明几何一般会先跑粗粒度的 cluster 级遮挡剔除，然后让软件光栅化处理微多边形，再让硬件光栅化处理那些比较大的三角形。两边写入统一的一张 depth，后续材质着色阶段按像素位置读取三角形 ID 和深度即可。如果顺序颠倒，或者两边的深度规则不一致，就会出现三角形互相穿帮、边缘闪烁这类很玄学的问题。
我见过最典型的错误，是软件光栅化里用的深度范围和硬件光栅化不一致。软件侧用手写透视插值，硬件侧用管线默认值，摄像机远平面一动，远处物体的边缘就开始闪。这不是精度不够，而是两边插值公式没有对齐。
3.4 动态分派：别做成二选一的静态开关
软硬协同最忌讳的实现方式，是在引擎启动时用一个全局开关决定“今天走软件还是硬件”。且不说不同场景的几何覆盖分布差异巨大，单是一个场景内，不同距离、不同粗糙度的物体之间，三角形尺寸分布就可能是天壤之别。
正确的做法是让分派发生在运行时、甚至发生在像素块级别。dispatch 端可以根据上一帧的统计结果，预测这一帧某类 cluster 走哪条路径更划算；cluster 内部的三角形，也可以在 compute shader 里按覆盖面积动态分流，大的提交给硬件光栅化，小的继续留在软件路径里。这种两级动态分派，才是软硬协同架构真正的灵魂。
4. 落地时最容易翻车的七个细节：来自工程实践的教训
4.1 微多边形尺寸不是越小越好
微多边形的目标尺寸一般是投影面积 0.5 到 1 个像素。有人会想：切到 0.1 像素，画质岂不是更极限？大错特错。微多边形尺寸一旦低于 0.5 像素，几何顶点数和索引数会呈二次方膨胀，缓存局部性迅速恶化，带宽和指令开销一起飙升，最终吃到的是整个管线的性能，而不是光栅化那一小段。
另外，要区分“几何细分精细度”和“像素着色质量”。微多边形的粒度只需要服务于几何边缘的精度，像素着色质量主要靠材质和光照阶段。把三角形切到远小于像素尺度，并不会让像素着色更好看，只会让你付出毫无意义的几何成本。
4.2 Visibility Buffer 还是 GBuffer
微多边形场景下，GBuffer 是一个需要非常谨慎的选择。传统的 GBuffer 会在像素着色阶段一次性输出多张纹理，包括法线、粗糙度、金属度、基础色等。三角形数量不大时，这套方案完全能接受。但微多边形的数量可以轻松达到传统路径的几十倍，如果每个微多边形都要写 GBuffer 的五六张纹理，带宽会被直接打穿。
实践中的主流方案是 visibility buffer：软件光栅化和硬件光栅化都只写一份紧凑的缓冲，存 cluster ID、三角形 ID 和深度，真正的材质属性解码、光照计算延迟到后续一个 pass 做。这样几何过载不会直接转化为纹理带宽过载，材质着色还可以按需执行，甚至可以实现逐材质和逐像素的多样化着色。
4.3 深度一致性的坑
两个光栅化路径共用同一个深度缓冲时，最容易被忽视的是浮点深度在插值过程中的微小差异。硬件光栅化使用标准透视校正插值，软件光栅化如果用近似公式算深度，在微多边形边缘很容易出现 0.0001 级别的差异。这个差异平时看不见，但遇到接缝、CSM 阴影边缘、以及后处理中依赖深度的效果时，就会变成明显的闪烁噪点。
解决方案是：软件光栅化里必须严格使用与硬件一致的透视校正公式，并且把深度计算统一封装成一个内联函数，避免两边各写一套。
4.4 阴影通道要有独立阈值
很多第一次做微多边形架构的人，会把主视图的光栅化方案直接套到阴影贴图 Pass 上，结果阴影渲染时间直接翻倍。原因很简单：阴影贴图的分辨率和视角与主视图完全不同，主视图里 0.5 像素的微多边形，在阴影贴图视角下可能覆盖了完全不同的区域，如果继续细分到同一尺度，只会浪费一半的几何处理能力。
工程上，阴影通道通常会采用更粗的细分阈值，比如允许微多边形覆盖 2 到 4 个阴影纹理像素，再配合阴影滤波来抹平细节损失。不然的话，微多边形架构会把阴影 Pass 变成整个帧率的第一杀手。
4.5 不要试图纯软件光栅化
软硬协同的反面，是“软硬对抗”或“软硬替代”。纯软件光栅化有它的魅力，特别是当你手上有一个强到没朋友的 compute 队列时，能避开所有硬件固定功能的限制。但现实是，纯软件光栅化会让你失去硬件光栅化的多采样、深度压缩、原生混合等能力。如果场景里有一堆透明物体、粒子、UI 层，纯软光栅化会做得非常痛苦。
真正成熟的架构，是让硬件光栅化继续承担所有“大三角形”和“非几何密集型”的工作，软件光栅化只在微多边形泛滥的区域出动。两者的占比可以是动态浮动的，但千万别走到一个极端里。
4.6 调试面板不能只看三角形数量
微多边形架构上线后，以前调试图形管线的习惯要全部推翻。“场景里有多少三角形”这个指标彻底失去意义，因为每帧三角形是全动态的。你要看的是这几类数据：软/硬光栅化路径各自处理的 cluster 数量、微多边形平均覆盖面积分布、visibility buffer 写入带宽、簇级剔除率。
我会建议在 debug 模式里加一个覆盖面积直方图的热力图，按屏幕区域显示哪些地方走了软光栅化、哪些地方走了硬光栅化。这一张图，比十个柱状图都有用。它能让你一眼看出分派策略是否失衡，哪里本该走软件路径却在硬扛。
4.7 透明物体的处置
微多边形生成和软件光栅化最不适用的场景，就是透明物体。软光栅化本身没有硬件混合排序的能力，如果每个微多边形都各自写到一张带混合的缓冲里，顺序和竞争问题会让人崩溃。实践中，透明物体、粒子、UI 这些内容永远优先走传统硬件光栅化路径，保留标准的深度排序和 alpha blending。微多边形架构服务的是主场景的不透明几何，千万别为了让“架构统一”去强行适配透明渲染。
5. 软硬协同的真正威力在数据调度：从一个场景案例说起
5.1 一个城市级场景下的预期收益
我们来做一个假想但非常典型的场景：一个城市级实时可视化项目，源几何 5000 万三角形，传统架构下 draw call 接近 10 万，CPU 每帧光提交命令就要吃 12ms。如果切成 cluster，每个 cluster 可能覆盖几千到几万三角形，draw call 数量直接降到几百级。由于 cluster 只流送当前帧可见的块，实际进入 GPU 端处理的几何会远小于 5000 万，微多边形细分则按屏幕覆盖面积实时计算，最后软件光栅化和硬件光栅化按面积阈值分流。
在桌级显卡上，这类改造通常能把几何提交时间从 10ms 级降到 1ms 级，把主视距像素处理时间控制在合理范围。当然，代价是你要付出更复杂的内存调度、更重的 GPU 端预处理，以及对带宽需求的精细化控制。这就是软硬协同的性价比所在：它用更复杂的架构，换回了大多数传统管线最难省下的那笔 CPU 和带宽开销。
5.2 微多边形与光追的配合
当前期架构稳定后，微多边形和光线追踪之间其实有天然的协同点。微多边形生成完成时，GPU 端已经有一份非常贴近屏幕几何的三角形列表，这些三角形可以被用来构建或更新 BLAS，做反射、软阴影和全局光照的求交。由于这类三角形已经经过屏幕空间误差控制，数量远小于全量源几何，BLAS 构建的压力会小很多。
反过来，光线追踪反馈的命中信息也可以指导微多边形的细分策略：某个区域反射内容特别复杂，可以在后续帧的细分开关中提高该区域的优先级。这就形成了由传统光栅化和光线追踪共同驱动的闭环架构，从“软硬协同”进一步进化成“光栅化与光线追踪协同”。
5.3 个人体会：别把它当成三天的“特效优化”
最后想聊聊心态。软硬协同光栅化架构不是一个周末就能塞进现有引擎的插件，它是一整套涉及资源流送、剔除策略、渲染 Pass 组织、调试工具链的系统工程。如果团队只有一两个人，我建议先拿一个小的数据流项目练手：把一款模型拆成 cluster，写成 compute 驱动的可见性剔除，再跑一个最简单的软件光栅化，先别管性能，把分派和调试链路跑通，然后才逐步接管主视图的硬件光栅化路径。
我个人在踩过这一圈坑之后最大的体会是：软硬协同的难点从来不是“软件光栅化怎么写”，而是“什么时候切过去、什么时候切回来”的判断逻辑，以及两条路径之间那份共享数据的组织方式。渲染架构做到最后，本质上都是在和数据调度做斗争——三角形只是数据的载体，带宽才是真正的战场。如果后续有机会，我打算再写一篇关于几何 cluster 的流送缓存和页面生命周期管理的实战记录，那部分才是微多边形架构在工业项目里能不能长期活下去的命门。
