建设厅电工证查询网站,安卓手机优化大师官方下载,购卡网页怎么制作,网站建设律师快手Y-tech 原创最新技术干货分享随着3D渲染场景规模越来越复杂#xff0c;单线程渲染架构在满足业务性能要求时已经捉襟见肘#xff0c;因此#xff0c;多线程渲染显得愈发重要。本文首先介绍了新一代图形渲染接口Metal、Vulkan#xff0c;以及它们的多线程渲染特性… 快手Y-tech 原创最新技术干货分享随着3D渲染场景规模越来越复杂单线程渲染架构在满足业务性能要求时已经捉襟见肘因此多线程渲染显得愈发重要。本文首先介绍了新一代图形渲染接口Metal、Vulkan以及它们的多线程渲染特性然后描述了一种优雅的渲染架构可以解决渲染管线开发中的诸多困扰并且基于此实现了多线程渲染极大的提升了3D渲染效率。一、背景Metal[1]、Vulkan[2]是分别由苹果(Apple)和科纳斯组织(Khronos Group)面向新一代图形处理器(GPU)设计的图形API。在移动平台上Metal应用于iOS系列产品Vulkan主要由Android系统提供。Metal、Vulkan作为新一台的图形API相较于OpenGL(ES)设计了更底层、更细粒度的接口提供了全新的状态管理改善了错误处理机制增加了新的特性支持。使用新一代的图形渲染接口可以全方位的增强3D引擎的渲染能力。比如使用状态缓存机制可以降低CPU负载利用ray tracing的三角面求交能力可以带来全新的全局光照方案(Global Illumination)自定义显存管理器可以提高显存利用率……本文受限于篇幅无法从各个角度逐一而述这里主要讨论新一代图形渲染接口带来的多线程渲染能力以及如何围绕它设计一种渲染架构。二、多线程渲染通常一个单线程渲染引擎会面临着硬件资源浪费的问题。如下图1所示一个CPU线程需要先负责逻辑更新然后反复更新渲染状态提交渲染指令。这种架构同时造成了CPU和GPU闲置。对CPU而言完全可以将这些任务分配给多个CPU线程并行执行就GPU而言CPU线程在进行逻辑更新和提交渲染指令时GPU处于闲置状态浪费了算力。图1 单线程渲染面临的问题作为开发者在不考虑功耗、散热、资源分配等现实限制条件下通常希望CPU、GPU永远处于满负荷状态。为了达到满负荷的状态每个线程通常需要具备三个基本能力· 资源创建管理· Pipeline创建管理· Command Buffer创建管理(提交Draw Calls)如果使用OpenGL(ES)引擎开发者将面临的最大问题是OpenGL(ES)API不能跨线程调用它们的调用只能局限在GL Context创建线程内这也就意味着OpenGL(ES)无法原生支持多线程渲染。为了达到OpenGL(ES)多线程渲染的目的开发者需要手动实现Command Buffer记录图形调用指令考虑数据线程安全问题解决资源同步可能带来的性能损耗不胜其烦。而这些问题已经在metal、vulkan设计者考虑之内新一代的图形API天然支持跨线程调用让多线程渲染变得更具有实践可行性。如下图2所示使用Vulkan时Thread 1、2、3独自组织更新工作写入Command Buffer最后提交到Thread 4中的Command Queue中。图2 Vulkan多线程渲染架构三、小结与转进从上面的描述可以看到新一代的图形API为了提高硬件资源利用率进行了全新的设计似乎多线程渲染唾手可得渲染效率即将走向巅峰。然而如果到此为止急冲冲拿着多线程渲染API试图提升渲染效率进行实践时才会发现脑子里一团乱无从下手。毕竟上面只是简单描述了图形API的基本能力并没有提供任何实际可行的方案。就好比做菜有一样的原料做出来的菜品可能千差万别。不过下面不准备直接描述一种多线程渲染方案先转进到一个相关问题—Render Graph。四、Render GraphRender Graph在有些文献也称之为Frame Graph这里使用Render Graph一词主要是考虑到与Shader Graph[3]一词呼应。附录对Shader Graph有一个简单描述。Render Graph是基于数据驱动的理念将行为与数据解耦。只不过是Shader Graph处理shading相关问题Render Graph处理rendering相关问题。下面先了解下渲染器开发时遇到的一些痛点问题然后了解下Render Graph如何解决这些痛点。4.1 网状结构的渲染流程从图3可以看到一个常见的渲染系统包含了地形、粒子、全局光照、反射、PBR、后处理、天空……各种模块而这些模块还具有相互依赖关系形成网状结构实际开发中会导致一系列令人沮丧的问题简单举例· 记忆难度大。即使渲染系统由一个专人负责过了一段时间之后也很难对整个渲染流程记得分毫不差。· 不易了解渲染流程全貌。阅读线性结构的代码来理解图状结构的流程非常困难。· 日常维护难。为了支持新的渲染特性经常需要向已有的流程中添加新的模块新的模块意味着需要打断与重建各模块之间的联系稍有不慎就会出错。· 资源管理困难。比如motion blur和Temporal Anti-Alias都需要使用velocity buffer一旦渲染流程中各种开关过多那么确定velocity buffer创建、销毁时机就变得异常困难。如果采用粗暴的设计方式就会变成渲染开始阶段创建velocity buffer直到渲染生命周期结束才销毁velocity buffer占用了紧缺的GPU资源。更加糟糕的是即使精妙的设计了velocity buffer创建和销毁时间后续渲染流程稍有改动这个所谓的精妙设计反而变成了错误设计作茧自缚心智负担极重。· 模块管理困难。比如 shadow map模块如果某个场景中不需要使用阴影那么shadow map模块就不应该执行。为了达到这种开关效果往往实际中建立一系列的if分支判断决定流程是否执行。但这种带有“土味”的方法会使渲染流程更难理解代码bug极容易发生。图3 Frostbite渲染系统上面一系列令人头疼的问题实践过的人会明白痛不欲生Render Graph应运而生。4.2 Render Graph应用在延迟渲染上图4 延迟渲染流程使用Render Graph描述要讲清楚什么是Render Graph最好的方式是直接看一个Render Graph例子。如上图4所示它描述的就是一个延迟渲染流程的Render Graph从中可以看到橙色的方框代表的是行为(operation)蓝色的方框代表的是资源(resource)。在实践中引擎中使用一个基类RenderGraphRenderPass来定义行为使用一个基类RenderGraphResource来定义资源。这样在实现RenderGraph时需要经历三个阶段· 构建阶段。在此阶段中需定义所有RenderGraphRenderPass、并为其定义输入输出RenderGraphResource。资源类型分为两种permanent和transient。Permanent一般是Render Graph的外界资源比如back color buffer之类。Transient资源可根据读写属性分为三种只读资源可写资源、内部创建资源。· 编译阶段。在这个阶段Render Graph可以自动的根据配置剔除无效行为和数据并且自动的计算资源生命周期。· 运行阶段。执行代码完成整个渲染流程。有了Render Graph数据和行为得到解耦加上清晰的数据流很好的解决了4.1节提到的诸多混乱。比如如果需要在上面的延迟渲染流程中添加Screen Space Ambient Occlusion(SSAO)只需要将全部的精力集中在SSAO的算法实现上实现一个RenderGraphSSAORenderPass然后定义好输入输出不用关心现有的渲染流程如何复杂。然后在Render Graph中设置好AO相关节点连接好相应的数据流整个过程就完成了。4.3 复用延迟渲染渲染流程在4.2小节中定义了一个延迟渲染的Render Graph在本节可以看看如何复用这个Render Graph来实现新的功能。从图5可以看到对于延迟渲染的绝大部分流程不必做改变只需要把Lighting Buffer拷贝到cube map之中然后进行卷积就可以得到反射球。图5 复用延迟渲染生成反射球4.4 剔除无效数据和行为在4.2小节中提到了 RenderGraph第二阶段是编译阶段会进行无效行为和数据剔除。如下图6所示这里本来Gbuffer是作为Lighting render pass的输入现在改为Debug View render pass的输入然后拷贝到Final target上就可以显示渲染中间变量用来进行调试。此时Lighting render pass及其相关资源和render pass就变成了无效资源可以直接在编译阶段剔除。图6 剔除Lighting及其相关资源4.5 异步执行的Compute Shader除了常见的渲染单元现代图形架构中还存在着不可忽视的计算单元(Compute Shader)。Compute shader相较于渲染单元将精力集中在计算方面类似于光栅化这种渲染单元中的标准步骤在计算单元中不复存在。可以简单的认为在执行通用计算时compute shader的效率优于fragment shader。因此一个完整的渲染架构不可回避通用计算模块可以定义一个基类RenderGraphComputePass来描述这个功能。既然同时有了RenderPass和ComputePass就需要考虑RenderPass和ComputePass是否串行执行。考虑到RenderPass和ComputePass都涉及大量IO访问和图形API提交GPU有可能处于闲置状态因此将RenderPass和ComputePass进行并行设计。如图7所示因为SSAO功能考虑使用compute shader实现那么SSAO相关功能放到另外一个异步队列中。因为异步设计同时会造成相应资源的生命周期延长增加了整体显存消耗。图7 上部和下部分别描述了SSAO的同步和异步设计4.6 小结基于Render Graph的渲染管线架构数据流清晰维护容易高度可配置甚至可以做到为每个渲染场景定义一套独特的渲染管线最大化的利用硬件效率。那么这一切和本文提到的多线程渲染有什么关联 五、基于多线程渲染的Render Graph站在更高角度抽象的去看Render Graph Render Graph是一个有向无环图。如图8所示执行C依赖F的完成但D并不依赖F也就是C、F必须串行执行而D、F可以并行运算。因此只要对这个有向无环图进行拓扑排序系统便可以自动判定任务并行性这就是多线程渲染的切入点。如果具象的理解这个问题可以认为任务D是Gbuffer pass而任务F是shadow pass那么D和F不存在相互依赖关系可以并行计算。图8 Render Graph的抽象形式这里设计了一种拓扑排序方法1. 统计各节点出度和入度。D、F入度为0具备并行性出度分别为1、2。E的入度为1。2. 执行入度为0的节点。执行D、FF任务结束后将它指向的节点入度减去1这样E的入度变为0。3. 反复执行第二步直到整个Graph执行完成。经过上面的操作整个Render Graph变成线性执行关系最后提交给常规的并行系统执行如图9所示。图9 拓扑排序Render Graph tasks并执行六、总结本文首先介绍了Metal、Vulkan的多线程能力然后使用Render Graph作为渲染架构最后利用了一种简单的拓扑排序方法将有向无环图展开为线型执行结构使Render Graph天然支持并发的特性得到发挥能够充分利用新一代图形API的多线程渲染能力。本文受限于篇幅主要探讨新一代图形API的多线程渲染能力其它方面来不及深究。此外CPU逻辑的并行能力也没有来得及阐述希望未来有机会进一步进行补充。作者简介饶超2018年加入快手图形引擎开发工程师负责特效图形引擎设计与开发。附录Shader Graph主要是根据数据驱动的理念将行为(shading)和数据解耦。下面图10展示了Unreal Engine 4 Shader Graph的UI界面。UI最右边面板含有Base color、Metallic、Roughness、Opacity等等slot其余的部分为这些slot提供数据。这种设计引擎内部可以不用关心data provider(整个Shader Graph就是一个data provider)具体逻辑直接拿到这些数据进行进一步的shading。Shader Graph具体实现本文不做深入探讨它与多线程渲染并没有太多的关联。图10 Unreal Engine 4 Shader Graph引用[1] Metal Programming Guidehttps://developer.apple.com/library/archive/documentation/Miscellaneous/Conceptual/MetalProgrammingGuide/Introduction/Introduction.html[2] Vulkanhttps://www.khronos.org/vulkan/[3] Unity3D shader graphhttps://unity.com/shader-graph快手Y-tech介绍Y-tech团队是快手公司在人工智能领域的探索者和先行者致力于计算机视觉、计算机图形学、机器学习、AR/VR等领域的技术创新和业务落地不断探索新技术与新用户体验的最佳结合点。目前Y-tech在北京、深圳、杭州、Seattle、Palo Alto有研发团队大部分成员来自于国际知名公司和大学。如果你对我们做的事情很感兴趣希望一起做酷炫的东西创造更大的价值请联系我们ytechservicekuaishou.com。
