---

1 -> 概述

随着移动端高帧率游戏的普及，如何兼顾流畅度与功耗一直是行业难题。传统通过GPU暴力渲染的帧率提升方式，受限于SoC的功耗墙和散热能力，往往难以持久维持高帧率输出。尤其是在快速运动的游戏场景中，原生渲染的帧率瓶颈更为突出。

鸿蒙6.0 Graphics Accelerate Kit（图形加速套件）从6.0.0(20)版本开始，在游戏渲染加速服务的超帧能力中，新增了支持顶点标记的Vulkan平台能力。这一能力为基于Vulkan图形API的鸿蒙应用提供了更精细的运动估计控制手段，开发者可以选择性地标记需要参与运动估计的物体顶点，从而在高动态场景中获得更高质量的超帧画质。

超帧（Frame Generation）是Graphics Accelerate Kit的核心能力之一。它利用硬件与软件协同的运动估计与运动补偿（MEMC）技术，基于渲染管线中的时域和空域信息，在真实渲染帧之间高效插入预测帧，在维持原始图像质量的前提下显著提升游戏帧率和流畅度，同时降低系统负载和功耗。

Graphic Accelerate Kit提供的三⼤核⼼服务对比：

服务	目标场景	核心技术
游戏渲染加速服务	高帧率、高负载游戏场景	超帧生成、自适应缓冲分辨率（ABR）、OpenGTX
游戏资源加速服务	游戏资源下载与管理	资源后台静默下载
游戏启动加速服务	游戏冷启动慢问题	内存快照精准恢复技术

顶点标记能力是游戏渲染加速服务中“超帧”功能的一个增强特性，它通过Vulkan平台的QueryPool接口实现。

2 -> 运动估计模式与顶点标记原理

2.1 -> 基础模式 vs 增强模式

超帧提供两种运动估计模式供开发者选择：

运动估计模式	原理	特点
基础模式	利用历史帧颜色信息、深度信息及相机矩阵信息进行运动估计	无需开发者介入即可工作，适用于一般运动场景
增强模式	利用历史帧中的几何顶点信息进行更精准的运动估计	需要开发者对绘制顶点的Draw Call进行额外标记，画质更优

基础模式下，运动估计依赖于屏幕空间的信息——颜色和深度只能反映二维投影的变化，缺乏三维空间中的精确运动信息。增强模式则通过Vulkan的**Transform Feedback（变换反馈）**特性，直接捕捉被标记物体的顶点数据，再通过顶点匹配、运动估计、屏幕空间投影等过程，最终获得高精度的运动向量图。

2.2 -> 几何顶点信息的价值

顶点数据中包含物体在三维空间中的位置、法线等原始几何信息。对于快速旋转的物体（如游戏中的角色转身、武器挥舞）或远离相机的物体（如飞行中的弹道、飘动的旗帜），屏幕空间的颜色和深度变化往往不够显著，难以通过基础模式准确估计其运动轨迹。而在增强模式下，系统可以直接获取这些物体的顶点在连续帧之间的三维空间位移，因此即使在相机和物体快速运动的游戏场景中，超帧效果也比基础模式更优，能有效改善拖影问题。

顶点标记能力的引入，本质上是将“哪些物体的运动需要被准确估计”这一决策权交给了开发者。开发者最了解自己的场景——哪些是动态物体，哪些是静态背景，哪些物体的运动预测最为困难，哪些物体的顶点数量较少但运动幅度大——这些信息都可以通过精细的顶点标记策略反映给运动估计算法。

3 -> 开发配置与设备限制

3.1 -> 应用配置

在正式使用顶点标记功能之前，需要在应用的module.json5配置文件中设置元数据，通知系统应用支持顶点标记：

{
  "module": {
    "metadata": [
      {
        "name": "GraphicsAccelerateKit_VBMV",
        "value": "true"
      }
    ]
  }
}

3.2 -> 设备兼容性

增强模式需要设备GPU支持相应的硬件特性，目前仅支持马良910 GPU及以上的手机平板设备。在不支持的平台上，系统会自动降级为基础模式，不会导致应用异常或崩溃。

开发者可以通过运行时检测来判断设备是否支持该功能，以便在必要时调整渲染策略。

