You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: test/cpp_extensions/open_registration_extension/README.md
+19-11Lines changed: 19 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,29 +1,37 @@
1
+
# PyTorch OpenReg
2
+
1
3
This folder contains a self-contained example of a PyTorch out-of-tree backend leveraging the "PrivateUse1" backend from core.
2
4
3
5
## How to use
6
+
4
7
Install as standalone with `python setup.py develop` (or install) from this folder.
5
-
You can run test via `python test/test_openreg.py`.
8
+
You can run test via `python {PYTORCH_ROOT_PATH}/test/test_openreg.py`.
6
9
7
10
## Design principles
11
+
8
12
For simplicity anything that can be implemented from python is done so.
9
13
A real implementation will most likely want to call these different APIs from c++ directly.
10
14
11
15
The current version sends everything back to python and contains enough implementation to run basic model, transfer host/device and printing.
12
16
13
17
The codebase is split as follows:
14
-
-`pytorch_openreg/__init__.py` imports torch to get core state initialized, imports `._aten_impl` to register our aten op implementations to torch, imports `.C` to load our c++ extension that registers more ops, allocator and hooks and finally renames the PrivateUse1 backend and register our python-side module.
15
-
-`pytorch_openreg/_aten_impl.py` does two main things. Use the `_register_same_name()` function to register hooks from c++ (like getDevice, getStream, etc) and send them to our device daemon. Define a new `torch.Library` that registers a fallback that will be called whenever a backend kernel for PrivateUse1 is called. It contains the logic to handle all kind of native functions, computing the output metadata, allocating it and only calling into the device daemon to perform computation
16
-
-`pytorch_openreg/_device_daemon.py` contains the Allocator (responsible for allocating memory on the device side, as int8 buffers, and recreating nice looking Tensors on the device side to be able to use aten ops to run code there), `run_op` that is the logic running on the device side to perform compute (for simplicity of coverage, we are re-building full blown Tensors here and calling aten ops on them). It also contains the Daemon responsible for the device worker process and sending data back and forth.
17
-
-`pytorch_openreg/_meta_parser.py` mainly contain utilities to send objects over the wire from the user process to the device process. The main class there is `OpenRegTensorMeta` that contains all the metadata sent to the device which should be enough for it to populate the output Tensor.
18
+
19
+
-`pytorch_openreg/__init__.py`
20
+
- imports torch to get core state initialized.
21
+
- imports `._aten_impl` to register our aten op implementations to torch.
22
+
- imports `.C` to load our c++ extension that registers more ops, allocator and hooks.
23
+
- renames the PrivateUse1 backend and register our python-side module.
24
+
-`pytorch_openreg/_aten_impl.py`
25
+
- Define a new `torch.Library` that registers a fallback that will be called whenever a backend kernel for PrivateUse1 is called. It contains the logic to handle all kind of native functions, computing the output metadata, allocating it and only calling into the device daemon to perform computation.
26
+
-`pytorch_openreg/_device_daemon.py`
27
+
- contains the Allocator (responsible for allocating memory on the device side and host side, as int8 buffers).
28
+
- contains `Driver`, which as user-process driver to deal with some information needed to be done in driver.
29
+
- contains `Executor`, which as device-process exector to do something related device logic.
30
+
-`pytorch_openreg/_meta_parser.py` mainly contain utilities to send objects over the wire from the user process to the device process.
31
+
- The main class there is `OpenRegTensorMeta` that contains all the metadata sent to the device which should be enough for it to populate the output Tensor.
18
32
19
33
## Next steps
20
34
21
-
Currently, the autograd test is disabled because it's missing the getStream implementation.
22
35
The main next step would be to:
23
-
- Split the daemon into a proper user-process driver vs device-process executor. The main goal would be to better mimick which information is held on the user-process side and when we're actually communicating with the device. In particular current device or stream should be user-process informations.
24
-
- Add Stream/Event system. Most likely by having multiple requests queue that go to the device from the driver.
25
-
- Add RNG Generator.
26
36
27
-
Longer term:
28
37
- Replace the current `open_registration_extension.cpp` test in PyTorch CI with this.
29
-
- Build this module in the CI environment and enable Device-generic tests on this device.
0 commit comments