Migrate WebGPU backend to gogpu/wgpu (core)

[kolkov]

Summary

Migrate Born's WebGPU backend from go-webgpu/webgpu (Rust FFI via wgpu-native shared library) to gogpu/wgpu (pure Go). Full replacement, not dual backend.

Context

• Parent: Backend Strategy: GoGPU Integration Research #20
• Decision: ADR-005 — use Core API, not HAL-direct (available on request; feel free to ask about specific points in comments)
• Research: GOGPU_WGPU_ARCHITECTURE_2026-04-10 (internal)
• gogpu/wgpu v0.24.6 stable, pure Go
• Eliminates runtime dependency on wgpu_native shared library (.dll/.so/.dylib)
• True single binary deployment
• gogpu/naga supports DXIL (Rust naga does NOT)
• WGSL shaders stay unchanged
• Milestone: v0.8.0

Technical Approach

Use gogpu/wgpu Core API (root wgpu package):

• Provides encoder pooling, staging belt, deferred destruction
• Dispatch overhead negligible for ML (nanoseconds vs microsecond GPU kernels)
• We maintain both libraries — can optimize Core API for ML workloads as needed

Do NOT use HAL-direct (except potentially for tensor arena allocator in the future).

Scope

Files to modify

• internal/backend/webgpu/backend.go — device init, lifecycle
• internal/backend/webgpu/compute.go — compute dispatch, encoder/pass
• internal/backend/webgpu/gpu_ops.go — GPU tensor operations
• internal/backend/webgpu/gpu_tensor.go — buffer management
• internal/backend/webgpu/buffer_pool.go — buffer pooling
• internal/backend/webgpu/lazy_compute.go — lazy mode
• internal/backend/webgpu/gpu_creation.go — tensor creation
• internal/backend/webgpu/ops.go, ops_extended.go — minor import updates
• go.mod — swap dependency

Key changes

• Replace go-webgpu/webgpu imports → gogpu/wgpu
• Adapt device initialization to Core API flow (Instance → Adapter → Device)
• Leverage Core API's staging belt for buffer uploads
• Leverage Core API's encoder pooling (saves 64KB DX12 allocator per frame)
• Use Core API's DestroyQueue for safe resource lifecycle
• Update shader module creation API
• WGSL shaders (shaders.go) — NO changes needed

Acceptance Criteria

• go build ./... passes with gogpu/wgpu
• All WebGPU unit tests pass
• Compute shaders dispatch correctly
• Buffer upload/download works
• Lazy mode works
• Buffer pool works
• Flash attention works
• No go-webgpu imports remain
• Single binary — no runtime .dll/.so dependency

[kolkov]

Hey @gmohmad @bennibbelink @jsully1720 — we'd love your input on a major change planned for v0.8.0.

What's changing

We're fully replacing the current WebGPU backend (go-webgpu/webgpu, which loads wgpu_native shared library via FFI) with gogpu/wgpu — a pure Go WebGPU implementation.

Why:

• Eliminates runtime dependency on wgpu_native shared library (.dll/.so/.dylib)
• True single binary deployment — nothing to ship alongside
• gogpu/wgpu v0.24.6 is stable, pure Go, performance on par with Rust
• gogpu/naga supports DXIL (Rust naga does not)
• Simpler build & deploy — no need to match wgpu_native version to platform

What stays the same:

• All WGSL shaders unchanged
• Backend interface unchanged
• CPU backend unaffected
• ONNX/GGUF import unaffected
• Your existing and future ONNX PRs are not impacted

Scope: ~15 hours across 3 issues (#40 core migration, #41 test suite, #42 cleanup). This is part of the v0.8.0 milestone.

Technical approach

We'll use gogpu/wgpu's Core API (not HAL-direct). The Core API provides critical infrastructure — encoder pooling, staging belt, deferred GPU resource destruction — that would be wasteful to reimplement. The dispatch overhead is negligible for ML (nanoseconds vs microsecond GPU kernels). We maintain both libraries, so we can optimize the Core API for ML workloads as needed.

Details: ADR-005

Questions for you

1. Any WIP branches? If you have in-progress work, we'll coordinate timing so nothing conflicts.
2. Concerns? About pure Go GPU, gogpu/wgpu maturity, or the approach?
3. Anything else you'd like to see in v0.8.0? We're also planning quantization support and missing tensor ops (Clamp, Abs, Pow, Slice).

No pressure to respond — just keeping the community in the loop. Your contributions in v0.7.16 were outstanding!

[gmohmad]

hey! thanks for the heads up

1. WIP branches: no active work from my side that would conflict.
2. Concerns: none , gogpu/wgpu looks promising, dropping the shared library dependency is a great improvement.
3. v0.8.0 wishlist: id love to see some cpu backend optimizations since currently it uses naive nested loops in some places. but the planned scope for 0.8.0 is already substantial, so maybe this can wait for a later release. also, more op support would be cool.

the link to the ADR is not working btw, says 404

[bennibbelink]

Hey, sorry just saw this!

1. This PR is my only WIP branch feature(tensor): implement sign and abs ops #59
2. No concerns about the approach. I'm new to GPU computing in Go, so will still be getting up to speed
3. No specific requests, but I'm happy to help implement some of the missing tensor ops (or optimize existing ops)