-
Notifications
You must be signed in to change notification settings - Fork 25.7k
[ROCm] allow user to override PYTORCH_ROCM_ARCH #60602
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.
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
Conversation
Restores the ability of a user to call .jenkins/pytorch/build.sh while also setting PYTORCH_ROCM_ARCH. Otherwise, with IN_CI=1 as the new default, it will forcibly ignore user settings when build.sh is used outside of CI.
💊 CI failures summary and remediationsAs of commit 6e3a9e4 (more details on the Dr. CI page and at hud.pytorch.org/pr/60602):
1 failure not recognized by patterns:
Preview docs built from this PR This comment was automatically generated by Dr. CI (expand for details).Follow this link to opt-out of these comments for your Pull Requests.Please report bugs/suggestions to the (internal) Dr. CI Users group. |
|
CC @jithunnair-amd for awareness. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Otherwise looks good to me!
| if [[ -n "$IN_CI" && -z "$PYTORCH_ROCM_ARCH" ]]; then | ||
| # Set ROCM_ARCH to gfx900 and gfx906 for CI builds, if user doesn't override. | ||
| echo "Limiting PYTORCH_ROCM_ARCH to gfx90[06] for CI builds" | ||
| export PYTORCH_ROCM_ARCH="gfx900;gfx906" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So I notice you use PYTORCH_ROCM_ARCH as a conditional, but then also reset it to something else. Would that ever be confusing as the user might not be expecting their input to be immediately overridden?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IN_CI is now always 1. It is testing for non-zero length string, so always true. Then I'm testing for zero-length, meaning the user has not explicitly set PYTORCH_ROCM_ARCH, therefore CI job should override as it did before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IN_CI=1 change was made in 510334f.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What lead me to submit this PR was indeed because I had export PYTORCH_ROCM_ARCH=gfx908 and the build.sh script was overriding what I wanted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah sorry I misread the -z
|
@janeyx99 any chance you could finish the review and land, if approved? |
|
@janeyx99 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
|
Ah my bad--forgot to import it! Thanks for the ping |
Summary: Restores the ability of a user to call .jenkins/pytorch/build.sh while also setting PYTORCH_ROCM_ARCH. Otherwise, with IN_CI=1 as the new default, it will forcibly ignore user settings when build.sh is used outside of CI. Pull Request resolved: pytorch#60602 Reviewed By: samestep Differential Revision: D29490791 Pulled By: janeyx99 fbshipit-source-id: b5e8a529b8e0b5020b260b4bf027a37e0c1df8d5
Restores the ability of a user to call .jenkins/pytorch/build.sh while
also setting PYTORCH_ROCM_ARCH. Otherwise, with IN_CI=1 as the new
default, it will forcibly ignore user settings when build.sh is used
outside of CI.