Skip to content

refactor(webgpu): build the software backend through the public wgpu API - #157

Merged
kolkov merged 2 commits into
mainfrom
refactor/webgpu-public-software-backend
Nov 6, 2026
Merged

kolkov merged 2 commits into
mainfrom
refactor/webgpu-public-software-backend

Conversation

@kolkov

@kolkov kolkov commented Nov 6, 2026

Copy link
Copy Markdown
Contributor

Summary

The WebGPU software backend (GOGPU_GRAPHICS_API=software, the automatic fallback when no GPU is usable, and the path the GPU tests take in CI) built its device by hand from github.com/gogpu/wgpu/hal/software through hal.InstanceDescriptor and wgpu.NewDeviceFromHAL. Two problems came out of that:

  • hal/ and core/ are wgpu's implementation, and they are moving under internal/, so this code would stop compiling on a future wgpu update.
  • Against current wgpu, the hand-built device no longer passed the compute availability probe. Under GOGPU_GRAPHICS_API=software, every GPU test skipped without a sound.

The software adapter now comes through the public API, the way Rust wgpu does it:

instance, _ := wgpu.CreateInstance(nil) // every registered backend, software included
adapter, _ := instance.RequestAdapter(&wgpu.RequestAdapterOptions{ForceFallbackAdapter: true})
device, _ := adapter.RequestDevice(nil)

Changes

  • internal/backend/webgpu/backend.go: newSoftwareBackend now uses CreateInstance, ForceFallbackAdapter and RequestDevice. The wgpu/hal and wgpu/hal/software imports are gone. Only the blank hal/allbackends import that registers the backends is left. The adapter info comes from the adapter instead of a hard-coded struct.
  • The deprecated wgpu.Backends* aliases are replaced with gputypes.Backends*.
  • New software_backend_test.go checks two things:
    • GOGPU_GRAPHICS_API=software yields a CPU adapter;
    • no non-test file in the backend imports wgpu/hal/... or wgpu/core/.... This check fails on the old code.
  • With the software tests running again, TestLazyModeAdd's 100 ms bound no longer holds there: the SPIR-V interpreter runs the dispatch inside Add. The bound is skipped on CPU adapters.
  • .gitignore: ignore a local project-management directory.
  • CHANGELOG entry under Unreleased.

Test plan

  • go build ./..., go vet
  • GOGPU_GRAPHICS_API=software go test ./internal/backend/webgpu/ -count=1
  • Same with vulkan and dx12 on a real GPU
  • golangci-lint run
  • CI green

@codecov

codecov Bot commented Nov 6, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 31.81818% with 15 lines in your changes missing coverage. Please review.

Files with missing lines Patch % Lines
internal/backend/webgpu/backend.go 31.81% 14 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

.pm/ holds the private project state (STATUS, HANDOFF, kanban) under the
workspace layout standard. It must never be published, like .claude/ and
docs/dev/.
newSoftwareBackend built its device from wgpu/hal/software via
hal.InstanceDescriptor and wgpu.NewDeviceFromHAL. gogpu/wgpu is moving
core/ and hal/ under internal/, and against current wgpu the hand-built
device no longer passed the compute availability probe, so every GPU test
skipped silently under GOGPU_GRAPHICS_API=software.

The software adapter now comes from CreateInstance(nil) plus
RequestAdapterOptions.ForceFallbackAdapter, as in Rust wgpu, and its
AdapterInfo from the adapter itself. Only the blank hal/allbackends import
remains; a test fails on any other wgpu/hal or wgpu/core import (ADR-005).
The deprecated wgpu.Backends* aliases become gputypes.Backends*.

With the software tests running again, TestLazyModeAdd's 100ms bound no
longer holds there: the SPIR-V interpreter executes the dispatch inside
Add (7.96s Add, 10ms Realize). The bound is skipped on CPU adapters.
@kolkov
kolkov force-pushed the refactor/webgpu-public-software-backend branch from db9e15c to 89d298b Compare November 6, 2026 07:50
@kolkov
kolkov merged commit 2f7fd5d into main Nov 6, 2026
11 checks passed
@kolkov
kolkov deleted the refactor/webgpu-public-software-backend branch November 6, 2026 08:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant