Skip to content

[RFC] Relax Upstreaming #89

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
YuchenJin wants to merge 4 commits into from
+776 −0
Closed

[RFC] Relax Upstreaming #89

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
293fb5b
relax upstreaming rfc.
YuchenJin Aug 18, 2022
a68a956
Add clarifying statements.
YuchenJin Aug 24, 2022
0e411f5
Update based on comments.
YuchenJin Aug 29, 2022
0f9c355
Add Rationale and alternatives section.
YuchenJin Sep 26, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add clarifying statements.
  • Loading branch information
@YuchenJin
YuchenJin committed Aug 24, 2022
commit a68a9569e309cd0b00ffce710ba934467d24b9ac
5 changes: 5 additions & 0 deletions rfcs/0089-relax-upstreaming.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -23,6 +23,11 @@ The main focus of this upstreaming RFC is to upstream the **core foundation** of
- **Minimize disruption:** This upstreaming should provide a **non-default** path to enable new capabilities for users/developers who are interested in what Relax brings, so it will not break the current default Relay flow.
- **Minimize complexity:** This upstreaming should reuse existing TVM/Relay infrastructure as much as possible (for example IRModule, runtime Module, TOPI library, etc.) to avoid duplicated effort and code.
Comment on lines +23 to +24
Copy link
Copy Markdown
Contributor

@leandron leandron Aug 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As a project, I think it creates some challenges on how to deal with new features being proposed and being introduced in Relay, by the established set of contributors that were not involved in Relax development.

While it is clear in the RFC that Relay and Relax would share some infrastructure, what I'm taking from this RFC, is that it will only set the core components for Relax, not having feature parity with Relay at this point, nor support in other components such as all runtimes.

How the proposed plan intends to deal with such new features being added in Relay, while the intention here it to - at some point - replace Relay with Relax?


Note:
- Acceptance of this RFC doesn't mean there is an agreement to eventually deprecate Relay and replace it with Relax. It only permits bringing the development that's currently occurring on the Relax fork into the TVM repo. This will improve the accessibility of that important work for community stakeholders who rely on it, as well as bring Relax under TVM project governance.

- If at a later stage it's found that individual features from Relax are desired in the Relay compiler (e.g. dynamic shapes, TVMScript support), design discussions and RFCs must take place to determine the best way to implement those features. Acceptance of this RFC gives no preference to Relax as the solution, and so evolving Relay would remain firmly on the table in those discussions.

This initial upstreaming will open the path for TVM Unity, and incrementally bring Relax into the community.

# 3. **Guide-level explanation**
Expand Down