Disable meta device tests. #74468
Closed
Disable meta device tests. #74468
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyang@fb.com> [ghstack-poisoned]
CI Flow Status⚛️ CI FlowRuleset - Version:
|
🔗 Helpful links
💊 CI failures summary and remediationsAs of commit 7591a35 (more details on the Dr. CI page): 💚 💚 Looks good so far! There are no failures yet. 💚 💚 This comment was automatically generated by Dr. CI (expand for details).Please report bugs/suggestions to the (internal) Dr. CI Users group. |
|
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyangfb.com> Differential Revision: [D35010278](https://our.internmc.facebook.com/intern/diff/D35010278) [ghstack-poisoned]
ezyang
added a commit
that referenced
this pull request
Mar 21, 2022
After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyangfb.com> ghstack-source-id: d0ea3286614051007c612f1f174d1715a0a5fba3 Pull Request resolved: #74468
|
@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator. |
After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyangfb.com> Differential Revision: [D35010278](https://our.internmc.facebook.com/intern/diff/D35010278) [ghstack-poisoned]
ezyang
added a commit
that referenced
this pull request
Mar 22, 2022
After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyangfb.com> ghstack-source-id: 2442622f1e27092d7f55295208c64755435e3501 Pull Request resolved: #74468
mruberry
approved these changes
Mar 22, 2022
|
@pytorchbot merge this |
|
Hey @ezyang. |
ezyang
added
release notes: composability
|
Just catching up with this PR. Thanks a lot for making the change @ezyang! Porting remaining ops to structured kernels definitely sounds more appealing now :) |
shahofblah
pushed a commit
that referenced
this pull request
Mar 25, 2022
After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyangfb.com> Pull Request resolved: #74468 Approved by: https://github.com/mruberry
facebook-github-bot
pushed a commit
that referenced
this pull request
Mar 29, 2022
Summary: After discussion with Can Balioglu, we have concluded that #53682 , while clever, is more trouble than it is worth. The main problem is that whenever someone adds support for new meta tensors, they then get dozens of new test case failures, because tests that were previously halted by lack of support for an operator on meta tensors, now have gotten further and hit some logic which expects to be able to, e.g., pull out a real value from a tensor (which clearly doesn't work). This is very annoying and time consuming! Most of these tests aren't written with meta device in mind, and it's not a good use of time to try to make them more generic. The plan on record is to switch meta testing to OpInfo, but that patch will take some time to prepare for now I want to stem the bleeding. I don't think we're at high risk for regressions here because meta tensors mostly share logic with their regular brethren. Signed-off-by: Edward Z. Yang <ezyangfb.com> Pull Request resolved: #74468 Approved by: https://github.com/mruberry Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/65329f4fac8fb22318b7a3eb115e9da207d8d41a Reviewed By: bigfootjon Differential Revision: D35193490 Pulled By: atalman fbshipit-source-id: 6e6bae34c075e60c6a84936f812e178bf88784cd
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack (oldest at bottom):
After discussion with Can Balioglu, we have concluded that
#53682 , while clever, is more
trouble than it is worth. The main problem is that whenever someone
adds support for new meta tensors, they then get dozens of new test case
failures, because tests that were previously halted by lack of support
for an operator on meta tensors, now have gotten further and hit some
logic which expects to be able to, e.g., pull out a real value from a
tensor (which clearly doesn't work). This is very annoying and time
consuming! Most of these tests aren't written with meta device in
mind, and it's not a good use of time to try to make them more generic.
The plan on record is to switch meta testing to OpInfo, but that patch
will take some time to prepare for now I want to stem the bleeding. I
don't think we're at high risk for regressions here because meta tensors
mostly share logic with their regular brethren.
Signed-off-by: Edward Z. Yang ezyang@fb.com
Differential Revision: D35010278