TarasandJeff Daily
51177cecf2
Fixes: - #169816. ## Root cause FBGEMM has been silently disabled on every Windows x64 build since #158210. `CMAKE_SYSTEM_PROCESSOR` is `AMD64` on Windows, but the gate introduced there only allows `x86_64|aarch64`, so `set(USE_FBGEMM OFF)` fires unconditionally it also overrides `USE_FBGEMM=1` from the environment. Windows is left with `onednn` as the only quantized engine, so torchvision's pretrained quantized models (which pin `backend="fbgemm"` via `weights.meta`) fail with `RuntimeError: Quantized backend not supported`. ## Changes **`CMakeLists.txt`**: allow `AMD64`, and restore the 32-bit exclusion #158210 dropped. The pointer-size check is required because 32-bit Windows also reports `AMD64`. It additionally excludes 32-bit `-m32`/x32/ILP32 builds. No 64-bit platform changes. **`cmake/Modules/FindAVX.cmake`**: MSVC exposes AVX intrinsics without any `/arch:` flag, so the no-op `" "` candidate won and cached `CXX_AVX*_FLAGS=' '`. fbgemm reuses those cache variables, so its AVX targets built without `/arch:`, `__AVX2__` went undefined, and the kernels guarded by it failed to compile (`error C3861: 'transpose_kernel_mxn_sse'`). Probe the real flag first on MSVC. The non-MSVC branch is unchanged. ## Behavior change Default qengine on Windows moves from `onednn` to `x86`, matching Linux. ## Test Plan ``` cmake -U "C_AVX*" -U "CXX_AVX*" -U "C_HAS_AVX*" -U "CXX_HAS_AVX*" -U USE_FBGEMM -S . -B build pip install -e . -v --no-build-isolation python -c "import torch; print(torch.backends.quantized.supported_engines)" ``` Before: `['onednn']`. After: `['onednn', 'x86', 'fbgemm']`. Issue repro now loads and runs: ```python import torch, torchvision m = torchvision.models.quantization.resnet18(weights="DEFAULT", quantize=True).eval() m(torch.randn(1, 3, 224, 224)) ``` Pull Request resolved: https://github.com/pytorch/pytorch/pull/198490 Approved by: https://github.com/jeffdaily Co-authored-by: Jeff Daily <jeff.daily@amd.com>
This folder contains various custom cmake modules for finding libraries and packages. Details about some of them are listed below.
FindOpenMP.cmake
This is modified from the file included in CMake 3.13 release, with the following changes:
-
Replace
VERSION_GREATER_EQUALwithNOT ... VERSION_LESSasVERSION_GREATER_EQUALis not supported in CMake 3.5 (our min supported version). -
Update the
separate_argumentscommands to not useNATIVE_COMMANDwhich is not supported in CMake 3.5 (our min supported version). -
Make it respect the
QUIETflag so that, when it is set,try_compilefailures are not reported. -
For
AppleClangcompilers, use-Xpreprocessorinstead of-Xclangas the later is not documented. -
For
AppleClangcompilers, an extra flag option is tried, which is-Xpreprocessor -openmp -I${DIR_OF_omp_h}, where${DIR_OF_omp_h}is a obtained usingfind_pathonomp.hwithbrew's default include directory as a hint. Without this, the compiler will complain about missing headers as they are not natively included in Apple's LLVM. -
For non-GNU compilers, whenever we try a candidate OpenMP flag, first try it with directly linking MKL's
libompif it has one. Otherwise, we may end up linking twolibomps and end up with this nasty error:OMP: Error #15: Initializing libomp.dylib, but found libiomp5.dylib already initialized. OMP: Hint This means that multiple copies of the OpenMP runtime have been linked into the program. That is dangerous, since it can degrade performance or cause incorrect results. The best thing to do is to ensure that only a single OpenMP runtime is linked into the process, e.g. by avoiding static linking of the OpenMP runtime in any library. As an unsafe, unsupported, undocumented workaround you can set the environment variable KMP_DUPLICATE_LIB_OK=TRUE to allow the program to continue to execute, but that may cause crashes or silently produce incorrect results. For more information, please see http://openmp.llvm.org/See NOTE [ Linking both MKL and OpenMP ] for details.