理解 WebGPU 中的 navigator.gpu 和 adapter：从浏览器到显卡的旅程

WebGPU 是一种现代图形 API，旨在为 Web 应用程序提供高性能的图形和计算功能。作为 WebGL 的继任者，WebGPU 提供了更底层的硬件访问和更高效的性能。在 WebGPU 开发中，navigator.gpu 是访问 WebGPU API 的入口点，而 adapter 则是浏览器与底层图形 API 之间的抽象层。本文将深入探讨 navigator.gpu 和 adapter 的作用，并解释它们如何与显卡硬件交互。

navigator.gpu 的作用

navigator.gpu 是浏览器提供的全局对象，用于访问 WebGPU 的功能。通过它，开发者可以获取 GPU 设备、创建渲染管线、管理缓冲区等。navigator.gpu 是 WebGPU 开发的起点，开发者通过它请求 GPU 适配器（Adapter），进而请求 GPU 设备（Device），最终进行图形渲染或计算任务。

adapter 的角色

navigator.gpu.requestAdapter() 返回的 adapter 表示浏览器选择的物理 GPU 适配器（例如集成显卡或独立显卡）。它并不是直接操作显卡的接口，而是浏览器对底层图形 API（如 Vulkan/Metal/D3D12）的抽象封装。通过 adapter，开发者可以进一步获取 device（设备对象），这才是实际创建资源、提交命令的核心对象。

命令的实际流程

当通过 WebGPU 发送命令时，流程大致如下：

开发者代码：使用 device 创建命令缓冲区（Command Buffer），编码渲染或计算命令。
浏览器实现层：将 WebGPU 命令转换为底层图形 API（如 Vulkan/Metal/D3D12）的调用。
操作系统/驱动层：底层图形 API 通过显卡驱动与物理 GPU 通信。
硬件执行：最终由 GPU 硬件执行命令。

开发者代码 → WebGPU API → 浏览器实现 → 底层图形 API → 显卡驱动 → 物理 GPU

为什么需要抽象层？

跨平台兼容性：WebGPU 需要适配不同操作系统（Windows/macOS/Linux）和显卡（NVIDIA/AMD/Intel）。
安全性：浏览器必须隔离网页代码对硬件的直接访问，防止恶意操作。
资源管理：浏览器负责处理内存分配、错误恢复等底层细节。

关键对象的分工

adapter：代表物理 GPU 的抽象，提供 GPU 的基本信息（如支持的特性）。
device：通过 adapter.requestDevice() 创建，是实际与 GPU 交互的核心对象。所有资源（缓冲区、纹理）和命令队列（Command Queue）均由 device 管理。
Command Buffer：开发者通过 device 创建命令缓冲区，将渲染或计算操作编码到其中，再提交到队列执行。关于使用Command Buffer的方式提交命令的原因可以参考如下链接：WebGPU：为什么通过命令缓冲区与硬件交互？

示例代码与流程

以下是一个简单的 WebGPU 初始化示例：

const adapter = await navigator.gpu.requestAdapter();
const device = await adapter.requestDevice();//请求一个默认设备。如果方法内添加参数{powerPreference:'high-performance'}就是‘尽可能’请求一个更好的设备（比如独立显卡）。

// 创建命令编码器
const commandEncoder = device.createCommandEncoder();

// 编码渲染命令（例如清屏）
const renderPass = commandEncoder.beginRenderPass({ /* ... */ });
renderPass.end();

// 提交命令到 GPU 队列
const commandBuffer = commandEncoder.finish();
device.queue.submit([commandBuffer]);

这里的 device.queue.submit() 会将命令缓冲区提交到 GPU 队列，但实际执行仍需经过浏览器和底层 API 的转换。