Runner: GPU backend detection fails on Windows (falls back to CPU)

jerry commented

2026-11-01 00:05:28 +00:00

Contributor

Problem

On Windows the runner can't detect any GPU backend, so it forces CPU rendering for every job, even on a machine with a working HIP GPU. That blocks the Windows render trial on ai1 (Linux ai1 has MES hangs; plain Blender 5.2.3 HIP on Windows rendered frames 520-560 clean, 41/41).

Repro

Host: ai1, Windows 11 25H2 (build 26200), AMD Radeon 8060S (Ryzen AI MAX+ 395), AMD driver 32.0.32015.12012.
Binary: PR #34 head b562f88, cross-compiled CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build ./cmd/jiggablend.
Run: jiggablend.exe runner --manager http://<manager>:8080 --sandbox none --hip-gpu-sample-batch 0, with Blender 5.2.3 (C:\blender-5.2.3) on PATH, manager lock-system-blender on.
Runner log (2026-10-31 19:03 CT):

[WARN] No capabilities detected
[INFO] Registered runner with ID: 3
[INFO] Detecting GPU backends (AMD/NVIDIA/Intel) from host hardware for Blender < 4.x policy...
runner.go:234: GPU backend detection failed (host probe unavailable). All jobs will use CPU because backend availability is unknown.

Runner was stopped before taking any task; no job rendered.

Cause

internal/runner/blender/detect.go only probes Linux: DRM card nodes under /sys and lspci. On Windows both are missing, DetectGPUBackends() returns ok=false, and DetectAndStoreGPUBackends() (runner.go ~234) sets gpuDetectionFailed = true, which forces CPU for all jobs.

Proposed fix (either)

Add a Windows probe (build tag windows): query Win32_VideoController (WMI / CIM, or Get-CimInstance Win32_VideoController output) and map Name/AdapterCompatibility to AMD/NVIDIA/Intel.
When the host probe is unavailable, don't force CPU; defer to Blender's own Cycles device enumeration (the enable_gpu script already lists HIP/CUDA/OptiX devices) and only fall back to CPU if Blender finds no GPU device.

Also: zstd on Windows

The runner refuses to start without zstd ("zstd not found - required for compressed blend file support. Install with: apt install zstd"). On Windows I had to put the official zstd v1.5.7 win64 zstd.exe on PATH. Either document that (README / Windows install notes, with a Windows-appropriate error message) or bundle/vendor zstd support.

Acceptance

On Windows with an AMD GPU, runner startup logs a GPU-capable backend (AMD/HIP) and no "detection failed ... use CPU" line.
A render task on that runner logs "Render devices (GPU only, 1 enabled) - ... [HIP]" and "Final Cycles device: GPU".
Linux detection behavior unchanged (existing tests pass).
Windows zstd requirement documented or handled, with an error message that isn't apt-specific.

## Problem On Windows the runner can't detect any GPU backend, so it forces **CPU rendering for every job**, even on a machine with a working HIP GPU. That blocks the Windows render trial on ai1 (Linux ai1 has MES hangs; plain Blender 5.2.3 HIP on Windows rendered frames 520-560 clean, 41/41). ## Repro - Host: ai1, Windows 11 25H2 (build 26200), AMD Radeon 8060S (Ryzen AI MAX+ 395), AMD driver 32.0.32015.12012. - Binary: PR #34 head b562f88, cross-compiled `CGO_ENABLED=0 GOOS=windows GOARCH=amd64 go build ./cmd/jiggablend`. - Run: `jiggablend.exe runner --manager http://<manager>:8080 --sandbox none --hip-gpu-sample-batch 0`, with Blender 5.2.3 (C:\blender-5.2.3) on PATH, manager lock-system-blender on. - Runner log (2026-10-31 19:03 CT): ``` [WARN] No capabilities detected [INFO] Registered runner with ID: 3 [INFO] Detecting GPU backends (AMD/NVIDIA/Intel) from host hardware for Blender < 4.x policy... runner.go:234: GPU backend detection failed (host probe unavailable). All jobs will use CPU because backend availability is unknown. ``` - Runner was stopped before taking any task; no job rendered. ## Cause `internal/runner/blender/detect.go` only probes Linux: DRM card nodes under `/sys` and `lspci`. On Windows both are missing, `DetectGPUBackends()` returns ok=false, and `DetectAndStoreGPUBackends()` (runner.go ~234) sets `gpuDetectionFailed = true`, which forces CPU for all jobs. ## Proposed fix (either) 1. Add a Windows probe (build tag `windows`): query `Win32_VideoController` (WMI / CIM, or `Get-CimInstance Win32_VideoController` output) and map Name/AdapterCompatibility to AMD/NVIDIA/Intel. 2. When the host probe is unavailable, don't force CPU; defer to Blender's own Cycles device enumeration (the enable_gpu script already lists HIP/CUDA/OptiX devices) and only fall back to CPU if Blender finds no GPU device. ## Also: zstd on Windows The runner refuses to start without `zstd` ("zstd not found - required for compressed blend file support. Install with: apt install zstd"). On Windows I had to put the official zstd v1.5.7 win64 `zstd.exe` on PATH. Either document that (README / Windows install notes, with a Windows-appropriate error message) or bundle/vendor zstd support. ## Acceptance - On Windows with an AMD GPU, runner startup logs a GPU-capable backend (AMD/HIP) and no "detection failed ... use CPU" line. - A render task on that runner logs "Render devices (GPU only, 1 enabled) - ... [HIP]" and "Final Cycles device: GPU". - Linux detection behavior unchanged (existing tests pass). - Windows zstd requirement documented or handled, with an error message that isn't apt-specific.

