Memoryless textures能否与多个MTLRenderCommandEncoder配合使用？

核心结论 #

你描述的整套流程存在明确的可行性边界，并非全流程可落地，核心判断逻辑完全基于Memoryless Texture的底层存储模型设计：它是iOS/tvOS平台专属的资源模式，定位是仅用于临时渲染附件的零持久显存占用资源，天生不支持跨渲染阶段的资源传递。

逐环节可行性拆解 #

对应你提出的三步流程，逐一验证合规性：

• 创建命令编码器#1，将Memoryless texture #1绑定为渲染目标执行渲染
  该环节完全可行，是Metal设计Memoryless Texture的核心适用场景。只要该纹理的像素格式、采样数符合颜色/深度/模板附件的绑定要求，通过MTLRenderPassDescriptor正常绑定后，所有渲染逻辑可以无异常执行。由于Memoryless纹理不占用常驻全局显存，这种用法也是移动端降低离屏渲染显存开销的标准优化手段。
• 结束编码器#1的编码流程，创建命令编码器#2，将Memoryless texture #2绑定为新的渲染目标
  该环节单独运行完全可行，两个独立的Memoryless纹理作为不同编码器的渲染目标，不存在任何资源冲突。
• 在编码器#2中，将之前用过的Memoryless texture #1作为只读纹理参数传入片段着色器采样
  该环节存在不可逾越的硬限制，无法正常运行，核心原因有两点：
  • 存储模型限制：Memoryless纹理的内存是和绑定它的渲染通道强绑定的片上高速临时内存，从绑定附件的时刻开始分配，到对应渲染通道所有图块执行完成就立刻回收，没有可被纹理采样单元访问的全局显存地址，不存在可供后续阶段读取的持久化像素数据。
  • API校验限制：Metal运行时会对资源绑定做合法性校验，只要是MTLStorageModeMemoryless模式的纹理，一旦被尝试绑定为着色器可采样资源，会直接抛出校验错误，对应命令缓冲区根本无法提交到GPU执行。

可替代的实现思路 #

如果你需要实现“先渲染到纹理A，再将纹理A的内容作为输入渲染到纹理B”的跨编码器渲染流程，可以参考两种合规方案：

• 把需要跨编码器传递的纹理从Memoryless模式换成MTLStorageModePrivate（全平台通用）的持久化存储模式，这类纹理的像素数据会在全局显存中持久留存，上一个编码器完成渲染后，下一个编码器可以正常绑定为采样资源读取像素值。
• 如果希望在不增加常驻显存开销的前提下完成两个纹理的内容传递，可以把两个纹理都设置为Memoryless模式，绑定到同一个渲染通道中，通过可编程混合、图块着色器在同一个编码器内部完成附件间的像素值读写——这种方式不需要全局持久显存，但不属于你提到的“两个独立命令编码器”的实现路径。

内容的提问来源于stack exchange，提问作者Arsynth