-
Notifications
You must be signed in to change notification settings - Fork 26.3k
Move VariableImpl functions to AutogradMeta and Variable #15487
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
| virtual void set_requires_grad(bool requires_grad, at::TensorImpl* self_impl) = 0; | ||
| virtual bool requires_grad() const = 0; | ||
| virtual at::Tensor& grad() = 0; | ||
| virtual const at::Tensor& grad() const = 0; |
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.
We add these functions into AutogradMetaInterface, and call them from TensorImpl's corresponding functions, because Variable::Impl will not be overriding those functions anymore (and Variable::Impl will be removed in the next PR).
| if (autograd_meta()) { | ||
| return autograd_meta()->grad(); | ||
| } else { | ||
| AT_ERROR("grad is not implemented for Tensor"); |
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.
This error message is not too accurate now, right?
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.
I feel that it's still correct, because these functions still only work on Variable and not Tensor. A more detailed version might be Cannot call grad on Tensor that doesn't contain autograd metadata, but only Variable contains autograd metadata right now, so the original error message is probably ok
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.
it sounds like it's correct until we actually merge variable and tensor. It's worth thinking about if this error message will naturally go away in that case, or you'll have to do active work to make it go away. In either case, a FixMe should be here; in the later case, it's probably worth filing an issue so you don't forget.
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.
I feel that it might be worthwhile to get rid of set_requires_grad / requires_grad / grad in TensorImpl and move them to Variable class, since people can only call those functions on a Variable anyway.
EDIT: This line https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/core/jit_type.h#L360 accesses tensor.requires_grad() from ATen, so we likely still need to keep set_requires_grad / requires_grad / grad in Tensor/TensorImpl instead of moving them to Variable.
|
I don't quite get the argument: I'm not sure what definition you are using for "pure wrapper class", but we are just talking about functions, not state, and variables already have a bunch of extra functions. |
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.
Just from taking a quick look at this, I think the right thing to do is kind of a split:
- set_requires_grad / requires_grad / grad should go on AutogradMeta; these are mostly just accessors/setters anyway so not a big deal.
- All the other functions should go on Variable. I don't quite get why they need to be on AutogradMeta.
What do you think?
ccb8232 to
4934482
Compare
4934482 to
afdbc59
Compare
| if (autograd_meta()) { | ||
| return autograd_meta()->grad(); | ||
| } else { | ||
| AT_ERROR("grad is not implemented for Tensor"); |
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.
it sounds like it's correct until we actually merge variable and tensor. It's worth thinking about if this error message will naturally go away in that case, or you'll have to do active work to make it go away. In either case, a FixMe should be here; in the later case, it's probably worth filing an issue so you don't forget.
| std::vector<Variable> inputs; | ||
| if (!gradient.has_value()) { | ||
| gradient = make_variable(at::ones_like(data_), /*requires_grad=*/false); | ||
| gradient = make_variable(at::ones_like(data()), /*requires_grad=*/false); |
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.
is this future proofing or is there a semantic change here?
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.
There is actually no semantic change - the old backward function lives in Variable::Impl and we can directly access data_, while the new backward function lives in Variable and we need to use either data() or impl_->data_ to access the underlying Tensor data.
In the next PR (when Variable itself becomes the data tensor), we will use *this instead of data() in this line.
1eb3958 to
b7346bd
Compare
b7346bd to
5bafafb
Compare
…able" This reverts commit 5bafafb.
facebook-github-bot
left a comment
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.
@yf225 has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
facebook-github-bot
left a comment
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.
@yf225 is landing this pull request. If you are a Facebook employee, you can view this diff on Phabricator.
In this PR, we are moving all functions away from
Variable::Impl, in order to get rid ofVariable::Impl(and thedata_Tensor in it) in the next PR. Some of the functions (such asset_requires_grad/requires_grad/grad) will be living inAutogradMetaclass, while others (such asbackward()/rebase_history()/grad_accumulator()/grad_fn()) will be living inVariableclass.This is the 2nd PR mentioned in #13638.