Conversation
…a, xpu] and setup oneAPI 2025.3.1
…imize python DLL loading logic, and fix typos
…OOT env, and add wheel-finding error checks
|
Thanks for submitting this pull request! The maintainers of this repository would appreciate if you could update the CHANGELOG.md based on your changes. |
… compiler In Intel oneAPI 2025.3.0, icpx.exe identifies as "GNU-like command-line" on Windows. CMake's Ninja generator on Windows generates MSVC-style flags when the C compiler (icx) is MSVC-like. This causes icpx to reject flags like /nologo, /EHsc, /Zi and the CXX compiler check fails. Fix: use icx for CXX on Windows in all 3 cmake invocations in the windows.yml workflow, and in 3rdparty/embree/embree.cmake (ExternalProject for embree SYCL build). icx.exe is MSVC-compatible, handles C++ and supports SYCL via -fsycl, making it consistent with the C compiler. On Linux, icpx remains correct (it is the standard SYCL C++ compiler).
…per byproduct - cpp/tests/CMakeLists.txt: the bare 'tbb' target only exists when TBB is built from source. SYCL builds use OPEN3D_USE_ONEAPI_PACKAGES, which finds TBB via find_package(TBB) and only defines TBB::tbb, causing 'CMake Error: No target "tbb"'. TBB::tbb is defined in both cases. - 3rdparty/embree/embree.cmake: ze_wrapper static lib byproduct was listed twice in BUILD_BYPRODUCTS (once unconditionally, once via the SYCL-conditional ISA_BUILD_BYPRODUCTS), causing Ninja error 'ze_wrapper.lib is defined as an output multiple times' on Windows SYCL builds.
… use lowercase install target for Ninja - CMake script mode (-P) silently resets CMAKE_BINARY_DIR to the script's own invocation directory, ignoring any -D override. iterative_build_examples.cmake relied on -DCMAKE_BINARY_DIR to locate the top build tree, which happened to work for Makefiles/VS generators (which support building from subdirectories) but breaks under Ninja (single monolithic build.ninja), causing every example build to silently fail with 'loading build.ninja: The system cannot find the file specified'. Renamed to a non-reserved variable, EXAMPLE_TOP_BUILD_DIR. - The Build step's 'cmake --target INSTALL' uses the uppercase meta-target name that only exists for the Visual Studio generator; Ninja only defines lowercase 'install'. Switched to lowercase, which works for both generators. Validated locally with oneAPI icx + Ninja: confirmed the working directory now resolves to the top build dir and the install target is found.
…ime mismatches
- cmake/Open3DSetGlobalProperties.cmake:
- Disable /MP for SYCL targets (icx rejects -MP with -fsycl offloading).
- Predefine _Guarded_by_(x)= for SYCL targets so icx tolerates the SAL
concurrency annotation used by recent MSVC STL <execution> headers
(pulled in transitively via oneDPL). Uses a plain quoted
target_compile_options string (not a generator expression or
target_compile_definitions) since CMake mishandles literal parens
in generator-expression content.
- 3rdparty/civetweb/civetweb.cmake: allow C++ exceptions needed by SYCL build.
- 3rdparty/embree/embree.cmake, CMakeLists.txt: force dynamic (/MD) MSVC
runtime whenever BUILD_SYCL_MODULE=ON, since icx's -fsycl offloading is
incompatible with the static runtime.
- 3rdparty/vtk/vtk_build.cmake, 3rdparty/filament/filament_download.cmake,
3rdparty/filament/filament_build.cmake, 3rdparty/find_dependencies.cmake,
3rdparty/libjpeg-turbo/libjpeg-turbo.cmake, 3rdparty/zeromq/zeromq_build.cmake,
3rdparty/jsoncpp/jsoncpp.cmake: propagate the same dynamic-runtime override
to these dependencies so their static libs don't mismatch
(LNK2038/LNK2005/LNK1169) against Open3D's own dynamic-runtime objects
when linking example executables.
- 3rdparty/webrtc/webrtc_download.cmake: (no functional change here; see
workflow change) pre-built WebRTC on Windows only supports the static
runtime, which is incompatible with SYCL's forced dynamic runtime.
- .github/workflows/windows.yml: disable BUILD_WEBRTC for the xpu matrix
leg, since pre-built WebRTC binaries require the static runtime that
SYCL builds cannot use.
Validated locally: full Windows xpu (BUILD_SYCL_MODULE=ON) Ninja build now
completes 632/632 steps with zero errors, including all example
executables and the pybind module.
Bug 13: The Config step initializes the oneAPI environment (setvars.bat) using [System.Environment]::SetEnvironmentVariable with default Process scope, which only affects the Config step's own PowerShell process. Since each GitHub Actions 'run:' block executes in a brand new process, this environment (LIB, INCLUDE, PATH additions for the Intel compiler) was lost by the time the subsequent Build step ran. This caused ExternalProject sub-builds (ext_zlib, ext_directxheaders, ext_directxmath) to fail during Build, since they perform their own fresh CMake compiler ABI detection at that point (invoked as ninja custom commands), and icx could not find its own runtime import library (libircmt.lib) without LIB properly set. Fixed by additionally appending each captured env var to $GITHUB_ENV, which GitHub Actions automatically applies to all subsequent steps in the job. Root-caused and validated locally by reproducing the exact 'LNK1104: cannot open file libircmt.lib' error with a minimal CMake+Ninja+icx project configured in a fresh process lacking the oneAPI environment, and confirming the error disappears once the environment is restored via the same file-based mechanism used by $GITHUB_ENV.
|
@copilot /fix-ci Check: Codacy Static Code Analysis Annotations and output: 33 new issues (0 max.) of at least minor severity.
Issues
======
- Added 33
See the complete overview on Codacy Check: Build and run (2-jammy) Annotations and output: Check: windows (ON, OFF, xpu, Release) Annotations and output: Check: windows (OFF, ON, xpu, Release) Annotations and output: Check: Build wheel (3.14, xpu, false) Annotations and output: Check: MacOS (macos-14, OFF) Annotations and output: Homebrew is currently ignoring formulae, casks and commands from these taps because tap trust is required. Check: MacOS (macos-14, ON) Annotations and output: Homebrew is currently ignoring formulae, casks and commands from these taps because tap trust is required. |
…, persist oneAPI env in build-wheel - 3rdparty/googletest/googletest.cmake: After FetchContent_MakeAvailable, suppress -Wcharacter-conversion for IntelLLVM/ICX on gtest/gmock targets. ICX's Clang front-end errors on char16_t->char32_t implicit conversion in gtest-printers.h(524) which blocks the full Windows xpu build. - .github/workflows/windows.yml (build-wheel Config step): Add the same $GITHUB_ENV persistence (Out-File) that was already present in the 'windows' job Config step. Without it, oneAPI env vars (LIB, INCLUDE, PATH from setvars.bat) were lost at step boundary, causing libircmt.lib not found during ExternalProject configure steps in the Build step.
|
Fixed two Windows xpu CI failures in commit
The MacOS ( |
…th icx on Windows SYCL
…ngle-config generators
Type
Motivation and Context
Adds full Windows SYCL support to align with PyTorch 2025.3.1 (oneAPI 2025.3.1). Migrates the Windows CI matrix from CUDA ON/OFF to target
cpu,cuda, andxpu(SYCL), enablingopen3d_xpuPython wheels and C++ binary distributions with SYCL acceleration on Windows.Checklist:
python util/check_style.py --applyto apply Open3D code style to my code.Description
CMake & Build Infrastructure
BUILD_SYCL_MODULEinCMakeLists.txtto support Windows builds.-syclto the packaged distribution name incmake/Open3DPackaging.cmakewhen built with SYCL.open3d/xpuincpp/pybind/CMakeLists.txtand updatedcpp/pybind/make_python_package.cmaketo bundle thexpudirectory structure.Python Runtime & DLL Loading
python/open3d/__init__.pyto locate and load Intel compiler, oneMKL, and oneTBB redistributable DLL directories. Resolves the runtime directories dynamically usingONEAPI_ROOT(or default paths) withos.add_dll_directoryto prevent DLL loading errors on Python 3.8+.xpusubmodule when running on a SYCL-enabled (xpu) binary.GHA Windows CI / CD Matrix
.github/workflows/windows.ymlfromBUILD_CUDA_MODULE: [ON, OFF]todevice: [cpu, cuda, xpu].xpu.-T "Intel(R) oneAPI DPC++ Compiler"and search forOpenCLdynamically.