Windows native port #2478

gshimansky · 2024-10-11T23:53:21Z

Fixes #2407. Current state is that code builds on windows and is able to pass many unit tests. More fixes will be done when this patch is integrated into main branch.

whitneywhtsang · 2024-10-12T00:02:10Z

Please fix the CI failures. And can we add testing to prevent regression?

gshimansky · 2024-10-12T00:35:15Z

Please fix the CI failures. And can we add testing to prevent regression?

Sure, we will add windows CI too but at the moment we don't have almost any windows infrastructure, and we need to figure out how to do automation. All of the bash scripts are not going to run on windows.

gshimansky · 2024-10-16T02:23:22Z

CI is green on Linux so PR is ready for review now.

victor-eds

Is this intended to be upstreamed?

CMakeLists.txt

bin/RegisterTritonDialects.h

python/test/unit/language/test_core.py

python/test/unit/language/print_helper.py

python/test/unit/language/test_reproducer.py

python/test/unit/language/test_compile_errors.py

python/triton/compiler/compiler.py

third_party/intel/backend/driver.py

python/test/unit/language/test_subprocess.py

python/triton/backends/compiler.py

third_party/intel/backend/driver.c

include/triton/Conversion/TritonToTritonGPU/TritonToTritonGPUPass.h

python/setup.py

@andreigh

* based on Windows support PR triton-lang#2465 by @andreigh - triton-lang#2465 * manually applied, rebased, fix lint errors * use sysconfig.get_config_var() to get the path of python*.lib * clang fix for windows * remove '-fPIC' for windows clang * fix download_and_copy() to support windows * add "exe" extension for windows * use "pyd" extension for windows to make importlib work * third_party/nvidia: fix for windows * win32 fix _path_to_binary() * add library_dir, include_dir for win32 * backend/compiler lazy remove temp files to support windows * additional works done by @mantaionut (2024/05/31) * rework for latest triton and cleanup (2024/10/14) * extract minimal fixes to support win32+clang (2024/10/16) * get exe/so extension using sysconfig (suggested by @anmyachev) see also: intel/intel-xpu-backend-for-triton#2478 Original-author-by: Andrei Gheorghe <andrei@dharmaventures.co> Signed-off-by: Won-Kyu Park <wkpark@gmail.com>

@andreigh

* based on Windows support PR triton-lang#2465 by @andreigh - triton-lang#2465 * manually applied, rebased, fix lint errors * remove '/A' platform option to use ninja * use sysconfig.get_config_var() to get the path of python*.lib * clang fix for windows * remove '-fPIC' for windows clang * fix download_and_copy() to support windows * add "exe" extension for windows * use "pyd" extension for windows to make importlib work * third_party/nvidia: fix for windows * win32 fix _path_to_binary() * add library_dir, include_dir for win32 * backend/compiler lazy remove temp files to support windows * additional works done by @mantaionut (2024/05/31) * rework for latest triton and cleanup (2024/10/14) * extract minimal fixes to support win32+clang (2024/10/16) * get exe/so extension using sysconfig (suggested by @anmyachev) see also: intel/intel-xpu-backend-for-triton#2478 Original-author-by: Andrei Gheorghe <andrei@dharmaventures.co> Signed-off-by: Won-Kyu Park <wkpark@gmail.com>

@andreigh

* based on Windows support PR triton-lang#2465 by @andreigh - triton-lang#2465 * manually applied, rebased, fix lint errors * remove '/A' platform option to use ninja * use sysconfig.get_config_var() to get the path of python*.lib * clang fix for windows * remove '-fPIC' for windows clang * fix download_and_copy() to support windows * add "exe" extension for windows * use "pyd" extension for windows to make importlib work * third_party/nvidia: fix for windows * win32 fix _path_to_binary() * add library_dir, include_dir for win32 * backend/compiler lazy remove temp files to support windows * additional works done by @mantaionut (2024/05/31) * rework for latest triton and cleanup (2024/10/14) * extract minimal fixes to support win32+clang (2024/10/16) * get exe/so extension using sysconfig (suggested by @anmyachev) see also: intel/intel-xpu-backend-for-triton#2478 Original-author-by: Andrei Gheorghe <andrei@dharmaventures.co> Signed-off-by: Won-Kyu Park <wkpark@gmail.com>

@andreigh

* based on Windows support PR triton-lang#2465 by @andreigh - triton-lang#2465 * manually applied, rebased, fix lint errors * remove '/A' platform option to use ninja * use sysconfig.get_config_var() to get the path of python*.lib * clang fix for windows * remove '-fPIC' for windows clang * fix download_and_copy() to support windows * add "exe" extension for windows * use "pyd" extension for windows to make importlib work * third_party/nvidia: fix for windows * win32 fix _path_to_binary() * add library_dir, include_dir for win32 * backend/compiler lazy remove temp files to support windows * additional works done by @mantaionut (2024/05/31) * rework for latest triton and cleanup (2024/10/14) * extract minimal fixes to support win32+clang (2024/10/16) * get exe/so extension using sysconfig (suggested by @anmyachev) see also: intel/intel-xpu-backend-for-triton#2478 Original-author-by: Andrei Gheorghe <andrei@dharmaventures.co> Signed-off-by: Won-Kyu Park <wkpark@gmail.com>

