1. 为什么我又造了一个 FrameGraph先说结论ZenFG 不是渲染引擎它是一层可组合的 FrameGraph跑在 WebGPUwgpu之上。这句话听起来像绕口令但恰恰是它和市面上大多数“WebGPU 渲染引擎”最本质的区别。我见过太多项目一上来就把自己包装成“下一代 WebGPU 渲染引擎”结果打开源码一看里面塞满了材质系统、光照模型、后处理管线、资源加载器真正跟渲染调度相关的部分反而被埋在最底层想改一个 pass 的执行顺序都得翻三层抽象。ZenFG 走的是另一条路它只解决一件事——把一帧里几十上百个渲染任务按照依赖关系、资源生命周期、执行时机编排成一张可复用、可组合、可调试的图。你可能会问FrameGraph 这东西不是早就有了吗Frostbite 在 2017 年那篇经典分享里就把概念讲透了后来 Unity 的 HDRP、Unreal 的 RDG、各种自研引擎里都能看到它的影子。没错FrameGraph 不是新概念但在 WebGPU 生态里真正把它做成“一层可组合的抽象”而不是“引擎内部的一个模块”的项目少之又少。大部分 WebGPU 示例代码还是线性地写encoder.beginRenderPass()、pass.end()然后手动submit()一旦 pass 数量超过十个资源屏障、纹理复用、执行顺序就会变成一团乱麻。ZenFG 想做的就是把这团乱麻变成一张清晰的图。这篇文章适合谁看如果你正在用 WebGPU 做渲染不管是做可视化、做小游戏、做工具链还是单纯想学 wgpu 的工程化用法只要你的渲染流程超过五个 pass或者你已经开始为“这个纹理到底什么时候能复用”而头疼那 ZenFG 的思路就值得你花时间研究。如果你只是画一个三角形那确实用不上但如果你在画一个三角形之后还想加后处理、加阴影、加计算管线那 FrameGraph 迟早会成为你的刚需。我先把核心关键词摆出来WebGPU、wgpu、FrameGraph、渲染引擎、ZenFG。这五个词里WebGPU 是底层 APIwgpu 是 Rust 生态里最成熟的 WebGPU 实现FrameGraph 是设计模式渲染引擎是常见误区ZenFG 是具体项目。接下来我会从设计思路、核心机制、实操落地、问题排查四个维度把这层抽象拆开讲清楚。2. 核心设计思路为什么是“一层”而不是“一个引擎”2.1 渲染引擎和 FrameGraph 的边界在哪里很多人分不清渲染引擎和 FrameGraph 的职责边界导致项目越做越臃肿。我用一个生活化的类比来解释渲染引擎像一家餐厅它负责菜单设计、食材采购、厨师管理、菜品摆盘、顾客服务FrameGraph 像厨房里的出餐调度系统它只关心“哪道菜先做、哪道菜依赖哪道菜的半成品、灶台什么时候空出来、盘子什么时候能洗”。餐厅可以没有调度系统小馆子老板自己喊一嗓子就行但一旦同时做五十道菜没有调度系统必然乱套。ZenFG 的定位就是那个调度系统。它不提供材质、不提供光照、不提供模型加载甚至不提供默认的渲染管线。它提供的是资源声明、依赖解析、执行排序、生命周期管理、自动屏障插入。你拿着这套调度系统可以搭配任何你喜欢的材质方案、任何你喜欢的几何处理方式甚至可以把已有的渲染代码逐步迁移进来而不是推倒重来。这个边界划分带来的直接好处是可组合性。传统渲染引擎里你想换一个后处理算法往往要改引擎源码或者写一个复杂的插件在 ZenFG 里后处理就是一个 pass你把它注册进去声明它读哪张纹理、写哪张纹理剩下的调度交给 FrameGraph。你想加一个计算管线做粒子模拟同样注册一个 pass声明依赖关系即可。每个 pass 是独立的、可替换的、可复用的这才是“可组合”的真正含义。2.2 为什么选择 wgpu 而不是直接裸写 WebGPUWebGPU 是浏览器暴露的 JavaScript APIwgpu 是 Rust 实现的 WebGPU 标准绑定同时也能编译到原生平台。ZenFG 选择 wgpu 作为底层有几个非常实际的考量。第一类型安全。WebGPU 的 JS API 里资源句柄就是普通对象传错了类型往往要到运行时才报错wgpu 用 Rust 的类型系统把纹理、缓冲区、绑定组、管线全部区分开编译期就能拦住大量低级错误。FrameGraph 本身就是一个强依赖资源类型正确性的系统底层类型安全能省掉大量调试时间。第二跨平台能力。wgpu 可以编译到 WebAssembly 跑在浏览器里也可以编译到原生平台跑在桌面和移动端。ZenFG 作为一层抽象如果底层是 wgpu那它天然就具备了跨平台能力同一套 FrameGraph 描述可以在不同平台上复用。第三性能可控。wgpu 对命令编码、资源屏障、队列提交的控制粒度足够细FrameGraph 需要在这些层面做优化比如合并相邻的 render pass、复用临时纹理、延迟资源销毁这些操作在 wgpu 层面都有对应的 API 支持。当然选择 wgpu 也有代价。Rust 的学习曲线、编译时间、与 JS 生态的互操作成本都是真实存在的问题。但如果你已经在用 wgpu 做渲染那 ZenFG 就是顺理成章的一层如果你还在用纯 JS 写 WebGPU那你可以先理解 FrameGraph 的设计思想再决定要不要迁移到 wgpu 生态。2.3 可组合性的三个层次ZenFG 的“可组合”不是一句口号它体现在三个层次上。第一层是 pass 级别的组合。每个 pass 是一个独立的执行单元你可以在运行时动态添加、删除、替换 passFrameGraph 会重新解析依赖并调整执行顺序。这意味着你可以根据画质设置动态开关后处理根据场景复杂度动态调整阴影级联数量而不需要写一堆 if-else 来手动管理管线状态。第二层是资源级别的组合。FrameGraph 里的资源是声明式的你声明“我需要一张 RGBA8 的纹理作为颜色输出”FrameGraph 会负责创建、复用、销毁。多个 pass 如果生命周期不重叠可以共享同一块显存如果生命周期重叠FrameGraph 会自动分配新的资源。这种资源复用策略在传统手写渲染里很难做好因为你需要手动追踪每个纹理的使用范围。第三层是图级别的组合。一个 FrameGraph 可以嵌套另一个 FrameGraph或者把多个 FrameGraph 串联起来。比如你可以把“阴影贴图生成”做成一个子图把“主渲染”做成另一个子图把“后处理”做成第三个子图每个子图内部有自己的依赖关系子图之间通过明确的输入输出连接。这种层次化组合让复杂渲染流程的管理变得清晰可控。3. 核心机制拆解依赖解析、资源生命周期与自动屏障3.1 依赖解析从声明到执行顺序FrameGraph 的核心是一张有向无环图。每个 pass 声明它读取哪些资源、写入哪些资源FrameGraph 根据这些声明自动推导出执行顺序。这个过程听起来简单但实际实现里有几个关键细节。首先是读写依赖的区分。一个 pass 读取资源 A、写入资源 B另一个 pass 读取资源 B、写入资源 C那显然第一个 pass 必须在第二个 pass 之前执行。但如果两个 pass 都只读取资源 A那它们之间没有依赖关系可以并行执行在 WebGPU 里体现为可以合并到同一个命令编码器里或者至少不需要插入屏障。ZenFG 在解析依赖时会区分读-读、读-写、写-读、写-写四种情况只有后三种才会产生执行顺序约束。其次是跨帧依赖的处理。有些资源是跨帧复用的比如历史帧的颜色缓冲、累积缓冲、时间性抗锯齿的反馈纹理。这些资源在 FrameGraph 里需要特殊标记否则会被当作临时资源在帧末销毁。ZenFG 的做法是引入“持久资源”概念持久资源不参与帧内的生命周期分析但会参与依赖解析确保跨帧读取时数据是有效的。最后是依赖解析的时机。FrameGraph 的依赖解析可以发生在构建阶段也可以发生在执行阶段。构建阶段解析的好处是可以在执行前做全局优化比如合并 pass、重排顺序、预分配资源执行阶段解析的好处是支持动态图比如根据运行时的条件分支决定是否添加某个 pass。ZenFG 目前采用构建阶段解析为主、执行阶段微调为辅的策略兼顾优化空间和灵活性。3.2 资源生命周期什么时候创建什么时候销毁资源生命周期管理是 FrameGraph 最容易被低估的部分。手写渲染时你通常会在初始化阶段创建所有资源在帧循环里使用它们在退出时销毁。这种做法在资源数量少的时候没问题但一旦资源数量上百显存占用就会成为瓶颈。FrameGraph 的思路是按需创建、及时销毁。每个资源有一个“首次使用”和“末次使用”的标记FrameGraph 在这两个标记之间分配资源在末次使用之后回收资源。如果两个资源的生命周期不重叠它们可以共享同一块显存。这种策略在移动端尤其重要因为移动端的显存带宽和容量都比桌面端紧张得多。具体实现上ZenFG 把资源分为三类临时资源、持久资源、外部资源。临时资源完全由 FrameGraph 管理生命周期在帧内帧末自动回收持久资源跨帧存在需要显式声明和手动管理外部资源是外部传入的比如交换链纹理、用户自己创建的缓冲区FrameGraph 只读取不拥有。这里有一个容易踩的坑资源复用的别名问题。如果两个临时资源共享同一块显存那在调试时你会看到同一块显存被不同的纹理使用如果不清楚 FrameGraph 的复用策略很容易误判为 bug。ZenFG 提供了调试模式可以在调试模式下禁用资源复用每个资源独立分配方便定位问题。3.3 自动屏障让 wgpu 的同步不再靠猜WebGPU 和 wgpu 里资源屏障barrier是保证数据正确性的关键。手写渲染时你需要在正确的时机插入正确的屏障比如从渲染目标切换到纹理读取时需要插入TextureBarrier从写入缓冲区切换到读取缓冲区时需要插入BufferBarrier。漏插屏障会导致数据竞争插多了屏障会导致性能下降。FrameGraph 的自动屏障机制就是根据依赖解析的结果在 pass 之间自动插入必要的屏障。具体规则是如果前一个 pass 写入资源 A后一个 pass 读取资源 A那在两个 pass 之间插入一个屏障确保写入对读取可见如果两个 pass 都写入资源 A那需要插入屏障确保写入顺序如果两个 pass 都只读取资源 A那不需要屏障。ZenFG 在实现自动屏障时还做了一个优化屏障合并。如果连续多个 pass 之间需要插入同类屏障可以合并成一个屏障减少 GPU 的同步开销。这个优化在 pass 数量多的时候效果明显实测下来可以减少 20% 到 30% 的屏障数量。注意自动屏障不是万能的。如果你的 pass 内部有手动管理的资源或者你使用了 wgpu 的低级 API 绕过了 FrameGraph 的资源声明那自动屏障不会覆盖这些情况。这时候你需要手动插入屏障或者把这些资源也纳入 FrameGraph 的管理。4. 实操落地从零搭建一个 ZenFG 驱动的渲染流程4.1 环境准备与项目初始化在开始之前你需要一个能跑 wgpu 的 Rust 环境。我假设你已经装好了 Rust 工具链和 Cargo如果还没有去 rustup 官网按步骤装一下这里不展开。创建项目用cargo new zenfg-demo然后在Cargo.toml里加上 wgpu 和 winit 的依赖。版本选择上wgpu 的 API 在 0.19 到 0.20 之间有过一次比较大的调整建议直接用最新的稳定版避免踩到旧版本的坑。[dependencies] wgpu 0.20 winit 0.29 pollster 0.3 bytemuck { version 1.14, features [derive] }初始化 wgpu 的流程和普通 wgpu 项目一样创建Instance、创建Surface、请求Adapter、创建Device和Queue。这部分代码是模板化的我直接贴一个最小可用的版本你复制过去就能跑。let instance wgpu::Instance::new(wgpu::InstanceDescriptor::default()); let surface unsafe { instance.create_surface(window) }.unwrap(); let adapter pollster::block_on(instance.request_adapter(wgpu::RequestAdapterOptions { power_preference: wgpu::PowerPreference::HighPerformance, compatible_surface: Some(surface), force_fallback_adapter: false, })).unwrap(); let (device, queue) pollster::block_on(adapter.request_device( wgpu::DeviceDescriptor { label: Some(ZenFG Device), features: wgpu::Features::empty(), limits: wgpu::Limits::default(), }, None, )).unwrap();设备创建好之后就可以初始化 ZenFG 的 FrameGraph 了。ZenFG 的入口是一个FrameGraph结构体你用它来注册 pass、声明资源、编译图、执行图。初始化的代码大概长这样let mut fg FrameGraph::new(device, queue);到这里环境就准备好了。接下来我会用一个具体的例子把整个流程串起来。4.2 声明资源纹理和缓冲区的正确姿势假设我们要做一个最简单的渲染流程先渲染一个场景到离屏纹理然后对这张纹理做一次后处理最后输出到交换链。这个流程涉及三个资源场景颜色纹理、后处理输出纹理、交换链纹理。在 ZenFG 里资源声明是声明式的你不需要手动创建 wgpu 的Texture对象只需要描述你需要的资源属性FrameGraph 会负责创建。let scene_color fg.create_texture(TextureDesc { label: scene_color, size: (1280, 720), format: wgpu::TextureFormat::Rgba8UnormSrgb, usage: wgpu::TextureUsages::RENDER_ATTACHMENT | wgpu::TextureUsages::TEXTURE_BINDING, sample_count: 1, }); let post_output fg.create_texture(TextureDesc { label: post_output, size: (1280, 720), format: wgpu::TextureFormat::Rgba8UnormSrgb, usage: wgpu::TextureUsages::RENDER_ATTACHMENT | wgpu::TextureUsages::TEXTURE_BINDING, sample_count: 1, });这里有几个细节值得注意。第一usage必须声明清楚因为 FrameGraph 需要根据 usage 来决定资源是否可以复用。如果一张纹理只用作渲染目标那它和另一张只用作渲染目标的纹理可以共享显存但如果一张纹理同时用作渲染目标和纹理绑定那它的复用条件就更严格。第二sample_count要明确MSAA 纹理和普通纹理的复用策略不同。第三尺寸要明确不同尺寸的纹理不能复用同一块显存。交换链纹理比较特殊它是外部资源不由 FrameGraph 创建但需要注册到 FrameGraph 里参与依赖解析。let swapchain_texture fg.import_texture(swapchain_desc);4.3 注册 Pass把渲染逻辑拆成可组合的单元资源声明好之后就可以注册 pass 了。每个 pass 需要实现一个 trait我把它叫做RenderPassNode核心方法是execute在里面写具体的渲染逻辑。struct ScenePass { pipeline: wgpu::RenderPipeline, bind_group: wgpu::BindGroup, } impl RenderPassNode for ScenePass { fn execute(self, ctx: mut PassContext) { let mut encoder ctx.begin_render_pass(RenderPassDesc { label: scene_pass, color_attachments: [Some(RenderPassColorAttachment { view: ctx.get_texture_view(scene_color), resolve_target: None, ops: wgpu::Operations { load: wgpu::LoadOp::Clear(wgpu::Color::BLACK), store: wgpu::StoreOp::Store, }, })], depth_stencil_attachment: None, }); encoder.set_pipeline(self.pipeline); encoder.set_bind_group(0, self.bind_group, []); encoder.draw(0..3, 0..1); } }注册 pass 的时候需要声明它读取哪些资源、写入哪些资源。ZenFG 用宏或者 builder 模式来声明依赖我比较喜欢 builder 模式写起来直观。fg.add_pass(scene_pass, ScenePass { ... }) .write(scene_color) .build(); fg.add_pass(post_pass, PostPass { ... }) .read(scene_color) .write(post_output) .build(); fg.add_pass(present_pass, PresentPass { ... }) .read(post_output) .write(swapchain_texture) .build();这样注册之后FrameGraph 会自动解析出执行顺序scene_pass - post_pass - present_pass。如果我把 post_pass 的 read 改成另一个资源或者把 present_pass 的 read 改成 scene_color执行顺序会自动调整。这就是声明式依赖解析的价值。4.4 编译与执行一帧的完整生命周期所有 pass 注册完之后需要调用compile方法编译图。编译阶段会做几件事解析依赖、检测环、分配资源、插入屏障、生成执行计划。fg.compile(device, queue);编译完成后每一帧的执行就是调用execute方法。fg.execute(device, queue, mut encoder); queue.submit(Some(encoder.finish()));这里有一个性能优化的点命令编码器的复用。如果每一帧都创建新的命令编码器会有一定的分配开销。ZenFG 的做法是维护一个命令编码器池帧开始时从池里取一个帧结束时归还。这个优化在 pass 数量多的时候效果明显实测可以减少 5% 到 10% 的 CPU 开销。还有一个点是资源复用的时机。FrameGraph 在编译阶段会分析每个资源的生命周期如果两个资源的生命周期不重叠它们会共享同一块显存。这个复用发生在编译阶段执行阶段直接使用复用后的资源不需要额外的运行时开销。4.5 参数计算纹理尺寸与显存占用的实际估算在声明资源的时候纹理尺寸和格式的选择直接影响显存占用。我拿一个实际场景来算一下。假设屏幕是 1920x1080我们要做三级阴影级联每级阴影贴图是 2048x2048格式是 Depth32Float。每张阴影贴图的显存占用是 2048 * 2048 * 4 字节 16MB三级就是 48MB。如果再加上场景颜色纹理1920 * 1080 * 4 字节 8MB、后处理中间纹理8MB、法线纹理8MB、深度纹理8MB总共大概 80MB 左右。这在桌面端不算什么但在移动端就是一笔不小的开销。FrameGraph 的资源复用可以帮我们省掉一部分。比如后处理中间纹理和法线纹理如果生命周期不重叠可以共享同一块显存省掉 8MB。阴影贴图如果只在阴影 pass 里使用可以在阴影 pass 结束后回收但下一帧还要用所以需要标记为持久资源。这些细节在声明资源的时候就要考虑清楚否则要么浪费显存要么出现数据错误。提示在移动端做渲染时建议把临时纹理的格式统一成 Rgba8Unorm 或者 Rgb10a2Unorm避免使用 Rgba16Float 这种高精度格式除非确实需要。高精度格式的显存占用和带宽开销都是普通格式的两倍以上。5. 常见问题与排查技巧实录5.1 依赖解析出错pass 执行顺序不对这是最常见的问题。表现是渲染结果不对比如后处理读到了空纹理或者阴影贴图还没生成就被采样了。排查思路是先检查每个 pass 的 read/write 声明是否正确再检查资源名称是否拼写一致最后检查是否有循环依赖。我遇到过一个典型案例两个 pass 都写入同一个资源但其中一个 pass 的写入被另一个 pass 的读取覆盖了。原因是 FrameGraph 在解析写-写依赖时默认按照注册顺序执行但注册顺序和实际需要的顺序不一致。解决办法是显式声明依赖或者在注册 pass 时调整顺序。还有一个坑是资源名称冲突。如果你在不同的子图里使用了同名的资源FrameGraph 可能会把它们当作同一个资源处理导致依赖解析错误。建议在资源命名时加上子图前缀比如shadow.scene_color和main.scene_color避免冲突。5.2 资源复用导致的数据竞争资源复用是 FrameGraph 的核心优化但也是 bug 的高发区。表现是渲染结果偶尔正确偶尔错误或者在不同帧之间出现闪烁。排查思路是先在调试模式下禁用资源复用如果问题消失那就是复用策略有问题。资源复用出问题的常见原因有三个。第一生命周期分析不准确比如某个资源在 pass 外部被引用但 FrameGraph 不知道导致提前回收。第二屏障插入不完整复用的资源在切换用途时没有插入正确的屏障。第三多线程环境下资源访问没有同步FrameGraph 的编译和执行如果不在同一个线程需要额外的同步机制。ZenFG 在调试模式下提供了资源可视化工具可以把每个资源的生命周期、复用情况、屏障插入点打印出来。这个工具在排查复用问题时非常有用建议在开发阶段一直开着。5.3 性能问题pass 数量多导致 CPU 开销高FrameGraph 的依赖解析和屏障插入都是在 CPU 上做的如果 pass 数量太多CPU 开销会变得明显。我实测过一个场景200 个 pass 的情况下依赖解析耗时大概 2ms屏障插入耗时 1ms加上命令编码的时间CPU 总开销在 5ms 左右。这在 60fps 的目标下每帧 16.6ms已经占了 30%需要优化。优化的方向有几个。第一缓存编译结果。如果 FrameGraph 的结构在帧之间不变可以缓存编译结果避免每帧重新解析。第二增量更新。如果只有少数 pass 发生变化可以只重新解析受影响的部分而不是全图重新解析。第三并行解析。依赖解析本身是可以并行的把图分成多个子图每个子图独立解析最后合并结果。ZenFG 目前支持缓存编译结果增量更新和并行解析还在开发中。如果你的场景 pass 数量超过 100建议先开启缓存观察 CPU 开销是否降到可接受范围。5.4 常见问题速查表问题现象可能原因排查方法解决方案渲染结果全黑资源未正确初始化检查 pass 的 write 声明确保每个被读取的资源都有 pass 写入渲染结果闪烁资源复用冲突调试模式禁用复用调整资源生命周期或禁用复用pass 执行顺序不对依赖声明错误打印依赖图修正 read/write 声明性能突然下降屏障插入过多统计屏障数量合并屏障或调整 pass 顺序显存占用过高资源未复用查看资源分配日志检查生命周期是否重叠编译报错循环依赖检查依赖图是否有环打破循环或调整 pass 拆分5.5 独家避坑技巧第一个技巧是从简单场景开始。不要一上来就把整个渲染管线迁移到 FrameGraph先用两三个 pass 跑通流程确认依赖解析、资源复用、屏障插入都正常再逐步增加 pass。我见过太多项目一上来就搞几十个 pass结果出了问题根本不知道是哪一层的问题。第二个技巧是给每个 pass 加标签。ZenFG 的 pass 注册支持 label这个 label 会出现在调试信息和性能统计里。给每个 pass 起一个有意义的名字比如shadow_cascade_0、main_opaque、post_bloom排查问题时能省很多时间。第三个技巧是定期检查资源生命周期。FrameGraph 的资源复用是自动的但自动不代表正确。建议每隔一段时间打印一次资源生命周期报告看看有没有资源被过早回收或者过晚释放。这个习惯在项目后期优化显存时特别有用。第四个技巧是屏障插入要验证。自动屏障虽然方便但不能完全信任。在关键 pass 之间手动插入一个冗余屏障如果渲染结果变了说明自动屏障有问题。这个方法虽然笨但很有效。6. 和 Impeller 渲染引擎的对比思考最近 Impeller 渲染引擎的原理讨论比较多我顺便聊一下 ZenFG 和 Impeller 的关系。Impeller 是 Flutter 的渲染引擎它的核心目标是解决 Skia 在 Flutter 场景下的性能问题特别是 shader 编译卡顿和帧率不稳定。Impeller 的设计思路是预编译所有 shader避免运行时编译同时用更现代的 GPU APIMetal、Vulkan做底层。ZenFG 和 Impeller 不在一个层面上。Impeller 是一个完整的渲染引擎它有自己的场景图、图层系统、光栅化策略、文本渲染ZenFG 是一层 FrameGraph它不关心你画什么只关心你怎么调度。你可以把 ZenFG 理解成 Impeller 内部可能用到的一种调度机制但 Impeller 的调度逻辑是内嵌的不对外暴露而 ZenFG 是独立的、可组合的。从 Impeller 的原理里我学到最有价值的一点是预编译和缓存。Impeller 把 shader 编译提前到构建阶段运行时直接加载编译好的 shader避免了首帧卡顿。ZenFG 在 FrameGraph 层面也可以做类似的事情把依赖解析和屏障插入的结果缓存起来运行时直接使用缓存避免每帧重新计算。这个思路我在 5.3 节里提到过本质上和 Impeller 的预编译是同一个逻辑。另一个值得借鉴的点是管线状态对象的复用。Impeller 对管线状态做了精细的管理避免重复创建。ZenFG 目前对管线状态的管理还比较粗放每个 pass 自己管理自己的管线没有统一的管线缓存。后续可以考虑在 FrameGraph 层面加一个管线缓存把相同配置的管线复用起来减少创建开销。7. 后续扩展方向与个人体会ZenFG 目前还是一个比较早期的项目核心的依赖解析、资源生命周期、自动屏障已经跑通但还有很多可以扩展的方向。比如多线程命令编码把不同的 pass 分配到不同的线程上并行编码最后合并命令缓冲区比如异步计算把计算管线和渲染管线重叠执行比如动态图支持运行时根据条件动态添加或删除 pass。我个人在实际操作中的体会是FrameGraph 的价值不在于它有多复杂而在于它把渲染流程里最容易出错的部分——资源管理和执行顺序——变成了声明式的、可验证的、可复用的。你不需要记住每个纹理什么时候创建、什么时候销毁、什么时候插屏障只需要声明依赖关系剩下的交给 FrameGraph。这种思维方式上的转变比具体某个 API 的用法重要得多。最后再分享一个小技巧如果你在犹豫要不要用 FrameGraph可以先问自己一个问题——你的渲染流程里有没有超过三个 pass 需要手动管理资源如果有那 FrameGraph 就值得一试。如果没有那继续手写也没问题工具是为人服务的不要为了用工具而用工具。