Hey @albanD, sorry to bother you.

PyTorch provides some CMake targets, such as torch_cpu_library and torch_cuda_library, but it doesn't provide a CMake target for torch_python, which is very useful for out-of-tree backends, as they require some Python bindings. We currently wrap a CMake target for torch_python in the openreg project, but it would be even better if Torch itself could provide one.

Ho that is interesting.
I would have expected that our torch.utils.cpp_extension uses a cmake target to build these cpp extensions. But it doesn't?

As far as I know, basic functions in torch.utils.cpp_extension such as CPPExtension use -ltorch_python and specify library_dir directly to build the extension instead of using cmake targets.

In addition, requirements of torch.utils.cpp_extension and integration of the new accelerator are slightly different; the core functions of the former are basically compiled into the extension library itself (such as _C.so), while the latter extension library itself is just an intermediate layer from Python to C++, and the core functions are all in the accelerator's own torch_binding.so. torch.uitls.cpp_extension is more suitable for PyTorch users to extend some functions of torch (such as Pluggable Allocator), but it is not suitable for the latter. A highly integrated CMake object like torch_python_library is what the latter needs.

Ok!
Adding a new target sounds good then.
cc @swolchok can you give a quick look at the new cmake target? Is that the right style that we want going forward?

Why are all of these set by hand?
Also shouldn't we get these from the torch_python library below?

Thank you for your advices.

• PyTorch does not provide torch_python or torch_python_library, which we intend to provide.
• Besides manually specifying the torch_python library path, other properties can be unified and directly use CMake targets, such as c10 and torch_cpu provided by PyTorch, without manual settings.
• We will also remove any unnecessary information.

@can-gaa-hou will do a update right now.

@FFFrog, Thanks for pointing out some redundant lines of code and explaining what is going on here. I have removed some useless code. Please let me know if there are any other questions.

Shouldn't all of these be standard properties?

Yes, those definitions is not necessary for OpenReg and will delete it.

Why do we set these flags?

ditto

Why do we need this now?

Got it, will dele it and keep DEBUG as the default CMAKE_BUILD_TYPE

Debug mode is quite complicated on Windows because it will load different DLLs at runtime and use python_d rather than python. Since OpenReg is still under development and there are not many lines of code, we can easily debug even if we build in Release Mode. To make this PR simple, I will support Debug mode in another PR.

This is surprising that we have to do so much here? We don't usually do that for our cpp extensions.

The dynamic library search mechanism on Windows differs from that on Linux/OSX, making it impossible to set RPATH and LIBRARY_PATH.

OpenReg is split into dynamic libraries: _C, torch_binding.so, torch_openreg.so, and openreg.so.

torch_openreg:
└── torch_openreg
    ├── lib
    │   ├── torch_bindings.lib
    │   ├── torch_openreg.lib
    │   └── openreg.lib
    └── _C.pyd

These libraries are not in the same directory as _C, making it impossible for PyTorch to find these libraries on Windows.

Therefore, we referenced the relevant implementation in Torch:

The above method contains much information that OpenReg doesn't use. We should have adapted it, but we didn't, which is our problem and will fix it right now @can-gaa-hou

You are right! Torch itself has already loaded a bunch of DLLs when we import torch on Windows; therefore, there is no need for us to load them twice when importing torch_openreg. I have fixed the code, and please let me know if there are any questions.

Why is this only windows?

Same as below, Windows requires all symbols to be resolved at link time. We are using Python Dependency here to build our library; therefore, we need to explicitly find the Python library and link it to our target. I have refactored the code so that CMake will be executed for the same purpose on both Windows and macOS.

Why do we need this one on macos?

By default, Linux does not require all symbols to be resolvable when generating dynamic libraries. As long as the symbols can be resolved at runtime, it is fine. However, this is not the case on MAC. The effect of adding this -undefined dynamic_lookup is the same as Linux. Unresolved Python symbols are ignored first and relocated at runtime.

PyTorch also uses the same approach, see this for more information.

any details on what doesn't work on this?

In this testcase, we use "/proc/{pid}/task" to access a process, which works fine on Linux but not on Windows. If it is necessary to test autograd on Windows, I would like to support it :)