GitHub项目说明 · 非用户反馈
以 64 位 GPU 指针和应用自有描述符堆重构图形 API，让大量常规对象消失
NoGraphicsAPI 是对 No Graphics API 设想的实验性实现：用 GPU 地址直接作为命令参数，应用自持描述符堆，以全局 hazard 屏障取代资源状态转换，从而去掉缓冲区对象、描述符集、管线布局等常用对象。原型已跑通三个示例，Metal 支持仍缺失，可作为观察无绑定渲染 API 可行性的信号。
查看原始信号github:sebbbi/NoGraphicsAPI
目标用户
使用 Vulkan 等底层图形 API 的渲染/图形开发者（游戏引擎、实时渲染工具链）以及关注图形 API 演进方向的研究者
潜在需求
需要更少样板对象、更贴近数据流的渲染 API：命令直接消费 GpuRange 地址，着色器以 64 位指针和描述符堆索引取资源，根数据以单个 push payload 传递，从而减少绑定与状态管理开销。
发生场景
传统图形 API 中，开发者需创建并管理缓冲区对象、描述符集/布局、管线布局、资源状态转换等大量间接对象；本项目展示了一条以 GPU 指针与地址命令、应用自有描述符堆、hazard 同步替代它们的路径，但仍是原型，且 Metal 端未实现。
来源证据
NoGraphicsAPI 是实验性 Vulkan 1.4 实现，探索在着色器使用 64 位 GPU 指针、纹理与采样器描述符位于应用自有 GPU 内存、同步只描述 hazard 时，常规图形 API 有多少会消失。
# NoGraphicsAPI `NoGraphicsAPI` is an experimental Vulkan 1.4 implementation of the ideas in Sebastian Aaltonen's [*No Graphics API*](https://www.sebastianaaltonen.com/blog/no-graphics-api). It explores how much of a conventional graphics API disappears when shaders use 64-bit GPU pointers, texture and sampler descriptors live in application-owned GPU memory, and synchronization describes hazards instead of resource state. The Vulkan backend is implemented and exercised by three examplehttps://github.com/sebbbi/NoGraphicsAPI
为什么值得留意
该原型把 No Graphics API 的博客和 SIGGRAPH 设想落到 Vulkan 1.4 新扩展上，是可供实际构建和实验的实现参考；对低层渲染开发者而言，它展示了一条显著缩小 API 面的技术路径，Metal 设计缺失与构建门槛也留下可继续观察的补齐空间。
未满足部分
- Metal 支持未实现，只有设计文档记录的映射与未解决问题
- 示例要求 Slang 2026.14.1+，随 Vulkan SDK 附带的旧版 Slang 会直接构建失败
- 版本检查对两位数字版本号（如 2026.17）解析失败，导致新版 Slang 也被拒绝
可能延伸 · 模型推测
- 按同一设计实现 Metal 4 后端并记录实际差异
- 将 Slang 版本检查改为兼容多位版本号或随项目打包所需编译器
- 把原型包装成示例驱动型渲染库，便于快速验证无绑定工作流
- 补充与传统 Vulkan 代码在样板量、内存开销、性能上的对比数据
目前未知
- 这是作者个人原型，仅三个示例应用，未见第三方采用证据
- 所需扩展较新，对 Vulkan 1.4 硬件和驱动支持范围较窄
- 构建问题属于工具链兼容性，不必然反映 API 设计需求
继续核实
- 有多少团队在实际 Vulkan 项目中为缓冲区对象、描述符集和管线布局样板所困，并愿意尝试无绑定模型？
- Vulkan 1.4 的 descriptor heap 与设备地址命令在主流硬件上的稳定性和性能是否足以支撑生产级实现？
- No Graphics API 思路在 Apple/Metal 生态是否有真实采用需求，还是主要停留在概念阶段？
主题词
gpu resource bindingdescriptor heapsgraphics api boilerplategpu pointers