GDC2017：Framegraph-extensible-rendering-architecture-in-frostbite

https://www.slideshare.net/DICEStudio/framegraph-extensible-rendering-architecture-in-frostbite

J:\Download\GDC\2017\GDC-FrameGraph.pptx

FrameGraph-Extensible_Rendering_Architecture_in_Frostbite.mp4

• 改进引擎的扩展性
• 简化一步计算
• ESRAM
• 
  

• DICE次时代引擎
• EA引擎
• 
  

• 游戏列表

• 07年引擎的渲染系统
• 
  

• 对比17年的
• 除了绿色部分，整体架构貌似差不多

• 简版的渲染系统
• 前向、后向
• 渲染上下文（RC），
• WR：

• 详细解释一下WR
• 代码驱动？
• 负责分配渲染资源（RT，Buffers）

• 战地四 用到渲染特性
• 
  

• WR的挑战：
• 
  
• 资源管理
  • 各自手工管理ESRAM
  • 每个Team有各自的实现方式
  • 
    
• 和渲染系统高耦合
• 可扩展性差
• 代码量：4k行上涨到15K行
  • 单个函数超过2k行
  • 维护代码合并、集成代码代价很大

• 模块化的WR实现目标：
  • 
    
  • 改进可扩展性
    • 低耦合、组件式代码模块
    • 自动化资源管理
  • 可视化、可调试

• 新架构中，添加了FrameGraph和Transient Resouces
• 
  

• 现在解释FG
• FG主要解决的问题
  • 能构建整个帧的图节点
    • 简化资源管理
    • 简化渲染管线的配置
    • 简化异步计算和资源隔离
  • 能DIY
  • 可视化和Debug

• 举一个FG的例子
• 橙色节点是渲染操作节点,蓝色节点是资源节点
• 能看到整个渲染管线流程

• 战地4中的一个FrameGraph
• 上百个Pass和Resouce节点
• 
  
• 超级大的Graph
• 
  
• 
  

• 演示内存分布

• 脱离Immediate mode （底层模式）
• 渲染的代码抽取到passes
• 多阶段 retained mode （高端模式）
  • Setup
  • Compile
  • Execute
• 这样做就是要统一模式，固定？
• 代码驱动架构？

• 详细及时FG的每个阶段
• 解释Setup阶段
  • 定义了RenderPass和ComputePass
  • 定义了资源的输入输出
  • 代码流程类似于ImmediateMode

•  在RenderPass中需要控制所有可用资源
  • 可读
  • 可写
  • 可创建
• 其他永久性的资源用Import形式到FrameGraph
  • Historybuffer
  • BackBuffer
  • 等
  • 全局buffer？
  • 固定

• 举例说明一个Resource例子
• 创建一个renderTarget

• 
  

• Setup的一个例子

• 高级操作
  • 延迟创建资源
  • 继承资源参数
  • 移动子资源？

• 延迟渲染模块到反射模块
• 解释MoveSubresource

• 编译阶段：
• 去除没有引用到的资源
• 分配实在的GPU资源
• 
  

• 禁用掉Lighting过程
• 插入DebugView
• 再将结果Move到FinalTarget上
• 这就是截断的例子

• 执行阶段：
  • 执行回调
  • ImmediateMode
    • 调用渲染API
    • 设置state、resource、Shader
    • Draw、Dispatch
  • 在这个阶段获取GPU的实际使用资源（GPU层）

• 异步计算：
  • 自动继承过来
  • 手动控制的问题
    • 内存增长
    • 滥用影响性能
  • 
    

• 主线程到异步线程过程
• 
  

• 采用C++类形式改造的问题：
  • 破坏代码流程
  • 需要大量引用？
  • 导出现有代码到C++类太费力
• 考虑使用 C++Lambdas （C++14）
  • 保存原有代码流程
  • 在原有基础上最小的改动
    • 在原有代码上包裹一层Lambda
    • 添加一个ResourceUsage定义

• 一个例子
• &和= 重载？
• 
  

• 渲染模块（每种Feature？）
• 渲染模块有两种类型
  • 独立无状态函数？
    • 输入输出是FG的Resource
    • 可以嵌套Pass
    • 这个是最常用的类型
  • 常驻类型
    • 常驻资源相关（LUTs History buffers）
• WR仍然属于高层级的渲染
  
  • 不会去分配GPU资源
    
  • 仅仅是控制各个渲染模块的开关
    
  • 更加易于扩展
    
  • 代码量从15K行减到5K行
    

• modules之间的通信
• 通过blackboard（黑板）通信
  • component的hash表
• 举例说明
  • BlurModule和TonemapModule通信
  • blackboard.get<BlurPyramidData>

• 临时资源管理
• 
  
• FG中的关键组件？

• 【临时资源系统底层】
• 不同平台下的不同处理
  • XB1
  • DX12 PS4
  • DX11
• Texture的内存池

• PS4上面的Texture的例子
• 在不同时期分配不同地址
• DX12上，分不同Heap
• XB1上，LightBuffer被分开了，
  • 因为随申请随用？

• 【关于内存对齐的一些建议】
• 
  

• 优先考虑DiscardResource而不是Clear

• 对齐隔离带
• CS Compute share
• PS Pixel Share

• 以战地4为例
• 147M为没有对齐的内存
• 不同平台的数据
  • DX12 80M
  • PS4 77M
  • XB1 76M

• 【总结】
• 
  

• 【将来的工作】

他的Blog

https://grahamhazel.com/blog/

来自为知笔记(Wiz)

转载于:https://www.cnblogs.com/username/p/8497150.html