J:DownloadGDC2017GDC-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