4 -> 核心API详解

4.1 -> 自定义Query Type

顶点标记通过Vulkan Query机制实现，使用了华为自定义的Query类型：

VkQueryType VK_QUERY_TYPE_HISS_MOTION_VECTOR_DRAW_TRACKING_HUAWEI = static_cast<VkQueryType>(1000000000);

这里1000000000是Vulkan规范中为供应商保留的自定义扩展值范围（VK_QUERY_TYPE_MAX_ENUM之后的空间），表示这是一个华为特有的Query类型，而非Vulkan标准中定义的Query类型。

4.2 -> QueryPool创建

创建用于顶点标记的QueryPool时，有如下关键注意事项：

VkQueryPool queryPool;
VkQueryPoolCreateInfo createInfo{};
VkDevice device;  // 从Vulkan设备实例获得

createInfo.sType = VK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO;
createInfo.queryType = VK_QUERY_TYPE_HISS_MOTION_VECTOR_DRAW_TRACKING_HUAWEI;
createInfo.queryCount = 1;  // queryCount必须等于1
vkCreateQueryPool(device, &createInfo, nullptr, &queryPool);

代码中需要特别关注以下几点：

• queryCount必须等于1：与普通的Query机制不同（通常按绘制对象数量分配Query），此处的QueryPool仅用于标记而非结果管理；
• QueryPool配置后不支持查询管理：这个QueryPool的本质是一个“标记工具”，而不是用于获取查询结果的容器。开发者不应对其进行vkCmdCopyQueryPoolResults或vkGetQueryPoolResults等查询操作；
• 一个应用只需要创建一个QueryPool：标记能力与QueryPool的数量无关，一个QueryPool可以循环用于多个Draw Call的标记。

4.3 -> 标记指令

在需要被追踪的Draw Call前后，分别调用vkCmdBeginQuery和vkCmdEndQuery：

void DrawDynamicObject(VkCommandBuffer cmd_buffer, VkQueryPool queryPool)
{
    // 开始标记：开始记录当前物体的顶点数据
    vkCmdBeginQuery(cmd_buffer, queryPool, 0, 0);
    
    // 实际的绘制调用
    vkCmdDraw(cmd_buffer, vertexCount, instanceCount, firstVertex, firstInstance);
    // 对于索引绘制，也可以是 vkCmdDrawIndexed 等
    
    // 结束标记：停止记录顶点数据
    vkCmdEndQuery(cmd_buffer, queryPool, 0);
}

在记录CommandBuffer时，被标记的Draw Call对应的顶点数据将被系统缓存，供后续的运动估计阶段使用。

4.4 -> Transform Feedback的内在机制

Vulkan规范中虽然没有直接定义Transform Feedback为独立的管线阶段，但GPU驱动可以在Query机制的执行过程中实现顶点数据的拦截和缓存。当Driver检测到VK_QUERY_TYPE_HISS_MOTION_VECTOR_DRAW_TRACKING_HUAWEI类型的Query处于激活状态时，自动将当前Draw Call中经过顶点着色器处理后的顶点位置信息复制到专门的缓存区域，供运动估计算法使用。

4.5 -> 各渲染管线的标记时机

顶点标记应在会影响最终深度缓冲区写入的渲染Pass中进行。不同渲染架构下，标记位置有所不同：

• 延迟渲染管线（Deferred Rendering）：在GBuffer Pass中标记
• 带Pre Depth的前向渲染管线：在Pre Depth Pass中标记
• 无Pre Depth的前向渲染管线：在Base Pass（也称Forward Pass）中标记

需要特别注意的是：不要在生成Shadow Map Pass中的动态物体Draw Call进行标记。Shadow Map Pass的深度图通常是不透明的纹理空间坐标系，其中的顶点变换与最终屏幕空间的投影差异很大，标记此类绘制会影响运动估计的准确性。

各渲染管线标记时机汇总：

渲染管线类型	建议标记位置	原因说明
延迟管线	GBuffer Pass	GBuffer包含了用于最终像素着色的位置数据
带Pre Depth前向管线	Pre Depth Pass	深度信息先于光照计算，顶点经过处理
无Pre Depth前向管线	Base Pass	只有此Pass直接参与最终颜色缓冲区的写入
Shadow Map Pass	⚠️ 不要标记	深度图坐标系与屏幕空间差异大，影响准确度

