Chapter 19 Graphics on Go: Under the Hood

19.1 The Rendering Pipeline and Where Go Sits

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

19.1 The Rendering Pipeline and Where Go Sits

Chapter 18 read the GPU as a “general-purpose parallel compute device.” But the GPU’s given name is the Graphics Processing Unit, and its first and most native job is to render graphics. For the two decades before “using the GPU for general computation” became a slogan, the graphics card was already doing parallel arithmetic for every pixel on the screen. Graphics is therefore the oldest heterogeneous workload: the massively parallel hardware on a GPU was built for it in the first place. This chapter returns to that origin to ask what role Go plays in graphics, and the starting point is to see clearly the rendering pipeline that runs through everything, and where exactly Go’s code sits on it.

19.2 Graphics Bindings and Thread Affinity

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

19.2 Graphics Bindings and Thread Affinity

19.1 said that Go sits at the application stage of the pipeline and is responsible for issuing draw calls. But before the first draw call can actually go out, there is a threshold in front of every Go graphics program. It does not come from graphics itself, but from a fundamental conflict between Go’s concurrency model and a property of graphics APIs: a graphics context is bound to a thread, while a goroutine migrates across threads. This threshold is the subject of this section, and the key that 18.2.5 handed us, LockOSThread, turns here from an optional trick into a necessity.

19.3 Software Rendering and Parallelism

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

19.3 Software Rendering and Parallelism

Rendering in the previous two sections always crossed a boundary: hand the work and commands to the local GPU, pay the whole set of tolls from Chapter 18, and still attend to the thread discipline of the graphics context (19.2). This section takes another road, software rendering: compute every pixel entirely on the CPU, touching no GPU, no driver, no FFI boundary of any kind. This road was once dismissed as “the slow and useless fallback,” yet it is precisely the best stage on which to put Go’s concurrency, and Go 1.27’s simd, to work in graphics.

19.4 Rendering in the Browser

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

19.4 Rendering in the Browser

Rendering in the previous three sections either pushed the work across the FFI boundary to the local GPU (19.1, 19.2) or kept it on the CPU as software rendering (19.3). This section changes the scene to a special runtime environment: the browser. Go can be compiled to WebAssembly (WASM) and run in the browser, and once inside the browser, rendering meets a brand-new boundary. What is interesting is that the shape of this boundary, its cost, and the way to deal with it correspond almost one to one with the heterogeneous computing of the previous two chapters, only lifted up one level. Understanding this section reveals that “the FFI boundary” is a motif far broader than cgo.