一帧游戏画面里人物在草地上站着，手里武器轻轻摆动，剑身外环绕着流动的法术光环，头顶还有无数粒子往天上飞——这些看起来像「魔法」。底层却是同一条清晰的链路：

CPU 准备数据与命令 → 提交给 GPU → GPU 按批次跑完顶点着色、光栅化、片元着色、深度测试与混合 → 写进显存里的帧缓冲 → 整帧结束后再呈现到显示器。

这篇文章把这条链路讲透。人物、武器、光效、粒子会作为贯穿例子出现；最终补充 WebGPU / WebGL 一类图形 API 里 UI 与文字是怎么画出来的。配套可运行演示见 webgpu-shader-demo。浏览器以 Chrome / Edge 的 WebGPU 支持最为稳定。

先建立正确的心智模型

CPU 与 GPU 各自干什么

• CPU串行逻辑—读输入、跑游戏逻辑、算骨骼与矩阵、决定「这一帧要画哪些东西、按什么顺序画」。不做逐像素光照，
• GPU大规模并行—同一段短程序被成千上万个硬件单元同时执行，处理不同顶点或片元。话说回来，几万个顶点、几十万片元都靠并行算完。

网格

"一帧里 GPU 真正循环的单位是『批次』。不是『物体』"

CPU 可以按物体遍历更新矩阵，但提交给 GPU 时会把「同一套管线状态下的多次绘制」组织成批次。

Pain point: "为什么我觉得每个 draw 都要切换管线？" — "因为你把每个物体想成独立管线，而实际只需要一次 setPipeline 后可以连续 draw 多次只需切换 BindGroup / 顶点缓冲即可。”

至于CPU侧。从拿到设备，到把命令交出去

至于启动，拿到GPU，建好画布与长期资源

1. `navigator.gpu` 是否支持？请确保 Chrome/Edge 最新版开启实验 flag 或使用 dev channel。

2. • // 检查支持
     if throw new Error;// 获取 Adapter 与 Device
     const adapter = await navigator.gpu.requestAdapter;const device = await adapter.requestDevice;按理说，const queue = device.queue;const canvas = document.querySelector;const context = canvas.getContext;context.configure({
     device。format : navigator.gpu.getPreferredCanvasFormat,alphaMode : "opaque"
     });console.log，}

     • resource creation lives in VRAM : createBuffer/createTexture put data in显存。
       • `queue.writeBuffer` & `queue.writeTexture` 用来上传 CPU 内存中的源到显存。按理说，
       • `createRenderPipeline` 等对象位于浏览器进程。但它们“烤”好的状态在驱动内部保持。
         • `createBindGroup` 是轻量级描述符表，只引用已有资源。