Zenith.NET v0.0.7：Metal 后端落地，.NET GPU 抽象的跨平台旅程

从第一行代码写下 GraphicsContext.CreateDirectX12() 到今天 GraphicsContext.CreateMetal() 跑通全部测试，Zenith.NET 终于实现了最初的承诺——用同一套 .NET API 覆盖三大图形后端。
这篇文章聊聊 Metal 后端的技术选型、架构设计，以及 Zenith.NET 作为一个 .NET GPU 抽象层的设计哲学。
为什么要做 Zenith.NET？

.NET 生态有不少图形相关的库——绑定层如 Silk.NET、Vortice，抽象层如 Veldrid、Evergine。但现有的抽象层要么停留在较旧的 API 版本（如 DX11/OpenGL），要么是商业引擎的一部分，难以作为独立的 GPU 抽象层使用。
Zenith.NET 的定位是：一个面向现代图形 API（DirectX 12、Metal 4、Vulkan 1.4）的轻量 GPU 抽象层，只做抽象、不做引擎，让开发者写一次代码、跑在所有平台上。
这就是 Zenith.NET 要做的事：
后端策略DirectX 12Windows 独占，性能天花板Metal 4Apple 全平台，仅支持 Apple SiliconVulkan 1.4跨平台兜底，覆盖 Linux/Android三个后端不是互相替代的关系，而是各守一方——在每个平台上选最原生的那个 API。
Metal 后端：架构决策

为什么选 Metal.NET？

v0.0.6 的 release notes 里提到过，当时在 SharpMetal 和 .NET macios TFM 之间评估。最终选了 Metal.NET（NuGet 包 Metal.NET 2.3.0）——这是我在开发期间制作的绑定库。相比 SharpMetal，Metal.NET 提供更完善的 Metal 4 API 覆盖，并且所有接口都是类型安全的。
不过坦率地说，Metal.NET 基于 class 封装 Objective-C 对象，在 GC 方面会有一定开销。
整体结构

Zenith.NET 抽象Metal 实现GraphicsContextMTLDevice + MTL4Compiler + MTLResidencySetCommandBufferMTL4CommandBuffer + 双编码器（Render/Compute）ResourceLayout绑定槽位计数（Buffer/Texture/Sampler）ResourceTableMTL4ArgumentTable，通过 GPU 地址绑定资源PipelineMTLRenderPipelineState + MTLDepthStencilStateSwapChainCAMetalLayer + CAMetalDrawableAccelerationStructureMTLAccelerationStructure + 实例缓冲区Metal 4 新特性的应用

Metal 4 引入了几个对抽象层至关重要的新特性，Zenith.NET 的 Metal 后端全面采用了它们。
MTL4ArgumentTable——这是 Metal 4 全新的资源绑定模型。相比旧版 Metal 需要逐个 setBuffer/setTexture/setSampler 绑定资源，Argument Table 允许将所有资源打包到一张表中，通过 GPU 地址一次性绑定。这与 Zenith.NET 的 ResourceLayout + ResourceTable 抽象天然吻合：
Zenith.NETMetal 4ResourceLayout声明 Buffer/Texture/Sampler 槽位计数ResourceTable创建 MTL4ArgumentTable，填入 GPU 地址SetResourceTable()一次调用绑定整张表MTL4CommandBuffer 采用双编码器模型——同一时刻只能有一种活跃编码器。CommandBuffer 默认开启 Compute 编码器，当用户开启渲染 Pass 时关闭 Compute、切换到 Render 编码器；Pass 结束后自动切回 Compute：

1. [Compute 编码器] → 开启 Pass → [Render 编码器] → 结束 Pass → [Compute 编码器]

复制代码

这样设计的好处是：Compute 编码器始终可用于拷贝（Blit）和计算调度，用户无需手动管理编码器生命周期。所有拷贝操作都走 Compute Encoder 的 Blit 路径，统一了屏障语义。
MTL4Compiler 支持设备端编译——把 Slang 输出的 metallib IR 在目标 GPU 上编译为最终 ISA，比传统 offline 编译能更好地利用 GPU 特定优化。
Objective-C 内存桥接

Metal API 基于 Objective-C 运行时，返回的对象都是 autoreleased 的——出了当前 autorelease pool 就会被回收。在 .NET 的托管环境里，这是个隐蔽的坑。
解决方案是一个统一的桥接工具：

1. public static T Own<T>(Func<T> func) where T : NSObject
2. {
3.     using NSAutoreleasePool _ = new();
4.     return func().Retain();
5. }

复制代码

所有从 Metal API 获取的对象都通过 NSAutorelease.Own() 包装，确保 Retain 延长生命周期，后续由 .NET 的 Dispose 模式释放。
Shader 编译：Slang 统一管线

三个后端共享同一套 Slang 着色器源码：

1. .slang 源文件
2.     ├─→ metallib (Metal Shader Library)
3.     ├─→ dxil     (DirectX Intermediate Language)
4.     └─→ spirv    (SPIR-V for Vulkan)

复制代码

开发者只需维护一份 .slang 着色器，编译到哪个后端由 Slangc.NET 自动处理。
光线追踪

Metal 后端完整支持硬件光线追踪：

• BLAS/TLAS：标准的两级加速结构
  
• 实例缓冲区：CPU 可写的间接寻址，更新 transform 无需重建 TLAS
  
• RayQuery：在任意着色器阶段内联查询，无需专用光追管线
  

这与 v0.0.6 移除 RayTracingPipeline 的决策一脉相承——统一用 RayQuery，三个后端的光追能力完全对齐。
设计哲学

只暴露共同能力

Zenith.NET 的核心原则是：采用最新 API 版本，只暴露三个后端共同支持的能力。平台特有的特性被刻意排除，以维护一致的跨平台体验。
这意味着你不会在 Zenith.NET 的 API 里看到 DX12 的 Enhanced Barriers、Vulkan 的 Push Descriptors 或 Metal 的 Tile Shading——这些都是某个 API 独有的。暴露出来只会让其他后端无法实现，破坏"一次编写、处处运行"的承诺。
对于硬件能力差异（比如并非所有 GPU 都支持光追），则通过 Capabilities 动态查询：

1. if (context.Capabilities.RayTracingSupported) { /* 光追路径 */ }
2. if (context.Capabilities.MeshShadingSupported) { /* Mesh Shader 路径 */ }

复制代码

共同能力统一暴露，硬件差异动态检测——这是 Zenith.NET 和其他抽象层最大的区别。
每个平台用最原生的 API

Zenith.NET 不像 bgfx 那样用 Vulkan 覆盖所有平台。在 Windows 上用 DirectX 12，在 Apple 上用 Metal 4，在 Linux/Android 上用 Vulkan 1.4。
虽然上层只暴露共同能力，但每个后端内部都用对应 API 最地道的方式实现——不需要在一种 API 上模拟另一种 API 的行为模式。
AOT 友好

整个库从第一天就为 Native AOT 设计。没有反射、没有动态代码生成、没有 Activator.CreateInstance。Metal.NET 和 Silk.NET 底层都是 P/Invoke + 函数指针，AOT 编译器能完整处理。
下一步

Metal 后端落地后，Zenith.NET 的三大后端全部就位。接下来的重点：

• SkiaSharp 集成——用 GPU 后端加速 2D 渲染
  
• API 稳定化——向 1.0 迈进
  

Zenith.NET 是开源项目，欢迎关注：

• GitHub：github.com/qian-o/Zenith.NET
  
• 文档站：qian-o.github.io/Zenith.NET
  
• NuGet：搜索 Zenith.NET
  

本文由 AI 辅助生成，经作者审核校对。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！