[性能] 方案 E：实例化渲染 —— A→C 落地后每帧顶点数据只剩 28.7 KB，收益同样被剔除吃掉 #18

New Issue

troytt · 2026-09-15T01:37:10Z

troytt commented

2026-09-15 01:37:10 +00:00

拆自 #16 的方案 E。和 #D 一样，开出来主要是为了基于实测裁决要不要做。

方案原意

四边形几何只上传一次，per-instance 属性只放 (x, y, w, h, u0, v0, u1, v1, unit, tint)，用 drawArraysInstanced 一次画完。调研共识是：对 tile／粒子这类"大量相似精灵"，实例化能显著降低 CPU 开销。

现在的数字

A→C 之后顶点布局是 4 顶点 × 9 float = 36 float/四边形（改造前是 6 顶点 × 8 = 48）。换成实例化约 12 float/实例。

场景	四边形/帧	当前顶点数据	实例化后	省下
改造前平均	2 849	400.6 KB	133.5 KB	267 KB
A→C 后平均	204	28.7 KB	9.6 KB	19 KB
A→C 后最差	437	61.5 KB	20.5 KB	41 KB

每帧省 19 KB 的总线传输和约 1.9 µs 的写入。按 60 fps 算是 1.1 MB/s —— 在任何现代 GPU 上都测不出来。

额外代价

实例化和当前的画家序冲突：一次 drawArraysInstanced 里实例的绘制顺序虽然在实践中通常按索引，但规范并不保证跨实例的片元顺序，2D 等距靠的就是严格后画覆盖先画。要保序就得靠深度缓冲或分批，两者都会把结构搞复杂。
属性 divisor 的设置、以及和现有多纹理单元合批（a_unit）的组合，需要重写整个批处理器。

建议

暂不做。 等实机 profile 出现「顶点上传是瓶颈」的证据再回来。

请裁决：关闭 / 降级挂起 / 仍然要做。

拆自 #16 的方案 E。和 #D 一样，**开出来主要是为了基于实测裁决要不要做**。 ## 方案原意四边形几何只上传一次，per-instance 属性只放 `(x, y, w, h, u0, v0, u1, v1, unit, tint)`，用 `drawArraysInstanced` 一次画完。调研共识是：对 tile／粒子这类"大量相似精灵"，实例化能显著降低 CPU 开销。 ## 现在的数字 A→C 之后顶点布局是 4 顶点 × 9 float = 36 float/四边形（改造前是 6 顶点 × 8 = 48）。换成实例化约 12 float/实例。 | 场景 | 四边形/帧 | 当前顶点数据 | 实例化后 | 省下 | | --- | --- | --- | --- | --- | | 改造前平均 | 2 849 | 400.6 KB | 133.5 KB | 267 KB | | **A→C 后平均** | **204** | **28.7 KB** | **9.6 KB** | **19 KB** | | **A→C 后最差** | **437** | **61.5 KB** | **20.5 KB** | **41 KB** | 每帧省 19 KB 的总线传输和约 1.9 µs 的写入。按 60 fps 算是 1.1 MB/s —— 在任何现代 GPU 上都测不出来。 ## 额外代价 - 实例化和当前的**画家序**冲突：一次 `drawArraysInstanced` 里实例的绘制顺序虽然在实践中通常按索引，但规范并不保证跨实例的片元顺序，2D 等距靠的就是严格后画覆盖先画。要保序就得靠深度缓冲或分批，两者都会把结构搞复杂。 - 属性 divisor 的设置、以及和现有多纹理单元合批（`a_unit`）的组合，需要重写整个批处理器。 ## 建议 **暂不做。** 等实机 profile 出现「顶点上传是瓶颈」的证据再回来。请裁决：关闭 / 降级挂起 / 仍然要做。

troytt added a new dependency 2026-09-15 01:37:24 +00:00

#16 [性能] 渲染主循环掉到 20 tps：零视口剔除（88.6% 白画）+ 图集页切换导致单帧最高 3077 次 draw call

troytt referenced this issue

2026-09-15 01:38:11 +00:00

[性能] 渲染主循环掉到 20 tps：零视口剔除（88.6% 白画）+ 图集页切换导致单帧最高 3077 次 draw call #16

troytt commented

2026-09-15 01:43:27 +00:00

按实测关闭：每帧顶点数据已从 400.6 KB 降到 28.7 KB，实例化最多再省 19 KB（60 fps 约 1.1 MB/s），而跨实例的片元顺序没有规范保证，与本项目依赖的严格画家序冲突，还要重写整个批处理器。

如果以后实机 profile 出现「顶点上传是瓶颈」的证据，再重开。

按实测关闭：每帧顶点数据已从 400.6 KB 降到 **28.7 KB**，实例化最多再省 19 KB（60 fps 约 1.1 MB/s），而跨实例的片元顺序没有规范保证，与本项目依赖的严格画家序冲突，还要重写整个批处理器。如果以后实机 profile 出现「顶点上传是瓶颈」的证据，再重开。

troytt closed this issue

2026-09-15 01:43:27 +00:00