改动 / #3607

#3607 [Engine] native Windows support for the Intel Arc SYCL port

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

BenchmarksSetup & installAMD / HIPNVIDIA / CUDAModels & quantsDocumentationWindowsLinux

说明

## Problem and result

The Intel Arc engine in `sycl/` is Linux only. On Windows, `setup --backend sycl` stopped with "there is no Windows
path yet" (`docs/INTEL_ARC.md`), the port did not compile with icx on Windows (GCC-style flags, POSIX calls), setup
could not find an Arc (it reads `/sys/class/drm`), and nothing had been run on a card.

This branch adds a native Windows path: no Docker, no WSL, no bash.

- `sycl\tools\build_windows.bat` configures and builds the port with MSVC + oneAPI (`icx`, oneMKL): the whole
  `sycl` project, 232 targets, no errors. GCC-style flags are spelled for icx on Windows (`/fp:precise`,
  `/Qmkl:sequential` through a `_sycl_mkl` variable) and the few POSIX calls are behind `#ifdef _WIN32`.
- `START-HERE.bat` finds an Intel Arc in the display class registry (and offers it beside NVIDIA / AMD when both are
  present), then hands the run to `sycl/setup_intel.py` as on Linux. The engine is `build-sycl-win\strata.exe`, built
  by setup when missing; the run config carries the oneAPI runtime folders in `lib_dirs` instead of the container's
  `sycl_root`.
- The engine runs on an Arc Pro B70 through Level Zero, and the port's own kernel parity tests run on it.

Result on the card (Windows 11 25H2, Core i9-9900, 64 GB, Arc Pro B70 32 GB, driver 32.0.101.8976, oneAPI 2026.2):
Coder IQ1_M with 32K context and 11,264 experts resident (21.46 GiB of VRAM) reads a 4K prompt at 1,451 tok/s and a
16K prompt at 1,407 tok/s, decodes at 51 tok/s on the benchmark suite's chat questions (66 tok/s on a nine-question
short-answer set) and 57.7 tok/s in its agent session; IQ3_XXS, whose experts partly stream, gives 906 / 955 tok/s and
38 tok/s. Both reports are in `bench/results/` and `COMMUNITY.md`.

## Related discussion

None: no issue asked for this, so there is no scope agreement yet. It is a substantial addition rather than a focused
fix, and the reasonable alternative is to split it: the Windows port and setup path as one change, and the two
smaller fixes (`tools/strata_bench.py` naming an Intel card instead of "CPU only", and `gr_parity` skipping a block the
port does not build) plus the documentation and benchmark reports as separate ones. Say which you prefer and I will
reshape it.

## Approach

- **Build and portability** (`sycl/CMakeLists.txt`, `sycl/src/**`): Windows spellings for the compiler flags, `_mkdir`
  for the new i9/int8 cache folder, `#ifdef _WIN32` around the parity tests' POSIX includes, and a few kernel-launch
  paths that need the Windows queue (pinned loader, `sycl_queue.hpp`, `generate.cpp`'s native device probe).
- **Setup** (`setup.py`, `sycl/setup_intel.py`, `sycl/tools/build_windows.bat`, `tools/test_setup_sycl.py`): an Arc is
  detected from the registry before the NVIDIA/AMD choice, the engine is built by `build_windows.bat` when
  `build-sycl-win\strata.exe` is missing, the config points at it with the oneAPI runtime folders on `lib_dirs`, and
  the Level Zero device selector, free-memory and command-graph aspects the port needs are checked before a run.
- **GGUF reads** (`sycl/include/strata/positioned_file.hpp`, `sycl/src/core/gguf_expert_source.cpp`,
  `sycl/tests/host/positioned_file_test.cpp`): one positioned reader shared by `GgufExpertSource` and a host-only test
  (the Windows overlapped read, the POSIX `pread`), so the test exercises what `--stream-experts` does.
- **Smaller fixes**: `tools/strata_bench.py` also names Intel cards on Windows (it asked the registry for AMD only,
  so a B70 run was headed "CPU only"), and `sycl/src/kernels/gr_parity.cpp` prints SKIP for `STRATA_QFUSE`, which the
  port does not build.

Nothing here changes the default path of any other backend: CUDA and HIP builds are untouched, the Intel build stays a
separate CMake target off by default, and the Windows behaviour only appears on Windows.

## Validation

**Passed:**

- `sycl\tools\build_windows.bat` — 232 targets, 0 errors, 50 executables (icx 2026.2, MSVC 14.51, Windows 11 25H2,
  Arc Pro B70 32 GB, driver 32.0.101.8976).
- `build-sycl-win\positioned_file_test.exe` — PASS (8 threads on one shared handle, an offset past 4 GiB, short
  reads, end of file, an invalid handle, a missing file).
- `ctest --test-dir build-sycl-win` — 30 of 31 model-free parity tests pass on the card through Level Zero; the
  details of the one failure are below. `sycl_payload_pairs` passes when run through ctest (it needs
  `STRATA_DOORBELL_CHECK=1`, which the test entry sets).
- `python tools\test_setup_*.py` — all pass except `test_setup_golden.py` (19) and `test_setup_menu.py` (1), which
  fail the same way on upstream main without this branch.
- `python tools\test_strata_bench.py` — 18 pass, including the new Windows case for the Intel card.
- `tools/strata_bench.py --long` on Coder IQ1_M and IQ3_XXS — numbers above; reports in `bench/results/`.

**Failed:**

- `s2_expert_grouped_parity` — the 20-group `moe_grouped_s2` and resident cases differ bitwise between the new and the
  previous grouped kernel on Battlemage (fp32: 140,689 output floats; fp16: gate/up scratch only), while both stay
  within 1e-7 of the host reference. The "hit" variants are bitwise identical. I have not established whether this is
  intended precision on this card or a real ordering difference; it is the one open item.

**Not run:**

- CUDA and HIP builds: this branch touches `setup.py` and the SYCL tree only, and the Windows setup path is behind
  `WIN`, but I could not build those backends here.
- Linux SYCL: no Linux machine with an Arc, so the Linux path is unchanged by inspection, not by a run.
- Windows: the Arc A-series, two cards, pictures, and the Docker path. The JIT and the AOT (`bmg-g31`) builds measured
  the same, so neither is recommended over the other for speed.

## Limits

- Level Zero is required. If SYCL shows the card only as `[opencl:gpu]`, setup refuses it; on the PC measured here
  that happened because `HKLM\SOFTWARE\Intel\oneAPI\LevelZero\1\LevelZeroLoaderPath` held the DLL path instead of the
  folder that holds it (`C:\Windows\System32`). `docs/INTEL_ARC.md` documents the symptom, the `UR_L0_DEBUG=1`
  check and the one-line fix.
- The decode rate moves with the question mix (51 to 66 tok/s on the same server), so figures are only comparable
  within one suite.
- The grouped MoE bitwise difference above.

本站相关内容

相关页面的快捷入口。