轮重构的重点是新版引入了哪些能力、为什么要做 bindless 和显式屏障、两套 API 用法有什么差别以及这些变化未来会给性能和生态带来哪些空间。新版最重要的变化Zenith.NET 正在从“跨平台图形封装库”变成“面向现代 GPU 的 .NET RHI”。新版的重点不只是创建 buffer、texture、pipeline而是开始对齐现代图形 API 中更底层也更关键的能力bindless 资源访问、显式屏障、布局转换、多队列、shader-visible descriptor heap、Metal 4、Vulkan 1.4 以及 Slang 跨后端编译。核心方向包括DirectX 12 后端要求 Shader Model 6.6、Resource Binding Tier 3 和 Enhanced Barriers。DirectX 12 使用大号 shader-visible descriptor heap让 shader 能直接索引资源。Vulkan 路线开始对齐 Vulkan 1.4 和VK_EXT_descriptor_heap这类 descriptor heap / bindless 资源模型Slang 编译目标也已经启用spvDescriptorHeapEXT能力。Metal 后端开始转向 Metal 4使用 Metal 4 compiler、MTL4 command queue、residency set并为 argument buffer / bindless 风格资源访问做准备。核心层新增了TextureLayout、BarrierStages、ColorAttachment、DepthStencilAttachment、ResourceHandle等更贴近现代 RHI 的概念。Shader 统一通过 Slang 编译到 DXIL、metallib 和 SPIR-V未来可以更自然地维护一套 shader 源码。这些东西听起来比“画一个三角形”硬很多但它们决定了库的上限。Zenith.NET 如果只是做一个简单渲染封装旧 API 也能继续用但如果要承载 ray tracing、mesh shading、GPU-driven rendering、后处理链、ImGui/Skia/游戏引擎集成那底层模型就必须先足够现代。现代图形 API 的复杂度不是凭空来的。它把以前驱动和封装层偷偷替应用做的事情重新交还给应用层。代价是 API 更显式收益是使用者终于能控制资源什么时候可见、什么时候转换、什么时候同步以及 shader 到底如何拿到它需要的数据。资源绑定旧版写法旧版本的资源绑定模型比较传统C# 侧先声明ResourceBinding[]再创建ResourceTable把 texture、sampler、buffer 写入 table。渲染时把 table push 到命令缓冲shader 侧按声明顺序访问资源。旧版 C# 写法大致是这样ResourceBinding[] bindings [ new() { Type ResourceType.ConstantBuffer, Count 1 }, new() { Type ResourceType.Texture, Count 1 }, new() { Type ResourceType.Sampler, Count 1 } ]; ResourceTable table context.CreateResourceTable(new() { Bindings bindings }); table.Write(0, constantBuffer); table.Write(1, albedoTexture); table.Write(2, linearSampler); pipeline context.CreateGraphicsPipeline(new() { Vertex vertexShader, Pixel pixelShader, ResourceBindings bindings, Output frameBuffer.Output }); commandBuffer.BeginRenderPass(frameBuffer, clearValue, table); commandBuffer.SetPipeline(pipeline); commandBuffer.PushResourceTable(table); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass();对应的旧版 shader 通常是按绑定顺序声明资源ConstantBufferConstants constants; Texture2D albedo; SamplerState linearSampler; float4 PSMain(PSInput input) : SV_Target { return albedo.Sample(linearSampler, input.TexCoord) * constants.Tint; }这套模型的优点是直观尤其适合教程C# 声明绑定布局shader 按顺序使用资源。缺点也很明显资源越多table 和 layout 管理越复杂draw call 越多绑定切换越容易变成 CPU 侧负担进入 ray tracing、GPU-driven、材质数组、纹理数组这些场景后传统资源表会越来越不舒服。少量资源时这很清楚资源一多CPU 就会频繁参与“摆桌面”。传统 descriptor set、layout 和 pipeline layout 的层次本质上是在把 shader 能访问的资源分组、定型再在命令流里绑定到对应位置。资源绑定新版写法新版改成了更接近 bindless 的思路资源创建后拿到一个ResourceHandleshader 需要什么资源就把 handle 放进常量 buffer 或结构化数据里。资源绑定不再围绕“这一帧 push 哪张表”展开而是变成 shader 数据的一部分。新版 C# 写法更像这样MaterialConstants constants new() { Transform transform, BaseColor new(1.0f, 1.0f, 1.0f, 1.0f), Albedo albedoTexture.SampledHandle, Sampler linearSampler.Handle }; constantBuffer.Upload(0, new() { Pointer (nint)(constants), SizeInBytes (uint)sizeof(MaterialConstants) }); commandBuffer.Transition(color, default, TextureLayout.ColorAttachment); commandBuffer.BeginRenderPass([ColorAttachment.Clear(color, clearColor)], null); commandBuffer.SetPipeline(pipeline); commandBuffer.SetConstantBuffer(constantBuffer, 0); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass(); commandBuffer.Transition(color, default, TextureLayout.Sampled);对应的新版 shader 不再依赖固定的ResourceTable顺序而是通过 handle 访问资源。概念上可以写成这样struct MaterialConstants { float4x4 Transform; float4 BaseColor; ResourceHandle Albedo; ResourceHandle Sampler; }; ConstantBufferMaterialConstants constants; float4 PSMain(PSInput input) : SV_Target { Texture2D albedo ResourceDescriptorHeap[constants.Albedo]; SamplerState samplerState SamplerDescriptorHeap[constants.Sampler]; return albedo.Sample(samplerState, input.TexCoord) * constants.BaseColor; }实际 shader 语法会根据后端和 Slang 输出目标做适配但思路是一致的C# 侧传 handleshader 侧按 handle 找资源。DirectX 12 对应 shader-visible descriptor heap 和直接索引Vulkan 对齐 descriptor heap / descriptor indexing 思路Metal 侧则向 Metal 4 的 argument buffer / bindless 资源访问靠拢。这个变化带来的直接收益是资源绑定可以更加数据驱动。一个材质、一批实例、一个光追场景都可以把资源 handle 作为普通数据传给 GPU。后续做材质系统、纹理数组、GPU culling、indirect drawing、ray tracing 时这种模型会比反复切换 resource table 更自然。这个模型对材质系统尤其友好。以前一个材质可能意味着一套绑定表现在一个材质更像一段普通数据里面记录需要哪些纹理、哪个 sampler、哪些 buffer。当材质数量、实例数量、光源数量上来以后这个差异会非常明显。如果说旧模型强调“按 set 和 binding 把资源分批摆好”bindless 则更强调“资源先进入一个大的可索引空间shader 用数据里的索引去取”。DirectX 12 的ResourceDescriptorHeap/SamplerDescriptorHeap、Vulkan 的 descriptor indexing / descriptor heap 方向以及 Metal 的 argument buffer本质上都在把资源绑定从命令状态变成 shader 可消费的数据。屏障和布局转换显式化另一个重要变化是资源状态。旧版本里很多状态转换被封装在更高层的调用里比如BeginRenderPass(frameBuffer, clearValue, resourceTable)。这对入门很友好但当项目开始支持更多后端和更多高级功能时隐藏状态反而会带来麻烦你很难知道某张 texture 此刻到底是 render target、shader resource、storage image 还是 present image。新版把这些状态放回命令流commandBuffer.Transition(colorTexture, default, TextureLayout.ColorAttachment); commandBuffer.Transition(depthTexture, default, TextureLayout.DepthStencilAttachment); ColorAttachment colorAttachment ColorAttachment.Clear(colorTexture, clearColor); DepthStencilAttachment depthAttachment DepthStencilAttachment.Clear(depthTexture, 1.0f, 0); commandBuffer.BeginRenderPass([colorAttachment], depthAttachment); commandBuffer.SetPipeline(pipeline); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass(); commandBuffer.Transition(colorTexture, default, TextureLayout.Sampled);这看起来多写了几行但它带来的收益非常实际DirectX 12 可以映射到 Enhanced Barriers。Vulkan 可以映射到 image layout 和 pipeline barrier。Metal 可以通过 usage、hazard tracking、residency 等机制更清楚地表达资源生命周期。上层可以更容易做 render graph、pass 合并、异步 compute 和资源别名。更重要的是性能优化终于有抓手了。以前“库帮你转状态”虽然省事但很容易保守甚至发生不必要的 barrier。现在状态转换出现在命令流里后续就可以做 barrier 合并、冗余 transition 消除、跨 pass 调度等优化。这也是 barrier 在现代 RHI 里绕不开的原因。GPU 并不是“上一行代码执行完下一行代码自然安全”。渲染、计算、拷贝、采样这些阶段之间有缓存、队列、访问类型和布局差异。显式 barrier 的意义就是告诉后端前一个阶段写入了什么后一个阶段要如何读取哪些数据必须在这里变得可见。如果屏障范围过宽就可能让 GPU 在大量无关阶段之间硬等形成明显的空泡。新版把TextureLayout和阶段信息显式交给命令流就是为了后续能把这些等待收窄、合并或消掉。API 风格的变化旧 API 更像一个高层封装创建 frame buffer创建 resource tablerender pass 开始时把它们一起交给命令缓冲。commandBuffer.BeginRenderPass(frameBuffer, clearValue, resourceTable); commandBuffer.SetPipeline(pipeline); commandBuffer.PushResourceTable(resourceTable); commandBuffer.SetVertexBuffer(vertexBuffer, 0, 0); commandBuffer.SetIndexBuffer(indexBuffer, 0, IndexFormat.UInt32); commandBuffer.DrawIndexed(6, 1, 0, 0, 0); commandBuffer.EndRenderPass();新版更接近真实 GPU 命令先说明资源接下来怎么用再说明 render pass 的 attachment再设置 pipeline 和输入资源。commandBuffer.Transition(color, default, TextureLayout.ColorAttachment); commandBuffer.Transition(depth, default, TextureLayout.DepthStencilAttachment); ColorAttachment colorAttachment ColorAttachment.Clear(color, clearColor); DepthStencilAttachment depthAttachment DepthStencilAttachment.Clear(depth, 1.0f, 0); commandBuffer.BeginRenderPass([colorAttachment], depthAttachment); commandBuffer.SetPipeline(pipeline); commandBuffer.SetVertexBuffer(vertexBuffer, 0, 0); commandBuffer.SetIndexBuffer(indexBuffer, 0, IndexFormat.UInt32); commandBuffer.SetConstantBuffer(constants, 0); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass();新版并不是“更简单”的 API。它确实更底层也更要求使用者理解现代 GPU 的几个概念。但它更明确也更适合做严肃一点的图形、计算和引擎层开发。对普通用户来说后续可以通过 helper 和更高层扩展把常见路径再包起来但核心 RHI 不能再建立在太高层的假设上。新版能带来哪些性能收益从架构上看新版的性能收益主要来自几个方向。第一是更少的 CPU 绑定开销。Bindless / descriptor heap 模型会减少频繁更新 resource table、切换 descriptor set/table 的需求。资源变成 handle 后很多场景只需要更新一小段常量或实例数据。第二是更少的后端胶水。旧模型里为了统一 resource table、frame buffer、resource layout每个后端都要维护一套配套对象。新版删掉了不少这种中间层核心路径更短后端可以更直接地使用原生 API。第三是屏障优化空间更大。显式TextureLayout和BarrierStages让资源状态变得可分析后续可以做冗余 barrier 消除、pass 间 barrier 合并甚至为 render graph 做准备。第四是更适合 GPU-driven。Indirect draw、mesh shading、ray tracing、compute culling 这类工作流本质上都希望 GPU 读资源索引、读参数、自己驱动更多工作。Bindless 和显式资源状态是这些能力的基础。第五是内存模型更清楚。新版把资源用途和驻留位置拆开例如BufferUsages与MemoryResidency。这能让上传、下载、GPU-only、CPU-write 这几种路径更容易走到合适的内存策略。所以这次重构不是“眼前某个 demo 帧率立刻翻倍”的类型而是把之后真正影响性能的路径打开少绑资源、少切状态、少做无用 barrier、更多工作留给 GPU。新版不是把复杂度抹掉而是把复杂度放在更适合被分析和优化的位置。只要资源状态和同步边界足够准确图形、计算、拷贝这些工作就更有机会重叠起来而不是被保守的全局等待串成一条线。对第三方库和生态的意义Zenith.NET 不是想做一个完整游戏引擎。它更适合成为 .NET 图形生态里的一层底座所以第三方库兼容很重要。目前仓库里已经有或正在维护的方向包括ImGui用于工具界面、调试面板、编辑器 UI。ImageSharp用于图片加载、像素格式转换、纹理上传。SkiaSharp适合 2D 绘制、字体、矢量图、UI 合成等场景。Slang作为跨后端 shader 编译链统一输出 DXIL、metallib 和 SPIR-V。Avalonia、MAUI、WinForms、WinUI、WPF、Uno面向 .NET UI 框架的视图集成。新版 RHI 对这些集成的意义在于底层资源模型统一后上层库不必关心当前是 D3D12、Metal 还是 Vulkan。比如 ImGui 只需要拿到一张 texture 的绑定句柄ImageSharp 只负责把图片数据上传成 textureSkiaSharp 后续可以作为 2D 内容生产者把结果交给 Zenith.NET 合成到 3D 或 UI 管线里。如果后面 native object 暴露继续完善也可以进一步和其他生态对接例如窗口系统、视频解码、截图/录制、
Zenith.NET 开发札记：把 .NET 图形 API 推向现代 RHI
轮重构的重点是新版引入了哪些能力、为什么要做 bindless 和显式屏障、两套 API 用法有什么差别以及这些变化未来会给性能和生态带来哪些空间。新版最重要的变化Zenith.NET 正在从“跨平台图形封装库”变成“面向现代 GPU 的 .NET RHI”。新版的重点不只是创建 buffer、texture、pipeline而是开始对齐现代图形 API 中更底层也更关键的能力bindless 资源访问、显式屏障、布局转换、多队列、shader-visible descriptor heap、Metal 4、Vulkan 1.4 以及 Slang 跨后端编译。核心方向包括DirectX 12 后端要求 Shader Model 6.6、Resource Binding Tier 3 和 Enhanced Barriers。DirectX 12 使用大号 shader-visible descriptor heap让 shader 能直接索引资源。Vulkan 路线开始对齐 Vulkan 1.4 和VK_EXT_descriptor_heap这类 descriptor heap / bindless 资源模型Slang 编译目标也已经启用spvDescriptorHeapEXT能力。Metal 后端开始转向 Metal 4使用 Metal 4 compiler、MTL4 command queue、residency set并为 argument buffer / bindless 风格资源访问做准备。核心层新增了TextureLayout、BarrierStages、ColorAttachment、DepthStencilAttachment、ResourceHandle等更贴近现代 RHI 的概念。Shader 统一通过 Slang 编译到 DXIL、metallib 和 SPIR-V未来可以更自然地维护一套 shader 源码。这些东西听起来比“画一个三角形”硬很多但它们决定了库的上限。Zenith.NET 如果只是做一个简单渲染封装旧 API 也能继续用但如果要承载 ray tracing、mesh shading、GPU-driven rendering、后处理链、ImGui/Skia/游戏引擎集成那底层模型就必须先足够现代。现代图形 API 的复杂度不是凭空来的。它把以前驱动和封装层偷偷替应用做的事情重新交还给应用层。代价是 API 更显式收益是使用者终于能控制资源什么时候可见、什么时候转换、什么时候同步以及 shader 到底如何拿到它需要的数据。资源绑定旧版写法旧版本的资源绑定模型比较传统C# 侧先声明ResourceBinding[]再创建ResourceTable把 texture、sampler、buffer 写入 table。渲染时把 table push 到命令缓冲shader 侧按声明顺序访问资源。旧版 C# 写法大致是这样ResourceBinding[] bindings [ new() { Type ResourceType.ConstantBuffer, Count 1 }, new() { Type ResourceType.Texture, Count 1 }, new() { Type ResourceType.Sampler, Count 1 } ]; ResourceTable table context.CreateResourceTable(new() { Bindings bindings }); table.Write(0, constantBuffer); table.Write(1, albedoTexture); table.Write(2, linearSampler); pipeline context.CreateGraphicsPipeline(new() { Vertex vertexShader, Pixel pixelShader, ResourceBindings bindings, Output frameBuffer.Output }); commandBuffer.BeginRenderPass(frameBuffer, clearValue, table); commandBuffer.SetPipeline(pipeline); commandBuffer.PushResourceTable(table); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass();对应的旧版 shader 通常是按绑定顺序声明资源ConstantBufferConstants constants; Texture2D albedo; SamplerState linearSampler; float4 PSMain(PSInput input) : SV_Target { return albedo.Sample(linearSampler, input.TexCoord) * constants.Tint; }这套模型的优点是直观尤其适合教程C# 声明绑定布局shader 按顺序使用资源。缺点也很明显资源越多table 和 layout 管理越复杂draw call 越多绑定切换越容易变成 CPU 侧负担进入 ray tracing、GPU-driven、材质数组、纹理数组这些场景后传统资源表会越来越不舒服。少量资源时这很清楚资源一多CPU 就会频繁参与“摆桌面”。传统 descriptor set、layout 和 pipeline layout 的层次本质上是在把 shader 能访问的资源分组、定型再在命令流里绑定到对应位置。资源绑定新版写法新版改成了更接近 bindless 的思路资源创建后拿到一个ResourceHandleshader 需要什么资源就把 handle 放进常量 buffer 或结构化数据里。资源绑定不再围绕“这一帧 push 哪张表”展开而是变成 shader 数据的一部分。新版 C# 写法更像这样MaterialConstants constants new() { Transform transform, BaseColor new(1.0f, 1.0f, 1.0f, 1.0f), Albedo albedoTexture.SampledHandle, Sampler linearSampler.Handle }; constantBuffer.Upload(0, new() { Pointer (nint)(constants), SizeInBytes (uint)sizeof(MaterialConstants) }); commandBuffer.Transition(color, default, TextureLayout.ColorAttachment); commandBuffer.BeginRenderPass([ColorAttachment.Clear(color, clearColor)], null); commandBuffer.SetPipeline(pipeline); commandBuffer.SetConstantBuffer(constantBuffer, 0); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass(); commandBuffer.Transition(color, default, TextureLayout.Sampled);对应的新版 shader 不再依赖固定的ResourceTable顺序而是通过 handle 访问资源。概念上可以写成这样struct MaterialConstants { float4x4 Transform; float4 BaseColor; ResourceHandle Albedo; ResourceHandle Sampler; }; ConstantBufferMaterialConstants constants; float4 PSMain(PSInput input) : SV_Target { Texture2D albedo ResourceDescriptorHeap[constants.Albedo]; SamplerState samplerState SamplerDescriptorHeap[constants.Sampler]; return albedo.Sample(samplerState, input.TexCoord) * constants.BaseColor; }实际 shader 语法会根据后端和 Slang 输出目标做适配但思路是一致的C# 侧传 handleshader 侧按 handle 找资源。DirectX 12 对应 shader-visible descriptor heap 和直接索引Vulkan 对齐 descriptor heap / descriptor indexing 思路Metal 侧则向 Metal 4 的 argument buffer / bindless 资源访问靠拢。这个变化带来的直接收益是资源绑定可以更加数据驱动。一个材质、一批实例、一个光追场景都可以把资源 handle 作为普通数据传给 GPU。后续做材质系统、纹理数组、GPU culling、indirect drawing、ray tracing 时这种模型会比反复切换 resource table 更自然。这个模型对材质系统尤其友好。以前一个材质可能意味着一套绑定表现在一个材质更像一段普通数据里面记录需要哪些纹理、哪个 sampler、哪些 buffer。当材质数量、实例数量、光源数量上来以后这个差异会非常明显。如果说旧模型强调“按 set 和 binding 把资源分批摆好”bindless 则更强调“资源先进入一个大的可索引空间shader 用数据里的索引去取”。DirectX 12 的ResourceDescriptorHeap/SamplerDescriptorHeap、Vulkan 的 descriptor indexing / descriptor heap 方向以及 Metal 的 argument buffer本质上都在把资源绑定从命令状态变成 shader 可消费的数据。屏障和布局转换显式化另一个重要变化是资源状态。旧版本里很多状态转换被封装在更高层的调用里比如BeginRenderPass(frameBuffer, clearValue, resourceTable)。这对入门很友好但当项目开始支持更多后端和更多高级功能时隐藏状态反而会带来麻烦你很难知道某张 texture 此刻到底是 render target、shader resource、storage image 还是 present image。新版把这些状态放回命令流commandBuffer.Transition(colorTexture, default, TextureLayout.ColorAttachment); commandBuffer.Transition(depthTexture, default, TextureLayout.DepthStencilAttachment); ColorAttachment colorAttachment ColorAttachment.Clear(colorTexture, clearColor); DepthStencilAttachment depthAttachment DepthStencilAttachment.Clear(depthTexture, 1.0f, 0); commandBuffer.BeginRenderPass([colorAttachment], depthAttachment); commandBuffer.SetPipeline(pipeline); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass(); commandBuffer.Transition(colorTexture, default, TextureLayout.Sampled);这看起来多写了几行但它带来的收益非常实际DirectX 12 可以映射到 Enhanced Barriers。Vulkan 可以映射到 image layout 和 pipeline barrier。Metal 可以通过 usage、hazard tracking、residency 等机制更清楚地表达资源生命周期。上层可以更容易做 render graph、pass 合并、异步 compute 和资源别名。更重要的是性能优化终于有抓手了。以前“库帮你转状态”虽然省事但很容易保守甚至发生不必要的 barrier。现在状态转换出现在命令流里后续就可以做 barrier 合并、冗余 transition 消除、跨 pass 调度等优化。这也是 barrier 在现代 RHI 里绕不开的原因。GPU 并不是“上一行代码执行完下一行代码自然安全”。渲染、计算、拷贝、采样这些阶段之间有缓存、队列、访问类型和布局差异。显式 barrier 的意义就是告诉后端前一个阶段写入了什么后一个阶段要如何读取哪些数据必须在这里变得可见。如果屏障范围过宽就可能让 GPU 在大量无关阶段之间硬等形成明显的空泡。新版把TextureLayout和阶段信息显式交给命令流就是为了后续能把这些等待收窄、合并或消掉。API 风格的变化旧 API 更像一个高层封装创建 frame buffer创建 resource tablerender pass 开始时把它们一起交给命令缓冲。commandBuffer.BeginRenderPass(frameBuffer, clearValue, resourceTable); commandBuffer.SetPipeline(pipeline); commandBuffer.PushResourceTable(resourceTable); commandBuffer.SetVertexBuffer(vertexBuffer, 0, 0); commandBuffer.SetIndexBuffer(indexBuffer, 0, IndexFormat.UInt32); commandBuffer.DrawIndexed(6, 1, 0, 0, 0); commandBuffer.EndRenderPass();新版更接近真实 GPU 命令先说明资源接下来怎么用再说明 render pass 的 attachment再设置 pipeline 和输入资源。commandBuffer.Transition(color, default, TextureLayout.ColorAttachment); commandBuffer.Transition(depth, default, TextureLayout.DepthStencilAttachment); ColorAttachment colorAttachment ColorAttachment.Clear(color, clearColor); DepthStencilAttachment depthAttachment DepthStencilAttachment.Clear(depth, 1.0f, 0); commandBuffer.BeginRenderPass([colorAttachment], depthAttachment); commandBuffer.SetPipeline(pipeline); commandBuffer.SetVertexBuffer(vertexBuffer, 0, 0); commandBuffer.SetIndexBuffer(indexBuffer, 0, IndexFormat.UInt32); commandBuffer.SetConstantBuffer(constants, 0); commandBuffer.DrawIndexed(indexCount, 1, 0, 0, 0); commandBuffer.EndRenderPass();新版并不是“更简单”的 API。它确实更底层也更要求使用者理解现代 GPU 的几个概念。但它更明确也更适合做严肃一点的图形、计算和引擎层开发。对普通用户来说后续可以通过 helper 和更高层扩展把常见路径再包起来但核心 RHI 不能再建立在太高层的假设上。新版能带来哪些性能收益从架构上看新版的性能收益主要来自几个方向。第一是更少的 CPU 绑定开销。Bindless / descriptor heap 模型会减少频繁更新 resource table、切换 descriptor set/table 的需求。资源变成 handle 后很多场景只需要更新一小段常量或实例数据。第二是更少的后端胶水。旧模型里为了统一 resource table、frame buffer、resource layout每个后端都要维护一套配套对象。新版删掉了不少这种中间层核心路径更短后端可以更直接地使用原生 API。第三是屏障优化空间更大。显式TextureLayout和BarrierStages让资源状态变得可分析后续可以做冗余 barrier 消除、pass 间 barrier 合并甚至为 render graph 做准备。第四是更适合 GPU-driven。Indirect draw、mesh shading、ray tracing、compute culling 这类工作流本质上都希望 GPU 读资源索引、读参数、自己驱动更多工作。Bindless 和显式资源状态是这些能力的基础。第五是内存模型更清楚。新版把资源用途和驻留位置拆开例如BufferUsages与MemoryResidency。这能让上传、下载、GPU-only、CPU-write 这几种路径更容易走到合适的内存策略。所以这次重构不是“眼前某个 demo 帧率立刻翻倍”的类型而是把之后真正影响性能的路径打开少绑资源、少切状态、少做无用 barrier、更多工作留给 GPU。新版不是把复杂度抹掉而是把复杂度放在更适合被分析和优化的位置。只要资源状态和同步边界足够准确图形、计算、拷贝这些工作就更有机会重叠起来而不是被保守的全局等待串成一条线。对第三方库和生态的意义Zenith.NET 不是想做一个完整游戏引擎。它更适合成为 .NET 图形生态里的一层底座所以第三方库兼容很重要。目前仓库里已经有或正在维护的方向包括ImGui用于工具界面、调试面板、编辑器 UI。ImageSharp用于图片加载、像素格式转换、纹理上传。SkiaSharp适合 2D 绘制、字体、矢量图、UI 合成等场景。Slang作为跨后端 shader 编译链统一输出 DXIL、metallib 和 SPIR-V。Avalonia、MAUI、WinForms、WinUI、WPF、Uno面向 .NET UI 框架的视图集成。新版 RHI 对这些集成的意义在于底层资源模型统一后上层库不必关心当前是 D3D12、Metal 还是 Vulkan。比如 ImGui 只需要拿到一张 texture 的绑定句柄ImageSharp 只负责把图片数据上传成 textureSkiaSharp 后续可以作为 2D 内容生产者把结果交给 Zenith.NET 合成到 3D 或 UI 管线里。如果后面 native object 暴露继续完善也可以进一步和其他生态对接例如窗口系统、视频解码、截图/录制、