ash was assigned by eva

2026-11-01 00:05:45 +00:00

eva commented

2026-11-01 00:05:45 +00:00

Owner

Routing this to Ash since it needs code: a Windows GPU probe (or deferring to Blender's own device list when the host probe can't run) plus a Windows-friendly zstd message or docs. Jerry's acceptance list is the bar, and Linux detection has to stay as it is. Mira sets the order against Ash's current queue.

s1d3sw1ped commented

2026-11-01 00:09:03 +00:00

Owner

Ideally if supported we would get all necessary hardware info from blender then fallback to the more specific methods by system as needed.

mira commented

2026-11-01 00:11:26 +00:00

Collaborator

Ruling: ACCEPT. Top priority. Per Justin (10/31 7:10 PM CT, via Jerry), this goes ahead of #36 and everything else in Ash's queue.

Purpose: runners use the GPU they have. Right now a Windows runner forces CPU, which blocks the ai1 Windows 520-560 render test.

Acceptance criteria

On Windows the runner detects an NVIDIA or AMD GPU, either through Win32_VideoController or by deferring to Blender's own device list, and doesn't force CPU.
Linux detection is unchanged: the existing /sys and lspci path behaves the same, with tests.
A unit test covers the Windows detection parsing.
The runner logs the detected device at startup.
On merge, the merger posts the PR and commit on this issue so Jerry can cross-compile and run the ai1 Windows 520-560 test.

The normal review and merge flow applies, including the no-context comment pass.

**Ruling: ACCEPT. Top priority.** Per Justin (10/31 7:10 PM CT, via Jerry), this goes ahead of #36 and everything else in Ash's queue. **Purpose:** runners use the GPU they have. Right now a Windows runner forces CPU, which blocks the ai1 Windows 520-560 render test. **Acceptance criteria** 1. On Windows the runner detects an NVIDIA or AMD GPU, either through Win32_VideoController or by deferring to Blender's own device list, and doesn't force CPU. 2. Linux detection is unchanged: the existing /sys and lspci path behaves the same, with tests. 3. A unit test covers the Windows detection parsing. 4. The runner logs the detected device at startup. 5. On merge, the merger posts the PR and commit on this issue so Jerry can cross-compile and run the ai1 Windows 520-560 test. The normal review and merge flow applies, including the no-context comment pass.

ash referenced this issue from a commit

2026-11-01 00:13:47 +00:00

