RequestAdapter blocks forever on macos

[thisguycodes]

The compute example doesn't work on macos, it hangs forever on instance.RequestAdapter(nil), using delve it looks like the callback never fires.

You have tests that would cover this, but it looks like CI only runs a limited subset of tests.

[kolkov]

Thanks for the report — confirmed. We've seen the same behavior with the Rust backend on macOS ARM64 in the gogpu ecosystem (gogpu/gg#171).

The issue is in how we handle the async callback from wgpu-native — likely CallbackModeAllowProcessEvents + ProcessEvents() doesn't work on macOS Metal. Working on a fix.

[kolkov]

We've done a deep investigation. Here's what we found and a diagnostic request.

Analysis

wgpu-native calls the adapter callback synchronously inside wgpuInstanceRequestAdapter() — the CallbackMode field is ignored entirely. On Windows this works because syscall.LazyProc.Call handles re-entrant callbacks natively. On macOS, our FFI layer uses a different call path (runtime.cgocall → assembly), and the synchronous callback may not fire correctly.

Two possible causes:

1. Metal main thread requirement — MTLCopyAllDevices() blocks because it's not on the main thread
2. FFI re-entrant callback — the C function returns but the callback doesn't fire (Go→C→Go re-entrancy issue)

Diagnostic

We've pushed a debug branch with prints before/after the C call and inside the callback handler. Could you test it?

# In your project, use the debug branch:
go get github.com/go-webgpu/webgpu@debug/macos-hang
go mod tidy

# Run your code (or the compute example):
DYLD_LIBRARY_PATH=/path/to/wgpu-native go run .

Expected output patterns:

Case A — C function blocks (Metal thread issue):

[wgpu-debug] calling wgpuInstanceRequestAdapter...
(hangs here — never prints "returned")

Case B — Callback doesn't fire (FFI re-entrancy issue):

[wgpu-debug] calling wgpuInstanceRequestAdapter...
[wgpu-debug] wgpuInstanceRequestAdapter returned
[wgpu-debug] callback did NOT fire synchronously, entering ProcessEvents loop
(spins forever)

Case C — Working (what we see on Windows):

[wgpu-debug] calling wgpuInstanceRequestAdapter...
[wgpu-debug] adapterCallbackHandler FIRED: status=0 adapter=0x... userdata1=1
[wgpu-debug] wgpuInstanceRequestAdapter returned
[wgpu-debug] callback fired synchronously (before loop)

Also: are you on Apple Silicon (arm64) or Intel (amd64)?

[ivokub]

I tested on MacOS 26.4 with both wgpu-native@master (compiled from source) and v29.0.1. I have the case B:

Init... OK
CreateInstance... OK
[wgpu-debug] calling wgpuInstanceRequestAdapter...
[wgpu-debug] adapterCallbackHandler FIRED: status=1 adapter=0x600003218470 userdata1=0
[wgpu-debug] wgpuInstanceRequestAdapter returned
[wgpu-debug] callback did NOT fire synchronously, entering ProcessEvents loop

[kolkov]

v0.5.0 may have fixed this — verification needed

This issue was reported before the v0.5.0 complete API rewrite (released 2026-05-26). The FFI layer was completely redesigned:

• wgpu-native v27 → v29 (stable webgpu-headers)
• New Go-idiomatic API with proper callback handling
• RequestAdapter now uses a different callback mechanism

Big news: go-webgpu/webgpu is now fully unified with gogpu/wgpu — the Pure Go WebGPU implementation. With the upcoming release, gogpu/wgpu becomes a single package with three backends selected by build tags:

• (default) Pure Go → Vulkan/Metal/DX12/GLES/Software
• -tags rust → go-webgpu/webgpu → wgpu-native v29
• js,wasm → Browser WebGPU

Same API, same types, same user code — build tag selects the implementation. We've verified the Rust backend works on Windows with v0.5.0 + wgpu-native v29 (triangle example renders correctly).

Could someone with macOS verify if this still reproduces on v0.5.0?

go get github.com/go-webgpu/webgpu@v0.5.0
# Run any example that calls instance.RequestAdapter()

@thisguycodes @ivokub — if you can test, that would be very helpful. Release is coming soon and macOS is the remaining platform to confirm.

[Raggaer]

package main

import (
	"fmt"
	"log"

	"github.com/go-webgpu/webgpu/wgpu"
)

func main() {
	// Initialize library
	if err := wgpu.Init(); err != nil {
		log.Fatal(err)
	}

	fmt.Println("WGPU started")

	// Create WebGPU instance
	instance, err := wgpu.CreateInstance(nil)
	if err != nil {
		log.Fatal(err)
	}
	defer instance.Release()

	fmt.Println("WGPU started")

	// Request GPU adapter
	adapter, err := instance.RequestAdapter(nil)
	if err != nil {
		log.Fatal(err)
	}
	defer adapter.Release()

	fmt.Printf("Adapter: %#x\n", adapter.Handle())
}

Still hangs for me on macOS 15.7.3.

module client

go 1.26.3

require github.com/go-webgpu/webgpu v0.5.0

require (
	github.com/go-webgpu/goffi v0.5.2 // indirect
	github.com/gogpu/gputypes v0.5.0 // indirect
)

[kolkov]

@lkmavi — could you test this on your macOS? You already have the gogpu ecosystem set up.

Quick repro with go-webgpu/webgpu v0.5.0:

package main

import (
	"fmt"
	"log"

	"github.com/go-webgpu/webgpu/wgpu"
)

func main() {
	if err := wgpu.Init(); err != nil {
		log.Fatal(err)
	}
	instance, err := wgpu.CreateInstance(nil)
	if err != nil {
		log.Fatal(err)
	}
	defer instance.Release()

	fmt.Println("Calling RequestAdapter...")
	adapter, err := instance.RequestAdapter(nil)
	if err != nil {
		log.Fatal(err)
	}
	defer adapter.Release()
	fmt.Printf("Adapter: %s\n", adapter.Info().Name)
}

Expected: prints adapter name. Reported: hangs on RequestAdapter.

Previous diagnostic showed the callback fires but isn't detected as synchronous (userdata1=0). Likely a goffi re-entrant callback issue on macOS ARM64.

Important: This only affects the Rust FFI backend (-tags rust). The default Pure Go Metal backend works fine on macOS — all gogpu/ui/gg examples render correctly.

We need to confirm whether v0.5.0 (complete API rewrite) fixed this or if it still reproduces. If it still hangs, we'll dig into the goffi callback layer.