Skip to content

v0.2.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 25 Jun 15:31
v0.2.2
87fa109
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

stable-diffusion-go v0.2.2 — pure-Go binding + prebuilt native libraries.

Built from leejet/stable-diffusion.cpp @ 19bdfe2 (upstream pin: master-685-19bdfe2).

go get github.com/Pendra-Cloud/stable-diffusion-go@v0.2.2 for the
binding; the lib archives attached here match this exact tag. Each archive
contains a self-contained libstable-diffusion (ggml statically linked,
hidden visibility — exports only the sd_* symbols pkg/sd/load.go registers).

CUDA archives require a matching host CUDA runtime; Vulkan archives require
a Vulkan loader/ICD on the host. The Windows archive carries the per-CPU/GPU
(avx2/avx512/avx/noavx/vulkan/cuda13) subdir tree the binding selects from.

Why

The Windows CUDA SD build (cuda12 leg) fails on windows-latest, and because windows_assemble needs the windows job and the auto-release job needs windows_assemble, that single leg has been blocking every release — no new tag or lib artifacts have published since the toolchain drift began. (This is why v0.2.2 with the image-gen callback fix never got tagged.)

Root cause: GitHub's windows-latest image now ships Visual Studio 18 / MSVC 14.51, and CUDA 12.9.1's nvcc rejects it:

host_config.h(170): fatal error C1189: unsupported Microsoft Visual Studio version!

This is environmental (a runner image bump), not a code change. The fix isn't to chase whatever VS the runner ships — it's to make the build deterministic and stop a no-consumer variant from gating releases.

What

  • Align Windows CUDA to 13.0.0 — matching the Linux CUDA build (nvidia/cuda:13.0.0) and the worker's CUDA 13 runtime requirement (libcudart.so.13). Renames the variant subdir cuda12 → cuda13 consistently across the workflow, the loader (pkg/sd/load.go windowsLibCandidates), README.md, and .gitignore.
  • Pin the CUDA leg to windows-2022 (per-leg runs-on), whose VS2022 host compiler CUDA 13's nvcc supports — rather than inheriting whatever Visual Studio the latest runner happens to have.
  • Make the CUDA leg best-effort (continue-on-error). Nothing Pendra ships bundles Windows CUDA SD — NVIDIA-on-Windows uses the Vulkan build (cudart is a separate ~half-GiB non-redistributable). So a future host/CUDA mismatch must never block a release again. windows_assemble now requires the 5 mandatory CPU/Vulkan DLLs and treats cuda13 as optional (5 or 6 both valid).

Effect

The 5 variants the product actually ships always build and publish; the CUDA leg ships when the pinned toolchain builds it and is harmless when it doesn't. Merging this unblocks the auto-tag + release that was stuck.

🤖 Generated with Claude Code

What's Changed

  • ci(pr-agent): sync to v0.36.1 with var-driven model + comment de-dup by @tomcrawf90 in #23
  • fix: return uintptr from C-ABI callbacks so Windows image gen works by @tomcrawf90 in #22
  • ci(windows): align CUDA SD to 13, pin VS2022 host, de-gate the release by @tomcrawf90 in #24

Full Changelog: v0.2.1...v0.2.2

Contributors

tomcrawf90
Assets 9
Loading