gogpu/gg v0.48.14 - GPU Runtime Dependency Update

gogpu/gg v0.48.14 was published on June 24, 2026, as a maintenance release for Go projects that keep GPU work inside a data or web processing path. The important operator signal is dependency movement: wgpu moves to v0.30.2, example code tracks gogpu v0.42.5, and indirect FFI plumbing moves to goffi v0.5.5. It is not marked as a prerelease.

The full release notes and downloads are on the GitHub release page.

The main runtime change in v0.48.14 is the wgpu bump from v0.30.1 to v0.30.2. The release notes do not describe a new API surface, a migration step, or a behavior change tied to that bump. Treat it as dependency maintenance unless your workload already sits close to GPU device setup, memory movement, or shader execution.

For data engineers, that still matters. A Go step that wraps GPU work can be quiet in normal test runs and noisy only under real input size. The narrow check is to rebuild the service or tool, run the jobs that exercise wgpu, and compare stderr, device selection, and memory pressure against the previous v0.48.13 build.

This is also the part to watch if gg is used inside a batch path that processes images, tensors, render output, or other binary payloads before loading them into storage. The release notes do not claim a speed change. The useful question is simpler: does the same workload produce the same output and resource profile after the dependency move.

The examples move from gogpu v0.42.1 to gogpu v0.42.5. That is not the same as a library feature for all consumers, but example drift is still worth noticing in a project like this. Examples are often the first integration test a platform team runs when checking whether a GPU stack works on a new host image.

For operators, the change reduces one source of version skew between the release artifact and the sample code around it. If your internal smoke tests copy from upstream examples, refresh them from this tag rather than mixing code from v0.48.14 with older dependency versions. That keeps failures easier to attribute when the host driver, container image, and Go module graph are all moving at once.

The release also updates goffi from v0.5.3 to v0.5.5 as an indirect dependency. The notes do not attach a user facing fix to that line. Its relevance is mostly in the boundary between Go and foreign calls. If your deployment has strict build rules, static analysis gates, or reproducible module snapshots, this indirect movement is the item to pin and review.

The only non dependency item is a fix to the organization profile README example code. The release notes cite the documentation change plainly and do not list source changes to the public contract. That makes this release easy to classify: small maintenance, not a new integration surface.

That said, README example fixes are still useful when they remove stale copy from the path between evaluation and a first local run. A broken example can waste the same time as a broken API when it is used in onboarding docs, internal templates, or quick checks for a new runner image. If your team keeps a local cookbook for gogpu/gg, compare it with the updated example before carrying forward old snippets.

There is no listed breaking change, schema change, CLI flag, or migration note in the release text. The safer rollout path is ordinary dependency validation: update the module graph, rebuild, run GPU covered tests, and keep the previous build available until at least one real workload has completed.