第 19 章图形 on Go 语言原本

19.1 渲染管线与 Go 的位置

Mon, 01 Jan 0001 00:00:00 +0000

19.1 渲染管线与 Go 的位置

第 18 章把 GPU 当作一台「通用并行计算设备」来读。但 GPU 的本名是 Graphics Processing Unit, 它最初、也最本职的工作是渲染图形。早在「用 GPU 做通用计算」成为口号之前的二十年，显卡就已经在为屏幕上的每一个像素做并行运算了。所以图形是最古老的异构负载,GPU 上那套大规模并行的硬件，本就是为它而生。这一章回到这条本源，看 Go 在图形里扮演什么角色，而起点是看清那条贯穿一切的 渲染管线,以及 Go 的代码究竟坐在它的哪个位置。

19.1.1 管线：一条分段的数据流

把一堆三维顶点变成屏幕上一帧彩色图像，GPU 走的是一条分段的流水线。每一段读入上一段的输出，做一类固定的变换，再交给下一段。经典的图形管线大致是这样：

flowchart LR
 app["应用阶段<br/>(CPU / Go)"] --> vs["顶点处理<br/>(可编程 shader)"]
 vs --> pa["图元装配<br/>(固定)"]
 pa --> rs["光栅化<br/>(固定)"]
 rs --> fs["片元处理<br/>(可编程 shader)"]
 fs --> fb["帧缓冲<br/>(固定)"]

这条管线里，有些段是固定功能的（图元装配、光栅化、帧缓冲混合），由硬件写死，你只能配置参数；有些段是可编程的，顶点处理与片元处理各跑一段叫 shader(着色器）的小程序，由你提供。光栅化是这条线的心脏：它把一个三角形「填」成一片覆盖到的像素，决定了哪些片元需要被着色。整条管线天然适合 GPU,因为每个顶点、每个片元都可以被同一段 shader 独立地、并行地处理, 这正是第 18 章说的 SIMT。

19.1.2 Go 坐在哪里：CPU 侧的编排者

关键的问题来了：这条管线上，Go 的代码坐在哪一段？

答案是最左边那一段，且仅此一段:应用阶段。Go 跑在 CPU 上，它做的事是「准备数据、下达命令」: 把场景的顶点、纹理、变换矩阵组织好，上传到显存，然后发起一次次绘制调用(draw call), 告诉 GPU「用这套数据、这套 shader，画」。一旦绘制调用发出，后面那几段顶点处理、光栅化、片元处理全在 GPU 上跑，Go 不再介入，只在最后需要时把结果取回或交给窗口系统显示。

19.2 图形绑定与线程亲和

Mon, 01 Jan 0001 00:00:00 +0000

19.2 图形绑定与线程亲和

19.1 说 Go 坐在管线的应用阶段，负责发起绘制调用。可在真正发出第一条绘制调用之前，有一道坎横在所有 Go 图形程序面前，它不来自图形本身，而来自 Go 的并发模型与图形 API 的一个根本矛盾:图形上下文绑定线程，而 goroutine 会迁移线程。这道坎是本节的主角，而 18.2.5 那把钥匙 LockOSThread,在这里从一个可选的技巧变成了必需。

19.2.1 上下文：一个绑定线程的隐式状态机

OpenGL 这类图形 API 是围绕上下文(context)组织的。上下文是一个庞大的隐式状态机:当前绑定的着色器、纹理、缓冲、混合模式、视口……几乎所有 API 调用都不显式地接收上下文参数，而是隐式地作用在「当前上下文」上。glBindTexture 绑的是当前上下文里的纹理槽，glDrawElements 用的是当前上下文里的一整套状态。

关键在于「当前」二字是按线程定义的:一个 OpenGL 上下文在某个时刻「当前于」某一条特定的 OS 线程。你在线程 A 上把上下文设为当前、配置好状态、发出绘制调用，这一切都依附在线程 A 上。如果同一串 OpenGL 调用里，有一部分跑到了线程 B 上,而线程 B 上并没有这个当前上下文,那些调用要么直接失败，要么作用在一个空的上下文上，画面一片漆黑。

19.2.2 goroutine 会迁移，于是必须钉住

这正是 Go 的并发模型撞上图形 API 的地方。回忆第 9 章:goroutine 不绑定固定的线程，调度器会把它在不同的 M 之间迁移,这次在线程 A 上跑，一次抢占、一次系统调用、一次通道阻塞之后，下次很可能就被调度到线程 B 上继续。对纯 Go 代码，这种迁移是透明的、无害的，正是 M:N 调度的红利。可对 OpenGL,它是灾难:

19.3 软件渲染与并行

Mon, 01 Jan 0001 00:00:00 +0000

19.3 软件渲染与并行

前两节的渲染都要过一道边界:把数据和命令交给 GPU,付清第 18 章那一整套过桥费，还要伺候图形上下文的线程纪律（19.2）。这一节走另一条路:软件渲染,完全在 CPU 上算出每一个像素，不碰 GPU、不碰驱动、不碰任何 FFI 边界。这条路一度被认为是「慢而无用的退路」,可它恰恰是把 Go 的并发能力，以及 Go 1.27 的 simd,用在图形上的最佳舞台。

19.3.1 为什么还要软件渲染

GPU 这么快，为什么还有人在 CPU 上渲染?因为有几类场景，GPU 要么用不上，要么不划算。

没有 GPU 可用。 服务器端批量生成图片、缩略图、图表、PDF 渲染，跑在没有显卡、也没有显示器的无头（headless）机器上。这是 Go 最主流的部署形态，恰恰也是 GPU 最缺席的地方。
要确定性与可移植。 软件渲染的结果逐位可复现，不受驱动版本、显卡型号的影响。需要「同一份输入在任何机器上渲染出逐像素相同的图」时(测试基线、文档生成），软件渲染是唯一可靠的选择。
图省心、要全控。 没有上下文、没有线程纪律、没有边界，渲染器就是一段普通的 Go 代码，可读、可调试、可单步,每一个像素怎么来的都看得见。Go 标准库的 image、image/draw、 golang.org/x/image,以及社区里的纯 Go 渲染器（如 polyred),走的都是这条路。

把这几条收成一句:软件渲染是边界的另一面。第 18、19 章前面反复计算的过桥成本，在这里一笔都不存在，代价是放弃了 GPU 的海量吞吐。于是问题从「怎么过桥更便宜」变成了「不过桥，怎么把 CPU 的并行榨干」。答案有两层，正好对应第 18.4 节那个三种并行的分类里属于 CPU 的两种: goroutine 的任务并行，与 SIMD 的数据并行。

19.3.2 把屏幕切成瓦片：goroutine 级并行

软件渲染有一个先天的好性质:像素之间大多互不依赖。一帧图像上不同区域的像素，可以完全独立地算出来。这是教科书级的「易并行」(embarrassingly parallel)问题,而 Go 的 goroutine 正是为这种任务级并行生的。

19.4 浏览器中的渲染

Mon, 01 Jan 0001 00:00:00 +0000

19.4 浏览器中的渲染

前三节的渲染，要么把活儿推过 FFI 边界交给本机 GPU(19.1、19.2),要么留在 CPU 上软件渲染（19.3）。这一节把场景换到一个特别的运行环境:浏览器。Go 可以编译成 WebAssembly(WASM)在浏览器里跑，而一旦进了浏览器，渲染会遇到一道全新的边界。有意思的是，这道边界的形状、它的成本、应对它的办法，与前面整整两章讲的异构计算几乎一一对应,只是搬高了一层。看懂这一节，就会发现「FFI 边界」是个比 cgo 宽得多的母题。

19.4.1 Go 进入浏览器：WASM 与 syscall/js

Go 用 GOOS=js GOARCH=wasm 就能把程序编译成一个 .wasm 模块，加载进网页，在浏览器的 WebAssembly 虚拟机里执行。但 WASM 模块本身是个沙盒:它能做纯计算，却碰不到外面的世界, 没有 DOM，没有画布，没有 GPU,这些都属于浏览器的 JavaScript 环境。

WASM 与 JS 之间隔着一道膜，跨越它的桥是标准库的 syscall/js。Go 代码通过 js.Global() 拿到 JS 的全局对象，用 js.Value 的 Get/Set/Call 去读写 JS 属性、调用 JS 函数:

1
2
3
4
5
6


import "syscall/js"

doc := js.Global().Get("document")
canvas := doc.Call("getElementById", "screen")
ctx := canvas.Call("getContext", "2d")
// 每一次 Get / Call，都是一次从 WASM 跨进 JS 的边界穿越

请认出这道膜的真面目:它就是又一条 FFI 边界。syscall/js 之于 WASM/JS,正如 cgo 之于 Go/C。每一次 js.Value 的调用，都要把参数从 WASM 的线性内存里编组、跨过膜、进入 JS, 和 18.1 描述的跨界是同构的。于是 18.1 那条核心告诫原封不动地适用: 这道边界穿越有固定成本，要尽量少跨。

第 19 章 图形 on Go 语言原本

19.1 渲染管线与 Go 的位置

19.1 渲染管线与 Go 的位置

19.1.1 管线：一条分段的数据流

19.1.2 Go 坐在哪里：CPU 侧的编排者

19.2 图形绑定与线程亲和

19.2 图形绑定与线程亲和

19.2.1 上下文：一个绑定线程的隐式状态机

19.2.2 goroutine 会迁移，于是必须钉住

19.3 软件渲染与并行

19.3 软件渲染与并行

19.3.1 为什么还要软件渲染

19.3.2 把屏幕切成瓦片：goroutine 级并行

19.4 浏览器中的渲染

19.4 浏览器中的渲染

19.4.1 Go 进入浏览器：WASM 与 syscall/js

第 19 章图形 on Go 语言原本