【HarmonyOS 6.0】Graphics Accelerate Kit：基于Vulkan的顶点标记技术

枫叶丹42026-05-23 8:14

文章目录

  • [1 -> 概述](#1 -> 概述)
  • [2 -> 运动估计模式与顶点标记原理](#2 -> 运动估计模式与顶点标记原理)
    • [2.1 -> 基础模式 vs 增强模式](#2.1 -> 基础模式 vs 增强模式)
    • [2.2 -> 几何顶点信息的价值](#2.2 -> 几何顶点信息的价值)
  • [3 -> 开发配置与设备限制](#3 -> 开发配置与设备限制)
    • [3.1 -> 应用配置](#3.1 -> 应用配置)
    • [3.2 -> 设备兼容性](#3.2 -> 设备兼容性)
  • [4 -> 核心API详解](#4 -> 核心API详解)
    • [4.1 -> 自定义Query Type](#4.1 -> 自定义Query Type)
    • [4.2 -> QueryPool创建](#4.2 -> QueryPool创建)
    • [4.3 -> 标记指令](#4.3 -> 标记指令)
    • [4.4 -> Transform Feedback的内在机制](#4.4 -> Transform Feedback的内在机制)
    • [4.5 -> 各渲染管线的标记时机](#4.5 -> 各渲染管线的标记时机)
  • [5 -> 顶点标记策略与性能权衡](#5 -> 顶点标记策略与性能权衡)
    • [5.1 -> 核心原则](#5.1 -> 核心原则)
    • [5.2 -> 推荐策略](#5.2 -> 推荐策略)
    • [5.3 -> 需要避免的标记](#5.3 -> 需要避免的标记)
  • [6 -> 完整集成流程](#6 -> 完整集成流程)
    • [6.1 -> 步骤一：配置Module](#6.1 -> 步骤一：配置Module)
    • [6.2 -> 步骤二：包含头文件](#6.2 -> 步骤二：包含头文件)
    • [6.3 -> 步骤三：创建QueryPool](#6.3 -> 步骤三：创建QueryPool)
    • [6.4 -> 步骤四：标记动态Draw Calls](#6.4 -> 步骤四：标记动态Draw Calls)
    • [6.5 -> 步骤五：运行时设备检查（建议）](#6.5 -> 步骤五：运行时设备检查（建议）)
    • [6.6 -> 步骤六：性能监控集成](#6.6 -> 步骤六：性能监控集成)
  • [7 -> 预期收益与适用场景](#7 -> 预期收益与适用场景)
  • [8 -> 其他引擎的同类技术对比](#8 -> 其他引擎的同类技术对比)
  • [9 -> 总结](#9 -> 总结)

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配置文件中设置元数据，通知系统应用支持顶点标记：

json 复制代码 
{
  "module": {
    "metadata": [
      {
        "name": "GraphicsAccelerateKit_VBMV",
        "value": "true"
      }
    ]
  }
}

3.2 -> 设备兼容性

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

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

4 -> 核心API详解

4.1 -> 自定义Query Type

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

cpp 复制代码 
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时，有如下关键注意事项：

cpp 复制代码 
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：

cpp 复制代码 
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 -> 步骤二：包含头文件

cpp 复制代码 
// 引用超帧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及以上设备

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

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

相关推荐
想你依然心痛4 小时前
HarmonyOS 6（API 23）实战：基于悬浮导航、沉浸光感与HMAF的“数智视界“——PC端AI智能体沉浸式数据可视化分析工作台
华为·ar·harmonyos·智能体
前端不太难12 小时前
从单页面到系统化：鸿蒙 App 演进路径
华为·状态模式·harmonyos
想你依然心痛13 小时前
HarmonyOS 6（API 23）实战：基于悬浮导航、沉浸光感与HMAF的“文思智脑“——PC端AI智能体沉浸式智能写作工作台
人工智能·ar·harmonyos·ai写作
小雨青年13 小时前
鸿蒙 HarmonyOS 6 | Pura X Max 鸿蒙原生适配 09：展开态列表增加字段但不变复杂
华为·harmonyos
richard_yuu14 小时前
鸿蒙治愈游戏模块实战｜四大轻量解压游戏、ArkTS动画交互与低功耗落地
游戏·交互·harmonyos
阿钱真强道18 小时前
24 鸿蒙LiteOS GPIO中断实战：从原理到上升沿/下降沿详解
harmonyos·中断·rk·liteos·开源鸿蒙·瑞芯微·rk2206
小崽崽118 小时前
华为云云主机 + DeepSeek｜快速实现华为云DeepSeek大模型搭建“腾讯云代码助手”客户端集成DeepSeek模型
华为·华为云·腾讯云
cd_9492172120 小时前
鸿蒙系统下抖音存储空间不足怎么办？缓存清理教程
缓存·华为·harmonyos
轻口味1 天前
HarmonyOS 6.1 全栈实战录 - 14 渲染树透镜：FrameNode 渲染状态感知与高性能 UI 调优实战
ui·华为·harmonyos
热门推荐
01GitHub 镜像站点02Codex 接入 DeepSeek API 完整配置文档03装上就回不去了：CodeGraph 让 AI 编程效率飙升 92%，它到底做了什么？04【AI】2026 年具身智能模型和世界模型总结05【踩坑记录 | 第一篇】微软商店无法使用时，如何手动安装 OpenAI Codex？附`.msix`文件系统错误解决方法06裂开！ChatGPT 居然开始要手机号验证，附详细解决方法07CC-Switch & Claude 基于 Linux 服务器安装使用指南08几个好用的ip纯净度检测网站09用了半年 OpenRouter，我换到了 Ofox.ai — 两个 AI API 聚合平台的真实对比10codex app每次打开重连5次Reconnecting问题解决