第二章：图形API与硬件接口
各位同学，今天我们来聊聊图形API和硬件之间那层「看不见的墙」。说白了，就是Vulkan、DirectX、Metal这些API，到底是怎么跟GPU硬件打交道的。
我刚开始做GPU驱动时，总觉得API就是个软件层，跟硬件关系不大。后来踩了不少坑才明白——API的设计，直接决定了硬件怎么干活。
2.1 硬件抽象层：API的「翻译官」
每个图形API都有自己的硬件抽象层（HAL）。它的任务很简单：把API的调用翻译成硬件能懂的指令。
举个例子，Vulkan里你创建一个VkPipeline，HAL会把它拆成几十条硬件寄存器配置。DirectX 12的ID3D12PipelineState也一样，只是名字不同。
核心要点：
- Vulkan的HAL最薄，几乎直接暴露硬件特性
- DirectX 12的HAL稍微厚一点，但比D3D11薄多了
- Metal的HAL介于两者之间，苹果自家优化做得好
我在项目中遇到过一个问题：某个Vulkan驱动在移动GPU上跑得慢，查了半天发现是HAL层把VK_IMAGE_LAYOUT_GENERAL映射到了错误的硬件状态。嗯，这种坑，你光看API文档是看不出来的。
2.2 Command Buffer：GPU的「待办清单」
Command Buffer，说白了就是一张「待办清单」。CPU把要干的活写上去，GPU照着清单执行。
为什么需要这个东西？你想想看，CPU和GPU是异步工作的。CPU不能每次发个Draw Call就等着GPU干完。所以，Command Buffer就是用来解耦的。
Vulkan里，你得手动管理Command Buffer的分配和提交：
// Vulkan示例：创建并记录Command Buffer
VkCommandBuffer cmdBuffer;
vkAllocateCommandBuffers(device, &allocInfo, &cmdBuffer);
vkBeginCommandBuffer(cmdBuffer, &beginInfo);
vkCmdBindPipeline(cmdBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, pipeline);
vkCmdDraw(cmdBuffer, vertexCount, 1, 0, 0);
vkEndCommandBuffer(cmdBuffer);
// 提交给GPU
VkSubmitInfo submitInfo = {};
submitInfo.commandBufferCount = 1;
submitInfo.pCommandBuffers = &cmdBuffer;
vkQueueSubmit(queue, 1, &submitInfo, fence);
DirectX 12的写法类似，只是API风格不同：
// DirectX 12示例
ID3D12GraphicsCommandList* commandList;
commandList->Reset(commandAllocator, pipelineState);
commandList->DrawInstanced(vertexCount, 1, 0, 0);
commandList->Close();
// 提交
ID3D12CommandList* ppCommandLists[] = { commandList };
commandQueue->ExecuteCommandLists(1, ppCommandLists);
个人经验：Command Buffer的分配策略很重要。我建议用「池化」的方式，提前分配一批，循环使用。别每帧都创建销毁，那样性能会很难看。
2.3 硬件调度：谁先谁后？
Command Buffer提交到GPU后，硬件调度器就开始干活了。它的任务是把这些命令分配到不同的硬件单元上。
GPU内部通常有多个引擎：
| 引擎类型 | 负责内容 | 并行度 |
|---|---|---|
| 3D引擎 | 顶点处理、光栅化、像素着色 | 高 |
| 计算引擎 | 通用计算、后处理 | 中 |
| 拷贝引擎 | 纹理上传、Buffer拷贝 | 低 |
| 视频引擎 | 编解码 | 低 |
调度器会看Command Buffer里的命令类型，然后分发给对应的引擎。比如vkCmdDraw走3D引擎，vkCmdCopyBuffer走拷贝引擎。
我曾经调试过一个性能问题：某个游戏在Vulkan下帧率不稳定。后来发现是调度器把计算任务和渲染任务混在一起了，导致3D引擎经常空等。解决办法是把计算和渲染的Command Buffer分开提交，用不同的Queue。
注意：不同GPU的调度策略差别很大。NVIDIA喜欢用「贪心调度」，哪个引擎闲了就塞任务。AMD更看重「公平调度」，尽量让所有引擎负载均衡。写跨平台代码时，千万别假设调度行为。
2.4 Draw Call的硬件解析
一个Draw Call，从API到硬件，到底经历了什么？我拆开来说：
- API层：你调用
vkCmdDraw或DrawInstanced，把顶点数、实例数等信息写入Command Buffer - 驱动层：驱动把这些信息打包成硬件能识别的「Draw Packet」
- 硬件调度器：从Command Buffer里取出Draw Packet，解析出顶点缓冲地址、索引缓冲地址、着色器句柄等
- 顶点处理单元：根据Draw Packet里的信息，从显存里读取顶点数据，执行顶点着色器
- 光栅化单元：把三角形变成像素片段
- 像素处理单元：执行像素着色器，写回Frame Buffer
你看，一个简单的Draw Call，背后是这么一串流水线。每个环节都可能成为瓶颈。
我记得有一次，某个游戏在移动GPU上Draw Call数量只有几百，但帧率就是上不去。查了半天，发现是每个Draw Call都绑定了不同的顶点缓冲，导致顶点处理单元频繁切换状态。解决办法是合并顶点缓冲，减少状态切换。
关键指标：
- Draw Call数量：不是越少越好，但太多肯定不行
- 每个Draw Call的顶点数：太少浪费，太多可能超限
- 状态切换频率：这是隐藏的性能杀手
2.5 三种API的硬件接口对比
最后，我整理了一个对比表，方便你理解：
| 特性 | Vulkan | DirectX 12 | Metal |
|---|---|---|---|
| HAL厚度 | 最薄 | 较薄 | 适中 |
| Command Buffer管理 | 完全手动 | 手动 | 半自动 |
| 硬件调度暴露 | Queue + Semaphore | Command Queue + Fence | Command Queue + Events |
| Draw Call开销 | 极低 | 低 | 低 |
| 跨平台性 | 好 | 仅Windows/Xbox | 仅Apple生态 |
选哪个API？我个人建议：做跨平台用Vulkan，做Windows独占用DX12，做苹果生态用Metal。别想着一个API通吃，那只会让你两头不讨好。
好了，这一章就到这里。下一章我们聊聊着色器硬件——那个让GPU真正「算起来」的核心单元。