SakuraEngine
[Graphics] Resource Barrier 改进和 Render Graph 重构
经过较长一段时间的需求验证、性能调优和试错，现在的 CGPU 和 RenderGraph 在释出稳定版本前，还有如下几个比较重大的问题：
- 在 API 成型时对
Resource Barrier没有做Pipeline Stage级别的同步控制，这样阶段同步其实是通过推断猜测出来的。- 在管道内同步情况下这样的实现方法并不够用，例如在一个
Pipeline的PixelStage读MSAA Resolve Target，在Resolve Stage覆写其内容； - 需要提供一套改进的
Resource Barrier接口，逐步弃用旧接口，改进同步；
- 在管道内同步情况下这样的实现方法并不够用，例如在一个
-
Render Graph现在只是一套初步的验证式的工件，为了适应后续的需求，需要实现地更加完善和系统化。- 现在很多内容是
interpret而非compile的，这样实现和维护方便而不利于优化； - 应该添加更加细致的
compile流程； - 多队列需要支持、
memory aliasing可以实现地更加彻底； - 接口是验证较为良好的，因此保持前端目前的接口。
- 现在很多内容是
参考 RPSL 的做法，并没有分离逻辑前后端，而是分离了图和设备。在实际实现中，确实发现图在编译阶段也是需要后端参与并提供一定辅助的（比如 memory 预算探测和相容性检测）。
因此我们也参照此方法，分离数据和实现不同的 Phase，把逻辑交给 Phase 概念实现，后端只作为一个 RenderGraph 基类覆盖器和调度器糖存在。录制好的参数数据交给不同的 GraphPhase 进行处理，处理的上下文包含图本身和设备的引用。
重写工作拆分成两个部分：
- [ ] 前端接口和数据结构大部分保留，先进行一遍修整，方便后端重写；
- [ ] 后端基本需要完全重写。
现在比较大的问题是，VRAM Service 的很多 resource barrier 处理并不妥当。
- 在重写
RenderGraph之前，有必要先解决这个问题； - 我们有合并
LuisaCompute作为模块的未来计划，也许合并后我会对RenderGraph有新的想法。
所以这个 issue 暂时搁置，我们先在 #73 实现一个新的 VRAM Service。
我有一个想法，renderpass/framebuffer/pipeline cache等的管理是否可以移到render graph里？这样cgpu就可以更薄了。cache的Key也可以更灵活。因为在很多语言里数组都只能从堆分配，而renderpass/framebuffer/pipeline等的desc都要涉及到大量的数组，如果把key移出cgpu，那么可能会更灵活，也有潜在的性能提升。
我有一个想法，renderpass/framebuffer/pipeline cache等的管理是否可以移到render graph里？这样cgpu就可以更薄了。cache的Key也可以更灵活。因为在很多语言里数组都只能从堆分配，而renderpass/framebuffer/pipeline等的desc都要涉及到大量的数组，如果把key移出cgpu，那么可能会更灵活，也有潜在的性能提升。
CGPU 没有 pipeline cache 吧，本来就是外部提供的 PSO Map。RenderPass 和 FrameBuffer 这些本身就是兼容性抽象，我们选择用值描述 OpenPass 是因为在大多数平台上 Pass 和 FB 本身就是个空壳，所以不想开一个额外的对象。你说的这个需求，感觉在外部语言开个对象，把 Desc 装进去也能实现？
还有请问有cgpu独立出仓库的时间表吗？
项目要用引擎，最近在花大功夫拆外部依赖做准备，没时间做这个。并且 CGPU 的 API 要引入不少重构，同时适配好 Metal，一些能在 issues 里看到，这个过程会引入很大变化。计划是先独立出一个模块，可以单独构建。
还有请问有cgpu独立出仓库的时间表吗？
项目要用引擎，最近在花大功夫拆外部依赖做准备，没时间做这个。并且 CGPU 的 API 要引入不少重构，同时适配好 Metal，一些能在 issues 里看到，这个过程会引入很大变化。计划是先独立出一个模块，可以单独构建。
我花了些把cgpu的vulkan部分独立出来了，放在了这里：https://github.com/vkensou/cgpu 请问介意我这个库也叫cgpu吗？如果介意我可以改名。