5 -> 顶点标记策略与性能权衡

5.1 -> 核心原则

被标记的物体能在运动估计阶段得到更高精度的运动向量图，但这需要付出额外的性能代价。开发者需要在画质收益与性能成本之间做出平衡。

5.2 -> 推荐策略

建议只标记画面中相对场景运动的物体。理由如下：

1. 顶点数量较少：动态物体通常只占场景顶点总数的一部分
2. 运动预测最为困难：静态背景在屏幕空间中几乎没有位移，基础模式已经能够较好地处理；而动态物体（角色、载具、道具等）的运动轨迹复杂，仅凭颜色和深度信息难以精确还原
3. 成本与收益的平衡：上述方式能以少量顶点标记的性能代价，换取较明显的超帧画质收益

5.3 -> 需要避免的标记

以下类型的Draw Call不应被标记：

• 静态背景：无实质运动信息，浪费带宽
• Shadow Map中的动态物体：坐标系不匹配，反而影响精度
• 粒子系统：顶点数量少且变化剧烈，标记收益有限但可能增加系统负担
• 后处理全屏Quad：本身就是屏幕空间的操作，无几何顶点运动信息

6 -> 完整集成流程

6.1 -> 步骤一：配置Module

在module.json5中添加GraphicsAccelerateKit_VBMV元数据开关。

6.2 -> 步骤二：包含头文件

// 引用超帧frame_generation_vk.h头文件
#include <frame_generation_vk.h>

6.3 -> 步骤三：创建QueryPool

在Vulkan设备初始化阶段创建专用的QueryPool对象。

6.4 -> 步骤四：标记动态Draw Calls

在每一帧的CommandBuffer记录阶段，在需要标记的动态物体绘制前后调用vkCmdBeginQuery和vkCmdEndQuery。

6.5 -> 步骤五：运行时设备检查（建议）

在引擎初始化时检查当前设备GPU型号，判断是否为马良910及以上，从而决定是否启用增强模式。

6.6 -> 步骤六：性能监控集成

建议在调试版本中将顶点标记的相关统计信息纳入性能分析工具，监控被标记物体的顶点数量、标记的Draw Call数量等指标。

7 -> 预期收益与适用场景

顶点标记的增强模式适用于以下场景：

• 高动态多人对战游戏：角色高速移动、频繁转向，顶点运动轨迹复杂
• 竞速类游戏：载具与场景的相对速度极高，精准的运动估计至关重要
• 开放世界ARPG：摄像头自由旋转，动态物体与静态背景交错出现
• 体育类游戏：球员、球的快速运动需要精确的插值位置

受益于增强模式下更精准的运动估计，这些场景中的拖影、模糊、伪影等问题将得到显著改善。

8 -> 其他引擎的同类技术对比

类似于Vulkan顶点标记的几何运动估计技术，在其他主流图形API和游戏引擎中也有不同形式的实现。PC端常用FXAA、TAA等技术依赖屏幕空间的运动向量，而顶点标记直接使用几何信息进行更精确的运动估计，是移动端超帧生成的关键创新。

9 -> 总结

鸿蒙6.0 Graphics Accelerate Kit新增的Vulkan顶点标记能力，为开发者提供了精细控制超帧运动估计的手段。通过在Vulkan CommandBuffer中对动态物体的Draw Call进行标记，系统可以获取高质量的顶点级运动信息，在高动态场景中获得更优的超帧画质。

核心要点可归纳为：

• 借助Vulkan自定义Query Type和Transform Feedback特性实现顶点数据捕获
• 标记时queryCount必须设为1，QueryPool仅供标记使用，不进行查询
• 仅在影响最终深度缓冲区写入的渲染Pass中进行标记
• 推荐策略是只标记动态物体——顶点数量少但运动预测最困难
• 目前仅支持马良910 GPU及以上设备

通过合理地运用顶点标记策略，开发者可以实现更高质量的超帧体验，在移动设备上获得更流畅的视觉效果。

---

感谢各位大佬支持！！！
互三啦！！！