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
We intend to integrate PyTorch Custom Operators as the primary mechanism for dispatching to device-specific operator implementations. An initial scaffolding of this is presented in PR #1544. This RFC will serve as a guideline to collect community feedback and refine our development plans moving forward.
Why?
Registering operators with torch.library allows us to take advantage of the existing device dispatch mechanisms in PyTorch.
We can treat calls to functionality in our CUDA kernels, or other low-level backend implementations, as opaque for improved torch.compile support.
This helps to simplify the development for additional backends, while taking an idiomatic modern PyTorch approach.
What about the multi-backend-refactor branch?
We are planning to deprecate further development on that branch upon the merging of #1544. After that point, the expectation is that we will implement backends using the new custom operator registration mechanisms. We expect to be able to reuse much of the existing implementations in the refactoring process.
Our goal is to aggressively mainline our in-tree backends, while additionally enabling out-of-tree backends. We will expand on this topic in the near future.
Supersedure
This RFC is intended to supersede topics which were covered in previously related RFCs which remained open as of this writing:
Purpose
We intend to integrate PyTorch Custom Operators as the primary mechanism for dispatching to device-specific operator implementations. An initial scaffolding of this is presented in PR #1544. This RFC will serve as a guideline to collect community feedback and refine our development plans moving forward.
Why?
torch.libraryallows us to take advantage of the existing device dispatch mechanisms in PyTorch.torch.compilesupport.What about the
multi-backend-refactorbranch?We are planning to deprecate further development on that branch upon the merging of #1544. After that point, the expectation is that we will implement backends using the new custom operator registration mechanisms. We expect to be able to reuse much of the existing implementations in the refactoring process.
Our goal is to aggressively mainline our in-tree backends, while additionally enabling out-of-tree backends. We will expand on this topic in the near future.
Supersedure
This RFC is intended to supersede topics which were covered in previously related RFCs which remained open as of this writing:
Related Issues
Related issues and discussions include:
Additionally, this relates to the following issues and discussions which have been closed:
Relevant contributors
The following contributors may have particular interest and feedback on this topic:
@Titus-von-Koeller
@christoph-koehncke
@jiqing-feng
@pnunna93
@akx
@rickardp
@ji-huazhong
@SlightwindSec