Add MemoryFormat to TensorOptions, but not codegen. #33704
Closed
Conversation
This file contains hidden or 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
This diff adds MemoryFormat field to TensorOptions, and teaches all kernels that take TensorOptions to respect it, but doesn't teach the codegen about it. As such, it is now possible to specify memory_format using TensorOptions syntax, e.g., at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous)) in the C++ API, but there isn't any other user visible effect. The intended end state of this diff stack is to eliminate the explicit MemoryFormat? arguments from native functions, but as this change has BC implications I'd prefer to do it separately. So this starts things off with a non-BC breaking addition to the API. For all internal functions that are not bound by codegen, I switch them to exclusively using TensorOptions (eliminating MemoryFormat); there's only a few, mostly quantized and to(). To keep things screwed down in the short term, it is a HARD ERROR to specify both the explicit MemoryFormat argument as well as TensorOptions. This caught a few errors in my diff where I needed to modify memory format settings and then call code later, esp in empty_like. Signed-off-by: Edward Z. Yang <[email protected]> [ghstack-poisoned]
This was referenced Feb 24, 2020
ezyang
approved these changes
Feb 24, 2020
This diff adds MemoryFormat field to TensorOptions, and teaches all kernels that take TensorOptions to respect it, but doesn't teach the codegen about it. As such, it is now possible to specify memory_format using TensorOptions syntax, e.g., at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous)) in the C++ API, but there isn't any other user visible effect. The intended end state of this diff stack is to eliminate the explicit MemoryFormat? arguments from native functions, but as this change has BC implications I'd prefer to do it separately. So this starts things off with a non-BC breaking addition to the API. For all internal functions that are not bound by codegen, I switch them to exclusively using TensorOptions (eliminating MemoryFormat); there's only a few, mostly quantized and to(). To keep things screwed down in the short term, it is a HARD ERROR to specify both the explicit MemoryFormat argument as well as TensorOptions. This caught a few errors in my diff where I needed to modify memory format settings and then call code later, esp in empty_like. Signed-off-by: Edward Z. Yang <[email protected]> Differential Revision: [D20073356](https://our.internmc.facebook.com/intern/diff/D20073356) [ghstack-poisoned]
💊 CircleCI build failures summary and remediationsAs of commit 7878001 (more details on the Dr. CI page): ✅ None of the build failures appear to be your fault 💚
🚧 1 upstream failure recognized by patterns:These were probably caused by upstream breakages:
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 on the GitHub issue tracker. This comment has been revised 7 times. |
added 3 commits
February 26, 2020 11:35
This diff adds MemoryFormat field to TensorOptions, and teaches all kernels that take TensorOptions to respect it, but doesn't teach the codegen about it. As such, it is now possible to specify memory_format using TensorOptions syntax, e.g., at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous)) in the C++ API, but there isn't any other user visible effect. The intended end state of this diff stack is to eliminate the explicit MemoryFormat? arguments from native functions, but as this change has BC implications I'd prefer to do it separately. So this starts things off with a non-BC breaking addition to the API. For all internal functions that are not bound by codegen, I switch them to exclusively using TensorOptions (eliminating MemoryFormat); there's only a few, mostly quantized and to(). To keep things screwed down in the short term, it is a HARD ERROR to specify both the explicit MemoryFormat argument as well as TensorOptions. This caught a few errors in my diff where I needed to modify memory format settings and then call code later, esp in empty_like. Signed-off-by: Edward Z. Yang <[email protected]> Differential Revision: [D20073356](https://our.internmc.facebook.com/intern/diff/D20073356) [ghstack-poisoned]
This diff adds MemoryFormat field to TensorOptions, and teaches all kernels that take TensorOptions to respect it, but doesn't teach the codegen about it. As such, it is now possible to specify memory_format using TensorOptions syntax, e.g., at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous)) in the C++ API, but there isn't any other user visible effect. The intended end state of this diff stack is to eliminate the explicit MemoryFormat? arguments from native functions, but as this change has BC implications I'd prefer to do it separately. So this starts things off with a non-BC breaking addition to the API. For all internal functions that are not bound by codegen, I switch them to exclusively using TensorOptions (eliminating MemoryFormat); there's only a few, mostly quantized and to(). To keep things screwed down in the short term, it is a HARD ERROR to specify both the explicit MemoryFormat argument as well as TensorOptions. This caught a few errors in my diff where I needed to modify memory format settings and then call code later, esp in empty_like. Signed-off-by: Edward Z. Yang <[email protected]> Differential Revision: [D20073356](https://our.internmc.facebook.com/intern/diff/D20073356) [ghstack-poisoned]
This diff adds MemoryFormat field to TensorOptions, and teaches all kernels that take TensorOptions to respect it, but doesn't teach the codegen about it. As such, it is now possible to specify memory_format using TensorOptions syntax, e.g., at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous)) in the C++ API, but there isn't any other user visible effect. The intended end state of this diff stack is to eliminate the explicit MemoryFormat? arguments from native functions, but as this change has BC implications I'd prefer to do it separately. So this starts things off with a non-BC breaking addition to the API. For all internal functions that are not bound by codegen, I switch them to exclusively using TensorOptions (eliminating MemoryFormat); there's only a few, mostly quantized and to(). To keep things screwed down in the short term, it is a HARD ERROR to specify both the explicit MemoryFormat argument as well as TensorOptions. This caught a few errors in my diff where I needed to modify memory format settings and then call code later, esp in empty_like. Signed-off-by: Edward Z. Yang <[email protected]> Differential Revision: [D20073356](https://our.internmc.facebook.com/intern/diff/D20073356) [ghstack-poisoned]
Contributor
ttumiel
pushed a commit
to ttumiel/pytorch
that referenced
this pull request
Mar 4, 2020
Summary: Pull Request resolved: pytorch#33704 This diff adds MemoryFormat field to TensorOptions, and teaches all kernels that take TensorOptions to respect it, but doesn't teach the codegen about it. As such, it is now possible to specify memory_format using TensorOptions syntax, e.g., at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous)) in the C++ API, but there isn't any other user visible effect. The intended end state of this diff stack is to eliminate the explicit MemoryFormat? arguments from native functions, but as this change has BC implications I'd prefer to do it separately. So this starts things off with a non-BC breaking addition to the API. For all internal functions that are not bound by codegen, I switch them to exclusively using TensorOptions (eliminating MemoryFormat); there's only a few, mostly quantized and to(). To keep things screwed down in the short term, it is a HARD ERROR to specify both the explicit MemoryFormat argument as well as TensorOptions. This caught a few errors in my diff where I needed to modify memory format settings and then call code later, esp in empty_like. Signed-off-by: Edward Z. Yang <[email protected]> Test Plan: Imported from OSS Differential Revision: D20073356 Pulled By: bhosmer fbshipit-source-id: 18d310d7ee7cf2ee182994104652afcfc9d613e2
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:
This diff adds MemoryFormat field to TensorOptions, and teaches
all kernels that take TensorOptions to respect it, but doesn't
teach the codegen about it. As such, it is now possible to specify
memory_format using TensorOptions syntax, e.g.,
at::empty_like(tensor, at::memory_format(MemoryFormat::Contiguous))
in the C++ API, but there isn't any other user visible effect.
The intended end state of this diff stack is to eliminate the
explicit MemoryFormat? arguments from native functions, but
as this change has BC implications I'd prefer to do it separately.
So this starts things off with a non-BC breaking addition to the
API. For all internal functions that are not bound by codegen,
I switch them to exclusively using TensorOptions (eliminating
MemoryFormat); there's only a few, mostly quantized and to().
To keep things screwed down in the short term, it is a HARD ERROR
to specify both the explicit MemoryFormat argument as well as
TensorOptions. This caught a few errors in my diff where I needed
to modify memory format settings and then call code later, esp
in empty_like.
Signed-off-by: Edward Z. Yang [email protected]
Differential Revision: D20073356