贡献 / #1156

#1156 setup: reach the CPU image encoder on Windows + AMD (#1155, #881)

open · @Hugua700 · 0 评论 · 去 GitHub 看

Setup & installServer & APIAMD / HIPNVIDIA / CUDAModels & quantsWindowsLinux

说明

# Reach the CPU image encoder on Windows + AMD

Fixes #1155.

Follow-up to #881 (closed as completed). 0.1.40 fixed the two bugs reported there, but the two blockers in
[its follow-up comment](https://github.com/Niko1221/Strata/issues/881#issuecomment-6011543135) are still on `main`, and
`--vision cpu` cannot work on Windows + AMD without them — on a ready-made engine or a self-built one.

`tools/vision` is a plain MSVC/CMake program linking llama.cpp's `mtmd`; nothing about it is Linux- or NVIDIA-specific
(its `CMakeLists.txt` has an `if(STRATA_PORTABLE AND MSVC)` branch, `strata_vision.cpp` has `#ifdef _WIN32`). It builds
and runs on two Windows-AMD machines — an RX 6800M / gfx1031 and a Strix Halo / gfx1151 — as soon as the plumbing
below is out of the way.

## Commit 1 — `setup: reach the CPU image encoder on Windows + AMD (#881)`

| Where | Change |
|---|---|
| `find_vcvars(cuda13=False)` | The `[16.0,18.0)` range is CUDA 13's requirement, so only a CUDA caller asks for it now. A machine whose only C++ tools are VS 2026 (version 18) could not be seen at all before — although `tools/hip/build_windows.bat` already calls vswhere without a range, so the packaging path builds the whole engine on VS 18 while setup could not find it. `STRATA_VCVARS=<vcvars64.bat>` picks one by hand, for a range-matched install that is broken (there, VS 2019 Build Tools without `mspdbcore.dll` → `C1356`). |
| `hip_vision()` | `--vision cpu` means the CPU encoder on every platform; the `and WIN` gate is gone. |
| `build_vision_cpu()` | Where no MSVC is found, warn and leave images off instead of stopping setup: the engine is already installed and works, and a PC without the C++ build tools must not lose it over the encoder. The Windows encoder build also passes `-DSTRATA_PORTABLE=ON` (the static runtime, as `build_windows.bat` builds the engine). |
| `main()` | Opening the gate alone would be a **regression**, not a fix: the `not hip` there skips the whole vision block, so the ready-made Windows-AMD engine installs no encoder while setup.py:4911-4917 writes the model config's `vision` block pointing at `engine/strata-vision.exe` — which nothing created. The ready-made engine now builds and installs the CPU encoder **beside** itself: the encoder only, never the HIP engine, which needs the ROCm toolchain the ready-made one exists to avoid. `pip_cuda_libs()` is skipped on the HIP path for the same reason. |

## Commit 2 — `tools/hip: ship the CPU image encoder in the ready-made zip (#881)`

Optional and additive: it only removes the C++ toolchain requirement from the user's PC, which is what the "the
ready-made Windows AMD engine has no image encoder" message has always really meant.

* `build_windows.bat` builds `strata-vision.exe` in the packaging run when a llama.cpp source tree is at hand
  (`STRATA_GGML_DIR`, else `third_party/llama.cpp`); without one the zip is what it always was, with a note.
* `package_windows.py` copies it in when the build has it, follows its imports for the DLL walk like the other two
  programs, and records `"vision": "cpu"` in the zip's `BUILD.json`.
* `build_vision_cpu()` takes a shipped encoder as it is when no `vision_src` is recorded.

## Verification

On the RX 6800M / gfx1031 machine of #881 (Windows 11, Chinese locale, **only VS 2026 Build Tools** installed):

```
before:  find_vcvars()                     -> None
after:   find_vcvars()                     -> C:\Program Files (x86)\Microsoft Visual Studio\18\BuildTools\VC\Auxiliary\Build\vcvars64.bat
         find_vcvars(cuda13=True)          -> None            (the CUDA path is unchanged: VS 18 is still refused there)
         STRATA_VCVARS=<path>              -> <path>;  a path that does not exist -> None
```

Both files pass `python -m py_compile`. The encoder built with exactly the flags of commit 1 runs on this machine's
self-built 0.1.40 HIP engine: setup reports `images: on (encoder on the CPU)`, `/health` reports `"images": true`, and
a 720x360 test image is read correctly through `/v1/chat/completions`.

What I could not run here is a full `build_windows.bat` (needs the ROCm toolchain and 10-20 minutes) and a real
`setup.py --vision cpu` on a ready-made engine; I will test either if you want, or drop commit 2 if the packaging
change is not wanted.

本站相关内容

相关页面的快捷入口。