3、驱动适配层设计：抽象接口定义、平台差异封装与回调机制

驱动适配层，说白了就是一道「防火墙」。

它的任务很简单：让上层的渲染引擎不知道自己在跑在 Windows 上还是 Linux 上。你想想看，如果每一处渲染代码都写满了 #ifdef _WIN32，那这个项目基本就废了——维护成本会指数级上升。我在早期的一个跨平台项目中就吃过这个亏，代码里到处都是平台宏，改一个 D3D 的 Present 调用，得小心翼翼地把 Vulkan 那边的逻辑也同步改一遍。嗯，后来我彻底重构了适配层，才把局面稳住。

3.1 抽象接口定义：SwapBuffer 与 Present

适配层的核心，是两个接口：SwapBuffer 和 Present。很多人觉得它们是一回事，其实不然。

• SwapBuffer：负责后台缓冲区的翻转逻辑。它管理的是「哪张图该被显示」这个状态机。
• Present：负责把翻转后的图像提交给显示硬件。它管的是「什么时候显示、怎么同步」。

我习惯把它们定义成纯虚类，像这样：

class ISwapChain {
public:
    virtual ~ISwapChain() = default;

    // 翻转后台缓冲区，返回下一张可渲染的索引
    virtual uint32_t SwapBuffer() = 0;

    // 提交当前帧到显示设备
    virtual void Present(bool vsync) = 0;

    // 重置交换链（窗口大小变化时调用）
    virtual void Resize(uint32_t width, uint32_t height) = 0;
};

注意 SwapBuffer 返回一个索引值。这个设计细节是我在调优时加上的——因为 Vulkan 里你拿到下一张图像后，还得手动设置信号量等待，而 D3D12 的 Present 内部已经帮你做了。返回索引可以让上层统一处理「下一帧该渲染到哪个 RT」的逻辑。

3.2 平台差异封装：Windows D3D vs Linux Vulkan

真正的挑战在这里。Windows 上我们用 D3D11/12，Linux 上我们用 Vulkan。两者的交换链模型差异很大。

我直接列一个对比表，你看完就明白了：

维度	Windows D3D11/12	Linux Vulkan
交换链创建	IDXGISwapChain::Create，传入 HWND	vkCreateSwapchainKHR，传入 surface
后台缓冲区获取	GetBuffer(idx) 直接拿到纹理	vkAcquireNextImageKHR，需要信号量同步
翻转操作	Present(1, 0) 内部翻转	队列提交 + vkQueuePresentKHR 显式控制
垂直同步	SyncInterval 参数控制	通过 VkPresentModeKHR 控制（FIFO/MAILBOX）
窗口 Resize	ResizeBuffers 自动处理	必须销毁重建 Swapchain

你看，D3D 把很多细节藏起来了，而 Vulkan 要求你事必躬亲。我在封装时，针对 Vulkan 版本额外做了一层「信号量管理器」——因为 vkAcquireNextImageKHR 返回的索引可能和上一帧的信号量状态冲突，我曾经在这里踩过一个死锁坑，排查了整整两天。

封装的具体做法，我建议用工厂模式：

std::unique_ptr<ISwapChain> CreateSwapChain(
    const PlatformContext& ctx,
    uint32_t width, uint32_t height) {
#if defined(_WIN32)
    return std::make_unique<D3DSwapChain>(ctx, width, height);
#elif defined(__linux__)
    return std::make_unique<VulkanSwapChain>(ctx, width, height);
#else
    #error "Unsupported platform"
#endif
}

这样上层代码只需要调用 CreateSwapChain，拿到 ISwapChain 指针，然后调用 SwapBuffer 和 Present。平台差异被完全隔离在工厂内部。

3.3 回调机制：让适配层主动通知上层

适配层不能只是被动调用。有些事件需要主动通知上层，比如：

• 窗口大小变化，交换链需要重建
• 垂直同步模式被系统覆盖（比如全屏优化）
• 后台缓冲区数量不足，需要扩展

我设计了一套轻量级的回调机制，用 std::function 注册：

class ISwapChainCallback {
public:
    virtual ~ISwapChainCallback() = default;
    virtual void OnSwapChainResize(uint32_t newWidth, uint32_t newHeight) = 0;
    virtual void OnPresentModeChanged(VkPresentModeKHR newMode) = 0;
    virtual void OnOutOfMemory() = 0;
};

class SwapChainBase : public ISwapChain {
public:
    void RegisterCallback(ISwapChainCallback* cb) { m_callback = cb; }

protected:
    void NotifyResize(uint32_t w, uint32_t h) {
        if (m_callback) m_callback->OnSwapChainResize(w, h);
    }

private:
    ISwapChainCallback* m_callback = nullptr;
};

为什么不用虚函数重载？因为回调是「可选」的。有些上层实现不关心垂直同步变化，那就不注册。用回调的方式，适配层不需要知道上层具体是谁，解耦更彻底。

3.4 整体架构图

下面这张图展示了适配层的完整结构。你可以看到，上层渲染引擎只与 ISwapChain 接口交互，平台差异被完全封装在 D3D 和 Vulkan 的实现中。回调机制则像一根「信号线」，把底层事件传递上来。

3.5 封装时的几个关键决策

最后，我分享几个在项目中反复验证过的决策点：

1. 缓冲区数量统一为 3：D3D 默认 2 缓冲区，Vulkan 可以设 3。我统一用 3，因为三重缓冲在应对帧率波动时更平滑。代价是多占一份显存，但现代 GPU 不差这点。
2. 垂直同步默认开启：但提供 SetVSync(bool) 接口让上层覆盖。我在一个电竞项目里，玩家要求关闭垂直同步换取更低延迟，这个接口就派上了用场。
3. 错误处理统一返回 std::expected：C++23 的特性，但我在 C++17 里用 tl::expected 模拟。这样适配层不会抛出异常，上层可以优雅地处理交换链创建失败。