Skip to content

[TENSOR MERGE] Delete type_ field from TensorImpl, replaced with backend_/scalar_typ…#9787

Closed
ezyang wants to merge 4 commits intopytorch:masterfrom
ezyang:pr/delete-type-field-from-tensor
Closed

[TENSOR MERGE] Delete type_ field from TensorImpl, replaced with backend_/scalar_typ…#9787
ezyang wants to merge 4 commits intopytorch:masterfrom
ezyang:pr/delete-type-field-from-tensor

Conversation

@ezyang
Copy link
Contributor

@ezyang ezyang commented Jul 24, 2018

…e_/is_variable_

The basic game plan is to stop accessing the type_ field directly,
and instead using the stored backend_, scalar_type_ and
is_variable_ to look up the appropriate Type from Context.
Storage of backend_ and scalar_type_ are new.

At some future point in time, I'd like to look at this code
carefully to see if I can get everything in this codepath inlining.
I didn't do it in this patch because there are circular include
problems making things difficult.

Some other details:

  • Added Device::backend() which does what it says on the tin

  • SparseTensorImpl is temporarily hard-coded to root in at::Context
    for the appropriate context. If/when we put this in shared code,
    we'll have to break this dep too, but for now it should be OK.

  • There's a stupid problem with globalContext() deadlocking if
    you didn't actually initialize it before loading libtorch.so
    (which is bringing along the variable hooks). I didn't fix
    it in this PR; it's tracked in globalContext() deadlock if Context is not initialized before libtorch (variable hooks) is loaded #9784

Signed-off-by: Edward Z. Yang ezyang@fb.com

…e_/is_variable_

The basic game plan is to stop accessing the type_ field directly,
and instead using the stored backend_, scalar_type_ and
is_variable_ to look up the appropriate Type from Context.
Storage of backend_ and scalar_type_ are new.

At some future point in time, I'd like to look at this code
carefully to see if I can get everything in this codepath inlining.
I didn't do it in this patch because there are circular include
problems making things difficult.

Some other details:

- Added Device::backend() which does what it says on the tin

- SparseTensorImpl is temporarily hard-coded to root in at::Context
  for the appropriate context.  If/when we put this in shared code,
  we'll have to break this dep too, but for now it should be OK.

- There's a stupid problem with globalContext() deadlocking if
  you didn't actually initialize it before loading libtorch.so
  (which is bringing along the variable hooks).  I didn't fix
  it in this PR; it's tracked in pytorch#9784

Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

@ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

@ezyang
Copy link
Contributor Author

ezyang commented Jul 24, 2018

@pytorchbot retest this please

1 similar comment
@ezyang
Copy link
Contributor Author

ezyang commented Jul 25, 2018

@pytorchbot retest this please

return type_ == Type::CPU;
}

Backend backend() const {

This comment was marked as off-topic.

}

at::Backend backend() const {
return storage_->data_ptr.device().backend();

This comment was marked as off-topic.

Copy link
Contributor

@facebook-github-bot facebook-github-bot left a comment

Choose a reason for hiding this comment

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

ezyang has imported this pull request. If you are a Facebook employee, you can view this diff on Phabricator.

zdevito pushed a commit to zdevito/ATen that referenced this pull request Aug 1, 2018
…… (#9787)

Summary:
…e_/is_variable_

The basic game plan is to stop accessing the type_ field directly,
and instead using the stored backend_, scalar_type_ and
is_variable_ to look up the appropriate Type from Context.
Storage of backend_ and scalar_type_ are new.

At some future point in time, I'd like to look at this code
carefully to see if I can get everything in this codepath inlining.
I didn't do it in this patch because there are circular include
problems making things difficult.

Some other details:

- Added Device::backend() which does what it says on the tin

- SparseTensorImpl is temporarily hard-coded to root in at::Context
  for the appropriate context.  If/when we put this in shared code,
  we'll have to break this dep too, but for now it should be OK.

- There's a stupid problem with globalContext() deadlocking if
  you didn't actually initialize it before loading libtorch.so
  (which is bringing along the variable hooks).  I didn't fix
  it in this PR; it's tracked in #9784

Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Pull Request resolved: pytorch/pytorch#9787

Reviewed By: cpuhrsch

Differential Revision: D8980971

Pulled By: ezyang

fbshipit-source-id: 2b4d867abfdc3999a836a220c638c109053145a8
goodlux pushed a commit to goodlux/pytorch that referenced this pull request Aug 15, 2018
pytorch#9787)

Summary:
…e_/is_variable_

The basic game plan is to stop accessing the type_ field directly,
and instead using the stored backend_, scalar_type_ and
is_variable_ to look up the appropriate Type from Context.
Storage of backend_ and scalar_type_ are new.

At some future point in time, I'd like to look at this code
carefully to see if I can get everything in this codepath inlining.
I didn't do it in this patch because there are circular include
problems making things difficult.

Some other details:

- Added Device::backend() which does what it says on the tin

- SparseTensorImpl is temporarily hard-coded to root in at::Context
  for the appropriate context.  If/when we put this in shared code,
  we'll have to break this dep too, but for now it should be OK.

- There's a stupid problem with globalContext() deadlocking if
  you didn't actually initialize it before loading libtorch.so
  (which is bringing along the variable hooks).  I didn't fix
  it in this PR; it's tracked in pytorch#9784

Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Pull Request resolved: pytorch#9787

Reviewed By: cpuhrsch

Differential Revision: D8980971

Pulled By: ezyang

fbshipit-source-id: 2b4d867abfdc3999a836a220c638c109053145a8
@ezyang ezyang added the merged label Jun 26, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants