Name Date Size #Lines LOC

..--

pytorch_openreg/H25-Apr-2025-854563

test/H25-Apr-2025-6542

README.mdH A D25-Apr-20253 KiB3123

setup.pyH A D25-Apr-20251.7 KiB6447

README.md

1This folder contains a self-contained example of a PyTorch out-of-tree backend leveraging the "PrivateUse1" backend from core.
2
3## How to use
4Install as standalone with `python setup.py develop` (or install) from this folder.
5You can run test via `python test/test_openreg.py`.
6
7## Design principles
8For simplicity anything that can be implemented from python is done so.
9A real implementation will most likely want to call these different APIs from c++ directly.
10
11The current version sends everything back to python and contains enough implementation to run basic model, transfer host/device and printing.
12
13The 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## Next steps
20
21Currently, the autograd test is disabled because it's missing the getStream implementation.
22The 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- Add Pinned memory and HostAllocator.
27
28Longer term:
29- Replace the current `open_registration_extension.cpp` test in PyTorch CI with this.
30- Build this module in the CI environment and enable Device-generic tests on this device.
31