Hacker News 中文摘要

文章摘要

文章探讨了低层图形API对行业的深远影响，作者Sebastian Aaltonen基于30年图形开发经验，分析了从传统API到现代技术的演变。他结合AMD、Nvidia等硬件文档和开源驱动验证技术细节，指出当前图形编程的瓶颈，并分享在Unity、Unreal等引擎优化中的实践洞见。

文章总结

无图形API：面向现代GPU的极简设计

作者背景

Sebastian Aaltonen是一位拥有30年图形编程经验的资深开发者，曾参与多款游戏主机（如Nintendo Switch、PlayStation、Xbox）和PC图形API（如DirectX、Vulkan）的开发。他目前致力于为HypeHype构建基于WebGPU、Metal和Vulkan的渲染器，并曾参与Unity DOTS图形团队的领导工作。

现代图形API的演变

十年前，低层级图形API（如DirectX 12、Vulkan和Metal）的推出标志着实时计算机图形领域的重大变革。这些API旨在减少驱动开销，但初期在实际游戏引擎中并未显著提升性能，反而因与现有引擎设计不兼容而增加了复杂性。

当前API的局限性

现有的“现代API”已问世十年，其设计初衷是为了支持13年前的GPU架构。这些API需要处理大量持久化对象（如PSO），导致存储和加载时间激增。随着GPU架构的演进（如统一的缓存层次结构和64位指针支持），许多早期的设计妥协已不再必要。

现代GPU架构的进步

现代GPU普遍采用以下特性： - 统一的最后一级缓存（LLC） - CPU通过PCIe ReBAR或UMA直接写入GPU内存 - 支持64位指针和无绑定纹理采样 - 原生支持8位、16位和64位数据类型

这些进步使得我们可以设计更简洁的API，无需复杂的持久化对象管理。

极简API设计提案

内存管理
采用类似CUDA的gpuMalloc和gpuFree接口，结合CPU映射的GPU内存（UMA/ReBAR），实现高效的内存分配和数据传输。支持三种内存类型：
- CPU映射的GPU内存（默认）
- 仅GPU内存（用于纹理和大缓冲区）
- CPU缓存内存（用于回读）
数据绑定
使用64位指针替代传统的缓冲区绑定，简化数据传递。示例： cpp uint32* numbers = gpuMalloc(1024 * sizeof(uint32)); for (int i = 0; i < 1024; i++) numbers[i] = random();
纹理绑定
通过全局可索引的纹理描述符堆实现无绑定纹理采样，支持CPU和GPU直接写入描述符。示例： cpp GpuTextureDescriptor* textureHeap = gpuMalloc<GpuTextureDescriptor>(65536); textureHeap[0] = gpuTextureViewDescriptor(texture, {.format = FORMAT_RGBA8_UNORM});
管线状态
减少PSO的持久化状态，将深度-模板和混合状态分离为独立对象，降低管线排列组合爆炸问题。支持动态混合状态和帧缓冲读取（针对移动GPU）。
同步机制
简化屏障设计，用阶段和危险标志替代资源列表。示例： cpp gpuBarrier(commandBuffer, STAGE_COMPUTE, STAGE_COMPUTE, HAZARD_DESCRIPTORS);
间接绘制
支持间接根数据和绘制参数，提升GPU驱动渲染的灵活性。示例： cpp gpuDrawIndexedInstancedIndirectMulti(commandBuffer, dataVertex.gpu, sizeof(DataVertex), dataPixel.gpu, sizeof(DataPixel), args.gpu, drawCount.gpu);

工具与兼容性

调试支持：通过64位指针和调试符号实现类似C/C++的内存调试。
翻译层：现有API（如DirectX 12、Vulkan、Metal）可通过翻译层运行在新API上。
硬件支持：现代GPU（如Nvidia Turing、AMD RDNA2、Apple M1等）均已支持所需特性。

结论

通过整合现代API的最佳特性（如Metal的指针语义、Vulkan的描述符缓冲和DirectX 12的纹理堆），可以设计出更简洁、高效的图形API。这种设计不仅减少复杂性，还能充分发挥现代GPU的潜力。未来的API应摒弃传统兼容性包袱，全面拥抱无绑定架构。

（全文约1500字，保留核心观点和技术细节，删减了部分硬件历史背景和示例代码。）

评论总结

这篇评论主要围绕新型图形API的讨论展开，以下是关键观点总结：

对现有API的批评

Vulkan和DX12存在冗余设计且缺乏更新（评论1："Vulkan carries a lot of baggage"；评论8："Graphics APIs have significantly increased in complexity"）
低层API暴露过多硬件细节可能是个错误（评论10："bad idea to go all in to a low level API"）

性能优化期待

新API可能带来显著性能提升（评论1："SDL3 gpu would get a 3x/4x boost"；评论5询问性能改进程度）

行业趋势讨论

软件渲染重新兴起（评论9："go back to software rendering"）
CUDA可能更适合未来发展（评论10："Maybe CUDA... is the right way"；评论9提到OctaneRender转向CUDA）

文章内容评价

技术细节丰富但部分概念未解释（评论3："never defines the term PSOs"；评论10："so many details"）
缺少动机说明（评论8补充了文章动机段落）

怀旧与比较

对Mantle等旧API的怀念（评论6："I miss Mantle... most fun I've had"）
与SDL3 GPU API相似（评论2："similar to the SDL3 GPU API"）

厂商角色质疑

微软停止更新DirectX的原因探讨（评论4："why M$ stopped putting out new Direct X"）
建议Valve开发新API（评论7："Valve might put out their own API"）

无图形API -- No Graphics API