现代图形API综合比较：Vulkan | DirectX | Metal | WebGPU
Vulkan、DirectX、Metal 和 WebGPU 等低级图形 API 正在融合为类似于当前 GPU 构建方式的模型。 图形处理单元 (GPU) 是异步计算单元，可以处理大量数据，例如复杂的网格几何形状、图像纹理、输出帧缓冲区、变换矩阵或你想要计算的任何数据。
NSDT工具推荐： Three.js AI纹理开发包 - YOLO合成数据生成器 - GLTF/GLB在线编辑 - 3D模型格式在线转换 - 可编程3D场景编辑器 - REVIT导出3D模型插件 - 3D模型语义搜索引擎 - Three.js虚拟轴心开发包 - 3D模型在线减面 - STL模型在线切割
GPU 并不总是这样，最初它们是一组基于固定硬件的功能，几乎没有可编程性。 随着应用程序突破了这些不可编程系统的功能极限，这种情况发生了变化，这保证了 GPU 制造商和应用程序开发人员之间的竞争不断突破其设计的极限 [Peddie 2023]。 帧缓冲区和光栅器 [Fatahalian 2018] 带来了可编程着色器、通用 GPU (GPGPU) 计算，以及最近添加的用于人工智能光线遍历加速和张量处理的硬件。 图形 API 伴随着这些变化而不断发展，增加了固定图形管道、计算着色器以及最近的光线遍历功能（DirectX 12 和 Vulkan 光线追踪）。
让我们看一下图形 API 之间的一些相似点和不同点。 我们将介绍以下 C++ API：
- 🌋 Vulcan
- ❎DirectX 12.x
- ✖️DirectX 11.x
- 🤖 Metal
- 🕸️WebGPU
- ⚪ OpenGL
OpenGL的设计起源于计算机图形学的早期，被设计为状态机，因此它的接口与现代图形API有很大不同。 DirectX 11 虽然比 OpenGL 更接近现代 GPU 架构，但试图通过将 Vulkan、DirectX 12 和 Metal 目前让开发人员负责的任务委托给驱动程序来简化开发人员的工作。 [罗素 2014]
了解现代图形 API 的遗产是很有用的，因此它们会在相关的地方被提及。
1、执行顺序
无论 API 如何，图形应用程序通常都遵循以下执行顺序：
- 初始化 API - 创建访问 API 内部工作所需的核心数据结构。
- 加载资源 - 创建加载着色器等内容所需的数据结构、描述图形管道、创建和填充命令缓冲区以供 GPU 执行，以及将资源发送到 GPU 独占内存。
- 更新资源 - 将任何uniforms更新到着色器并在此处执行应用程序级逻辑。
- 呈现 - 将命令缓冲区列表发送到命令队列并呈现结果。
- 重复 2、3 和 4，直到应用程序发出关闭信号。
- 销毁 - 等待 GPU 完成所有剩余工作，并销毁所有数据结构和句柄。
因此，我们将按此顺序跟踪 Graphics API 数据结构的创建和使用。
2、导入依赖项
依赖关系示例
| API | Structure |
|---|---|
| Vulkan | #include |
| DirectX 12 | #include |
| DirectX 11 | #include |
| Metal | #import |
| WebGPU | Requires Canary Browser with Flags |
| OpenGL | Varies by OS |
启动新应用程序时，你需要包含对外部 API 的所有依赖项，图形 API 也不例外。 根据 API，你的项目中可能还需要其他库，例如着色器编译器。
OpenGL 是所有其他图形 API 的例外，因为根据操作系统和你的个人设置，可以从不同位置进行多种导入。
3、着色器编译器
| API | Structure |
|---|---|
| Vulkan | #include "glslang/Include/revision.h" |
| DirectX 12 | #include |
| DirectX 11 | #include |
| Metal | #import |
| WebGPU | N/A |
| OpenGL | void glShaderSource(...) |
Vulkan 要求你使用生成 SPIR-V 的外部着色器编译器，例如 glslang 或 DirectX Shader Compiler。
对于 DirectX，建议你使用 DirectX 着色器编译器而不是附带的编译器，因为它支持更新的着色器模型版本以及更多优化和速度。
金属着色器可以在运行时编译，也可以在构建时使用 MacOS 路径中包含的 metallib 命令行工具进行编译。
OpenGL 不需要外部库来编译着色器，因为它包含在库中，但它也支持 SPIR-V 作为 OpenGL 4.6 中 GLSL 的可选替代方案。
WebGPU 着色器是纯文本字符串，因此无需编译它们，尽管在生产中去除空格和缩小/损坏符号是个好主意。
4、初始化API
- 入口API
| API | Structure |
|---|---|
| Vulkan | vk::Instance |
| DirectX 12 | IDXGIFactory4 |
| DirectX 11 | IDXGIFactory |
| Metal | CAMetalLayer |
| WebGPU | GPU |
| OpenGL | Varies by OS |
图形 API 的入口点通常允许你访问 API 的内部类。
Vulkan 的入口点涉及选择你打算使用的 API 版本以及您想要的任何扩展或层，例如错误检查、窗口表面等。
DirectX 11 和 12 要求您创建一个工厂，以及一个可选的调试数据结构。
在 Metal 上，NSWindow 需要有一个带有 CAMetalLayer 的 NSView（它是 QuartzCore 的一部分）。 一旦层存在并附加到窗口，该窗口就可以使用 Metal API 的其余部分。
对于 OpenGL，最接近入口点的是操作系统特定的上下文，你可以在创建操作系统窗口后请求该上下文。
- 物理设备
| API | Structure |
|---|---|
| Vulkan | vk::PhysicalDevice |
| DirectX 12 | IDXGIAdapter1 |
| DirectX 11 | IDXGIAdapter |
| Metal | MTLDevice |
| WebGPU | GPUAdapter |
| OpenGL | glGetString(GL_VENDOR) |
物理设备允许你查询重要的设备特定详细信息，例如内存大小和功能支持。
金属是这里唯一的异常值，因为物理和逻辑设备都由相同的数据结构共享。
OpenGL 无法查询任何设备详细信息，除非使用制造商专有的扩展。 你可以获得一些杂项数据，例如驱动程序供应商名称、渲染器和 OpenGL 版本。
- 逻辑设备
| API | Structure |
|---|---|
| Vulkan | vk::Device |
| DirectX 12 | ID3D12Device |
| DirectX 11 | ID3D11Device |
| Metal | MTLDevice |
| WebGPU | GPUDevice |
| OpenGL | N/A |
设备使你可以访问 API 的核心内部功能，例如创建纹理、缓冲区、队列、管道等图形数据结构。这种类型的数据结构在所有现代图形 API 中大部分都是相同的，并且具有非常丰富的功能。 他们之间几乎没有什么变化。
Vulkan 和 DirectX 12 通过设备创建内存数据结构来提供对内存的控制。
- 队列
| API | Structure |
|---|---|
| Vulkan | vk::Queue |
| DirectX 12 | ID3D12CommandQueue |
| DirectX 11 | ID3D11DeviceContext |
| Metal | MTLCommandQueue |
| WebGPU | GPUQueue |
| OpenGL | N/A |
队列允许你将任务排入队列以供 GPU 执行。 GPU 是一种异步计算设备，因此这里的想法是始终保持忙碌状态，同时控制何时将项目添加到队列中。
Vulkan 队列要求你在创建设备之前指定设备将使用哪些队列。
- 命令池
| API | Structure |
|---|---|
| Vulkan | vk::CommandPool |
| DirectX 12 | ID3D12CommandAllocator |
| DirectX 11 | ID3D11DeviceContext |
| Metal | MTLCommandQueue |
| WebGPU | GPUDevice |
| OpenGL | N/A |
命令池是一种允许你创建命令缓冲区的数据结构。
Metal 的突出之处在于队列也是分配命令缓冲区的数据结构。
5、帧后台API
- 窗口表面
| API | Structure |
|---|---|
| Vulkan | vk::Surface |
| DirectX 12 | ID3D12Resource |
| DirectX 11 | ID3D11Texture2D |
| Metal | CAMetalLayer |
| WebGPU | GPUCanvasContext |
| OpenGL | Varies by OS |
窗口表面API允许你将所有绘制调用绑定到操作系统特定的窗口。
在 DirectX 上，由于只有 Windows / Xbox 作为 API 的目标，因此最接近表面的是从交换链接收的纹理后台缓冲区。 交换链接收您的窗口句柄，并从那里创建 DirectX 驱动程序内部的表面。
由于 MacOS 和 iOS 窗口具有分层结构，其中应用程序包含视图，视图可以包含层，因此 Metal 中最接近表面的东西要么是金属层，要么是包裹它的视图。
- 交换链
| API | Structure |
|---|---|
| Vulkan | vk::Swapchain |
| DirectX 12 | IDXGISwapChain3 |
| DirectX 11 | IDXGISwapChain |
| Metal | CAMetalDrawable |
| WebGPU | GPUCanvasContext |
| OpenGL | Varies by OS |
交换链在给定窗口的不同后台缓冲区之间翻转，并控制渲染的各个方面，例如刷新率和后台缓冲区交换行为。
Metal 和 OpenGL 在这里脱颖而出，因为 API 缺乏交换链的概念，而是将其留给操作系统窗口 API。
- 帧缓冲区
| API | Structure |
|---|---|
| Vulkan | vk::Framebuffer |
| DirectX 12 | ID3D12Resource |
| DirectX 11 | ID3D11RenderTargetView |
| Metal | MTLRenderPassDescriptor |
| WebGPU | GPURenderPassDescriptor |
| OpenGL | GLuint |
帧缓冲区是在基于光栅的图形管道执行期间用作输出的输出纹理组。
DirectX 12 和 11 没有为此提供显式数据结构，而是你可以传递一组视图。
6、初始化资源
- 纹理
| API | Structure |
|---|---|
| Vulkan | vk::Image & vk::ImageView |
| DirectX 12 | ID3D12Resource |
| DirectX 11 | ID3D11Texture2D |
| Metal | MTLTexture |
| WebGPU | GPUTexture & GPUTextureView |
| OpenGL | GLuint |
纹理是存储颜色信息的数据数组，并用作渲染的输入/输出。 Vulkan、DirectX 12 和 WebGPU 引入了对给定纹理拥有多个视图的想法，这些视图可以以不同的编码格式或颜色空间查看该纹理。 Vulkan 引入了图像和缓冲区的托管内存的概念，因此纹理是图像、使用时的图像视图（可以有多个）以及仅设备中或 CPU-GPU 可访问空间中的内存的三元组。
对于 Vulkan 中管理内存的更传统方式，我强烈推荐 AMD Vulkan 内存分配器。 对于 DirectX 12，同一作者发布了 AMD D3D12 内存分配器。
- 缓冲区
| API | Structure |
|---|---|
| Vulkan | vk::Buffer & vk::BufferView |
| DirectX 12 | ID3D12Resource |
| DirectX 11 | ID3D11Buffer |
| Metal | MTLBuffer |
| WebGPU | GPUBuffer & GPUBufferView |
| OpenGL | GLuint |
缓冲区是一个数据数组，例如网格的位置数据、颜色数据、索引数据等。类似的图像规则也适用于 Vulkan 和 WebGPU 中的缓冲区。
- 着色器
| API | Structure |
|---|---|
| Vulkan | vk::ShaderModule |
| DirectX 12 | ID3DBlob |
| DirectX 11 | ID3D11VertexShader or ID3D11PixelShader |
| Metal | MTLLibrary |
| WebGPU | GPUShaderModule |
| OpenGL | GLuint |
着色器往往是已编译的着色器（HLSL、GLSL、MSL 等）代码块的句柄，该代码将馈送到给定的管道。
- 着色器绑定
| API | Structure |
|---|---|
| Vulkan | vk::PipelineLayout & vk::DescriptorSet |
| DirectX 12 | ID3D12RootSignature |
| DirectX 11 | ID3D11DeviceContext::VSSetConstantBuffers(...) |
| Metal | [MTLRenderCommandEncoder setVertexBuffer: uniformBuffer] |
| WebGPU | GPUPipelineLayout |
| OpenGL | GLint |
大多数现代图形 API 都具有绑定数据结构，以帮助将统一的缓冲区和纹理连接到需要该数据的图形管道。 Metal 的独特之处在于，您可以在命令编码器中使用 setVertexBuffer 绑定制服，与 Vulkan、DirectX 12 和 WebGPU 相比，它的架构变得更加容易。
- 流水线
| API | Structure |
|---|---|
| Vulkan | vk::Pipeline |
| DirectX 12 | ID3D12PipelineState |
| DirectX 11 | Various State Calls |
| Metal | MTLRenderPipelineState |
| WebGPU | GPURenderPipeline |
| OpenGL | Various State Calls |
管道是对执行光栅绘制调用、计算调度或光线跟踪调度时将执行的内容的总体描述。
DirectX 11 和 OpenGL 在这里是独一无二的，它们没有用于图形管道的专用对象，而是使用调用在执行绘制调用之间设置管道状态。
- 命令缓冲区
| API | Structure |
|---|---|
| Vulkan | vk::CommandBuffer |
| DirectX 12 | ID3D12GraphicsCommandList |
| DirectX 11 | ID3D11DeviceContext |
| Metal | MTLRenderCommandEncoder |
| WebGPU | GPUCommandEncoder |
| OpenGL | Intenal to Driver or with GL_NV_command_list |
命令缓冲区是一个异步计算单元，你可以在其中描述 GPU 执行的过程，例如绘制调用、将数据从 CPU-GPU 可访问内存复制到 GPU 独占内存，以及动态设置图形管道的各个方面，例如当前剪刀。
以前，你会声明希望 GPU 按程序执行什么，并且 GPU 会执行这些任务，但 GPU 本质上是异步的，因此驱动程序将负责确定何时将任务调度到 GPU。
- 命令列表
| API | Structure |
|---|---|
| Vulkan | vk::SubmitInfo |
| DirectX 12 | ID3D12CommandList[] |
| DirectX 11 | ID3D11CommandList |
| Metal | MTLCommandBuffer |
| WebGPU | GPUCommandEncoder[] |
| OpenGL | Intenal to Driver or with GL_NV_command_list |
命令列表是批量推送到 GPU 的命令缓冲区组。 这样做的原因是为了保持 GPU 持续忙碌，从而减少 CPU 和 GPU 之间的不同步 [Foley 2015]。
- 围栏
| API | Structure |
|---|---|
| Vulkan | vk::Fence |
| DirectX 12 | ID3D12Fence |
| DirectX 11 | ID3D11Fence |
| Metal | MTLFence |
| WebGPU | N/A |
| OpenGL | glFenceSync |
Fence 是用于同步 CPU 和 GPU 的对象。 CPU 和 GPU 都可以被指示在栅栏处等待，以便对方能够赶上。 这可用于管理资源分配和释放，从而更轻松地管理总体图形内存使用情况。 [萨特兰等人。 2018]
- 栅栏
| API | Structure |
|---|---|
| Vulkan | vkCmdPipelineBarrier |
| DirectX 12 | D3D12_RESOURCE_BARRIER |
| DirectX 11 | N/A |
| Metal | MTLFence |
| WebGPU | N/A |
| OpenGL | glMemoryBarrier |
命令缓冲区内更细粒度的同步形式。 Hans-Kristian Arntzen 写了一篇关于 Vulkan 同步的文章，值得一看。
- 信号量
| API | Structure |
|---|---|
| Vulkan | vk::Semaphore |
| DirectX 12 | HANDLE |
| DirectX 11 | HANDLE |
| Metal | dispatch_semaphore_t |
| WebGPU | N/A |
| OpenGL | Varies by OS |
信号量是用于引入操作之间的依赖关系的对象，例如在将命令缓冲区提交到设备队列之前获取交换链中的下一个图像之前等待。
Vulkan 的独特之处在于信号量是 API 的一部分，而 DirectX 和 Metal 将其委托给操作系统调用。
7、空间、对齐
每个图形 API 可以有不同的轴方向、NDC 坐标方向、矩阵对齐、纹理对齐等默认值，在大多数情况下，这不是什么大问题，只需在你的片段着色器中翻转 UV 中的 y 值即可。
- 纹理对齐
| API | Structure |
|---|---|
| Vulkan | Bottom Left |
| DirectX 12 | Top Left |
| DirectX 11 | Top Left |
| Metal | Top Left |
| WebGPU | Bottom Left |
| OpenGL | Bottom Left |
DirectX 使用左上角作为像素空间坐标，大多数闭源 API 也是如此，而开源则选择使用左下角。
8、结束语
虽然这些 API 中的每一个都有细微的差别，但它们在设计上非常接近。 由库架构师决定他们所需的 API 限制在哪里，无论是像 Metal/WebGPU 一样简洁，还是像 Vulkan 一样复杂。
原文链接：现代图形API综合比较 - BimAnt