bin/CMakeLists.txt

lib/Tools/LinearLayout.cpp

python/setup.py

python/src/main.cc

Signed-off-by: Gregory Shimansky <gregory.shimansky@intel.com>

python/triton/compiler/compiler.py

third_party/nvidia/backend/compiler.py

anmyachev · 2024-11-04T15:15:30Z

python/setup.py

+    return None
+
+
+def find_visual_studio(version_ranges):


Could we reuse code from CLFinder.py?

We can and it should work in theory, but it doesn't. For some reason when I import these functions from CLFinder I am getting an error LINK : fatal error LNK1168: cannot open C:\b\tr\python\triton\_C\libtriton.pyd for writing. I have no idea how they are related but this link error is stably reproducible for me. I tried to debug the problem and found that environment after calling set_env_vars is identical when functions are reused from CLFinder.py or setup.py has its own copies, so now I am out of ideas how libtryton.pyd may end up locked.

…:getSubOpSize` for portability between platforms (#2620) Part of #2478. To reduce diff. --------- Signed-off-by: Anatoly Myachev <anatoly.myachev@intel.com> Co-authored-by: Ettore Tiotto <ettore.tiotto@intel.com>

Signed-off-by: Gregory Shimansky <gregory.shimansky@intel.com>

python/setup.py

anmyachev · 2024-11-06T15:53:09Z

python/setup.py

+        raise FileNotFoundError("vswhere.exe not found.")
+
+    for version_range in version_ranges:
+        command = [


For me it works only if I specify -products:
"C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe" -version "[17.0,18.0)" -products Microsoft.VisualStudio.Product.BuildTools -requires Microsoft.VisualStudio.Component.VC.Tools.x86.x64 -property installationPath -prerelease

@gshimansky do you know why?

For me it works just fine if I don't specify -products or if I specify -products "*". Specifying -products Microsoft.VisualStudio.Product.BuildTools doesn't find anything for me but specifying -products Microsoft.VisualStudio.Product.Professional does.

-products "*" works for me too. It seems that this is because I did not install the entire studio, but only the build tools. Should we add -products "*" to allow this case?

I don't know whether it may result in multiple different products found as the result, but we can add it for now.

I don't know whether it may result in multiple different products found as the result, but we can add it for now.

I thought about that too. But couldn't it be the same default behavior when -products parameter is not specified at all?

….py` (#2637) Part of #2478 Signed-off-by: Anatoly Myachev <anatoly.myachev@intel.com>

Signed-off-by: Gregory Shimansky <gregory.shimansky@intel.com>

anmyachev · 2024-11-07T19:53:41Z

third_party/nvidia/backend/driver.c

+    }                                                                          \
+    symbolName##_t funcHandle =                                                \


Should we explicitly clear any existing error on Windows as well?

Suggested change

} \

symbolName##_t funcHandle = \

} \

/* Clear any existing error */ \

SetLastError(NO_ERROR); \

symbolName##_t funcHandle = \

I don't think that is needed. GetLastError is used for information purposes only (think of it as of errno in POSIX), any next call of Win32 API should set its own error status, clear it if it is successful.

python/triton/backends/compiler.py

third_party/nvidia/backend/driver.c

Signed-off-by: Gregory Shimansky <gregory.shimansky@intel.com>

third_party/nvidia/backend/compiler.py

Signed-off-by: Gregory Shimansky <gregory.shimansky@intel.com>

anmyachev · 2024-11-11T10:01:03Z

third_party/intel/backend/driver.c

@@ -194,8 +194,18 @@ static PyObject *loadBinary(PyObject *self, PyObject *args) {
    const size_t binary_size = PyBytes_Size(py_bytes);

    uint8_t *binary_ptr = (uint8_t *)PyBytes_AsString(py_bytes);
-    const auto ctx =
-        sycl_device.get_platform().ext_oneapi_get_default_context();


Could we make this available on Windows using set SYCL_ENABLE_DEFAULT_CONTEXTS=1: https://github.com/intel/llvm/blob/7dd09d9effd6a56d2c0c7abca38b21baa4d77fc8/sycl/doc/EnvironmentVariables.md?plain=1#L22?

I checked this and it does work. But I am not sure it is a good way because triton on Windows will work only with this variable set to 1. Even on Linux if someone has environment SYCL_ENABLE_DEFAULT_CONTEXTS=0 we're going to throw an uncaught exception, are you sure it is ok?

gshimansky requested a review from whitneywhtsang October 11, 2024 23:53

etiotto requested review from a team and alexbaden October 15, 2024 14:57

gshimansky force-pushed the gregory/windows-support branch 2 times, most recently from d1baf6d to 45d26b3 Compare October 15, 2024 22:13

victor-eds reviewed Oct 16, 2024

View reviewed changes

CMakeLists.txt Outdated Show resolved Hide resolved

CMakeLists.txt Outdated Show resolved Hide resolved

bin/RegisterTritonDialects.h Outdated Show resolved Hide resolved