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

【HarmonyOS 6.0】Graphics Accelerate Kit:基于Vulkan的顶点标记技术 文章目录1 - 概述2 - 运动估计模式与顶点标记原理2.1 - 基础模式 vs 增强模式2.2 - 几何顶点信息的价值3 - 开发配置与设备限制3.1 - 应用配置3.2 - 设备兼容性4 - 核心API详解4.1 - 自定义Query Type4.2 - QueryPool创建4.3 - 标记指令4.4 - Transform Feedback的内在机制4.5 - 各渲染管线的标记时机5 - 顶点标记策略与性能权衡5.1 - 核心原则5.2 - 推荐策略5.3 - 需要避免的标记6 - 完整集成流程6.1 - 步骤一配置Module6.2 - 步骤二包含头文件6.3 - 步骤三创建QueryPool6.4 - 步骤四标记动态Draw Calls6.5 - 步骤五运行时设备检查建议6.6 - 步骤六性能监控集成7 - 预期收益与适用场景8 - 其他引擎的同类技术对比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配置文件中设置元数据通知系统应用支持顶点标记{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_HUAWEIstatic_castVkQueryType(1000000000);这里1000000000是Vulkan规范中为供应商保留的自定义扩展值范围VK_QUERY_TYPE_MAX_ENUM之后的空间表示这是一个华为特有的Query类型而非Vulkan标准中定义的Query类型。4.2 - QueryPool创建创建用于顶点标记的QueryPool时有如下关键注意事项VkQueryPool queryPool;VkQueryPoolCreateInfo createInfo{};VkDevice device;// 从Vulkan设备实例获得createInfo.sTypeVK_STRUCTURE_TYPE_QUERY_POOL_CREATE_INFO;createInfo.queryTypeVK_QUERY_TYPE_HISS_MOTION_VECTOR_DRAW_TRACKING_HUAWEI;createInfo.queryCount1;// queryCount必须等于1vkCreateQueryPool(device,createInfo,nullptr,queryPool);代码中需要特别关注以下几点queryCount必须等于1与普通的Query机制不同通常按绘制对象数量分配Query此处的QueryPool仅用于标记而非结果管理QueryPool配置后不支持查询管理这个QueryPool的本质是一个“标记工具”而不是用于获取查询结果的容器。开发者不应对其进行vkCmdCopyQueryPoolResults或vkGetQueryPoolResults等查询操作一个应用只需要创建一个QueryPool标记能力与QueryPool的数量无关一个QueryPool可以循环用于多个Draw Call的标记。4.3 - 标记指令在需要被追踪的Draw Call前后分别调用vkCmdBeginQuery和vkCmdEndQueryvoidDrawDynamicObject(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 PassGBuffer包含了用于最终像素着色的位置数据带Pre Depth前向管线Pre Depth Pass深度信息先于光照计算顶点经过处理无Pre Depth前向管线Base Pass只有此Pass直接参与最终颜色缓冲区的写入Shadow Map Pass⚠️不要标记深度图坐标系与屏幕空间差异大影响准确度5 - 顶点标记策略与性能权衡5.1 - 核心原则被标记的物体能在运动估计阶段得到更高精度的运动向量图但这需要付出额外的性能代价。开发者需要在画质收益与性能成本之间做出平衡。5.2 - 推荐策略建议只标记画面中相对场景运动的物体。理由如下顶点数量较少动态物体通常只占场景顶点总数的一部分运动预测最为困难静态背景在屏幕空间中几乎没有位移基础模式已经能够较好地处理而动态物体角色、载具、道具等的运动轨迹复杂仅凭颜色和深度信息难以精确还原成本与收益的平衡上述方式能以少量顶点标记的性能代价换取较明显的超帧画质收益5.3 - 需要避免的标记以下类型的Draw Call不应被标记静态背景无实质运动信息浪费带宽Shadow Map中的动态物体坐标系不匹配反而影响精度粒子系统顶点数量少且变化剧烈标记收益有限但可能增加系统负担后处理全屏Quad本身就是屏幕空间的操作无几何顶点运动信息6 - 完整集成流程6.1 - 步骤一配置Module在module.json5中添加GraphicsAccelerateKit_VBMV元数据开关。6.2 - 步骤二包含头文件// 引用超帧frame_generation_vk.h头文件#includeframe_generation_vk.h6.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必须设为1QueryPool仅供标记使用不进行查询仅在影响最终深度缓冲区写入的渲染Pass中进行标记推荐策略是只标记动态物体——顶点数量少但运动预测最困难目前仅支持马良910 GPU及以上设备通过合理地运用顶点标记策略开发者可以实现更高质量的超帧体验在移动设备上获得更流畅的视觉效果。感谢各位大佬支持互三啦