runner: detect GPUs on Windows via Win32_VideoController (#39)

ash referenced this issue from a commit

2026-11-01 00:14:51 +00:00

runner: pin existing lspci matching in tests, drop unrelated whitespace edits (#39)

ash referenced this issue from a pull request that will close it,

2026-11-01 00:15:07 +00:00

runner: detect GPUs on Windows via Win32_VideoController (#39) #40

ash referenced this issue from a commit

2026-11-01 00:33:58 +00:00

runner: run Win32 parser tests on all platforms (#39)

linus closed this issue

2026-11-01 00:36:42 +00:00

linus referenced this issue from a commit

2026-11-01 00:36:43 +00:00

Merge pull request 'runner: detect GPUs on Windows via Win32_VideoController (#39)' (#40) from ash/windows-gpu-detect-39 into develop

jerry commented

2026-11-01 00:42:18 +00:00

Author

Contributor

Deployed be76c82 (#40, includes #34) on ai1 Windows 11, 7:37 PM CT 10/31. Cross-compiled CGO_ENABLED=0 GOOS=windows GOARCH=amd64 on the jumpbox, exe sha256 c66f968f…522f1d. zstd.exe is still supplied on PATH by hand.

Runner startup:

GPU devices detected via win32_videocontroller: AMD Radeon(TM) 8060S Graphics
GPU backend detection: AMD=true NVIDIA=false INTEL=false

No "detection failed" line. Job 6 (frames 520-560) task 5354 runs GPU-only on HIP with Blender 5.2.3 and logs "Final Cycles device: GPU". Acceptance met on ai1.

Side note, not part of this fix: on Windows, make-relative reports "Total files 928 | Changed 43 | Failed 567". The same scene on Linux reports "Changed 610 | Failed 0". The paths are absolute E:\… library paths, and Blender won't make a path relative across drive letters (the workspace is on C:).

Task 5354 device lines:

Found devices by type: ['CPU', 'HIP']
    Disabled CPU: AMD RYZEN AI MAX+ 395
  Enabled HIPRT (HIP Ray Tracing) for faster rendering
Render devices (GPU only, 1 enabled):
  - AMD Radeon(TM) 8060S Graphics [HIP]
Final Cycles device: GPU
Blender 5.2.3 LTS (hash e13b728c6880 built 2026-10-22 01:37:16)
00:46.953  render           | Fra: 520 | Mem: 165M | Updating Geometry BVH SU Split Slip Dress G9_22031.001 5/111 | Building HIPRT acceleration structure
00:46.953  render           | Fra: 520 | Mem: 165M | Updating Geometry BVH Genesis8Female 3/111 | Building HIPRT acceleration structure
00:46.968  render           | Fra: 520 | Mem: 167M | Updating Geometry BVH Genesis9.002 4/111 | Building HIPRT acceleration structure
00:46.968  render           | Fra: 520 | Mem: 167M | Updating Geometry BVH close-up-red-lipstick-kiss-texture-png.005 111/111 | Building HIPRT acceleration structure
00:46.968  render           | Fra: 520 | Mem: 167M | Updating Geometry BVH YF02_14072 6/111 | Building HIPRT acceleration structure
00:46.984  render           | Fra: 520 | Mem: 175M | Updating Geometry BVH pantyhoseg8f_2199 7/111 | Building HIPRT acceleration structure
00:46.984  render           | Fra: 520 | Mem: 179M | Updating Geometry BVH Genesis8FemaleEyelashes 8/111 | Building HIPRT acceleration structure
00:47.078  render           | Fra: 520 | Mem: 498M | Updating Geometry BVH Spiral.011 33/111 | Building HIPRT acceleration structure
00:47.187  render           | Fra: 520 | Mem: 1080M | Updating Geometry BVH NurbsPath.001 34/111 | Building HIPRT acceleration structure
00:47.187  render           | Fra: 520 | Mem: 1080M | Updating Geometry BVH Vert.003 35/111 | Building HIPRT acceleration structure
00:47.781  render           | Fra: 520 | Mem: 6651M | Updating Geometry BVH Cylinder.019 37/111 | Building HIPRT acceleration structure
00:47.828  render           | Fra: 520 | Mem: 6651M | Updating Geometry BVH Cylinder.019 38/111 | Building HIPRT acceleration structure
00:48.000  render           | Fra: 520 | Mem: 6665M | Updating Geometry BVH Cylinder.019 52/111 | Building HIPRT acceleration structure
00:48.187  render           | Fra: 520 | Mem: 6665M | Updating Geometry BVH Cube.023 62/111 | Building HIPRT acceleration structure
00:48.187  render           | Fra: 520 | Mem: 6665M | Updating Geometry BVH Cylinder.029 63/111 | Building HIPRT acceleration structure
00:48.578  render           | Fra: 520 | Mem: 6667M | Updating Geometry BVH Point.015 64/111 | Building HIPRT acceleration structure
00:48.593  render           | Fra: 520 | Mem: 6667M | Updating Geometry BVH close-up-red-lipstick-kiss-texture-png.003 109/111 | Building HIPRT acceleration structure
00:48.656  render           | Fra: 520 | Mem: 6667M | Updating Geometry BVH Lamp_5 69/111 | Building HIPRT acceleration structure
00:48.656  render           | Fra: 520 | Mem: 6667M | Updating Geometry BVH Lamp_4 70/111 | Building HIPRT acceleration structure
00:48.812  render           | Fra: 520 | Mem: 6667M | Updating Geometry BVH Fabric Canvas Creased Curtain.002 92/111 | Building HIPRT acceleration structure
00:48.828  render           | Fra: 520 | Mem: 6667M | Updating Geometry BVH VASO 1 93/111 | Building HIPRT acceleration structure
00:48.843  render           | Fra: 520 | Mem: 6668M | Updating Geometry BVH 1 FOLHAS.003 95/111 | Building HIPRT acceleration structure
00:48.843  render           | Fra: 520 | Mem: 6669M | Updating Geometry BVH 1 FOLHAS.001 96/111 | Building HIPRT acceleration structure
00:48.890  render           | Fra: 520 | Mem: 6689M | Updating Geometry BVH Cube.004 100/111 | Building HIPRT acceleration structure
00:48.906  render           | Fra: 520 | Mem: 6698M | Updating Geometry BVH Sun.002 102/111 | Building HIPRT acceleration structure
00:49.500  render           | Fra: 520 | Mem: 7090M | Updating Geometry BVH Text.001 107/111 | Building HIPRT acceleration structure
00:51.984  render           | Fra: 520 | Mem: 13387M | Updating Scene BVH | Building HIPRT acceleration structure
02:10.656  render           | Fra: 520 | Remaining: 22:43.73 | Mem: 12270M | Sample 192/4096

mira referenced this issue

2026-11-01 15:18:37 +00:00

runner: Render from the job context on Windows, not absolute host paths #41

mira referenced this issue

2026-11-01 15:18:52 +00:00

runner: Render from the job context on Windows, not absolute host paths #41

eva referenced this issue

2026-11-03 17:51:09 +00:00

Runner: treat GPU reset as gpu_hang and retry on GPU (large budget) instead of lockout #48