Skip to content

Add Dynamic Output Shape Tag For data-dependent ops, handle in FakeTensor#79170

Closed
eellison wants to merge 4 commits intogh/eellison/307/basefrom
gh/eellison/307/head
Closed

Add Dynamic Output Shape Tag For data-dependent ops, handle in FakeTensor#79170
eellison wants to merge 4 commits intogh/eellison/307/basefrom
gh/eellison/307/head

Conversation

@eellison
Copy link
Contributor

@eellison eellison commented Jun 8, 2022

Stack from ghstack (oldest at bottom):

Adds a tag for operators which have an output whose shape depends on input Tensor data. This tag is tested through the fake_tensor tests. If an operator is not tagged appropriately, the fake tensor test will fallback to cpu to run the operator, and then output metadata will diverge. This helped me find linalg_lstsq among others.

I included in the tags CompositeImplicitAutograd ops, although I'm not sure what the general policy is for these operators.

One difficulty wrt/fake tensors was aten::one_hot. Because it is a CompositeImplicitAutograd, it won't be seen by __torch_dispatch__. It would be possible to handle this case either
a) always throwing with local_scalar_dense, but this would add a huge amount of false negatives where we think operators have data-dependent output shapes but are actually not.
b) Maybe I should also be defining __torch_function__ for fake_tensor to error on specific composites. (this didn't work when I tried it, didn't get invoked, so maybe there's something I'm missing)

Feel free to suggest a different name than dynamic_output_shape.

@facebook-github-bot
Copy link
Contributor

facebook-github-bot commented Jun 8, 2022

🔗 Helpful links

❌ 1 New Failures, 1 Pending

As of commit 90a4bc6 (more details on the Dr. CI page):

Expand to see more
  • 1/1 failures introduced in this PR

🕵️ 1 new failure recognized by patterns

The following CI failures do not appear to be due to upstream breakages

See GitHub Actions build pull / linux-xenial-cuda11.3-py3.7-gcc7 / test (default, 1, 4, linux.4xlarge.nvidia.gpu) (1/1)

Step: "Test" (full log | diagnosis details | 🔁 rerun)

2022-06-09T23:01:19.1189301Z AssertionError: Th...or special.entr on device type cuda are incorrect!
2022-06-09T23:01:19.1180504Z   File "/opt/conda/lib/python3.7/site-packages/torch/testing/_internal/common_device_type.py", line 377, in instantiated_test
2022-06-09T23:01:19.1181385Z     result = test(self, **param_kwargs)
2022-06-09T23:01:19.1182499Z   File "/opt/conda/lib/python3.7/site-packages/torch/testing/_internal/common_device_type.py", line 786, in test_wrapper
2022-06-09T23:01:19.1183302Z     return test(*args, **kwargs)
2022-06-09T23:01:19.1184360Z   File "/opt/conda/lib/python3.7/site-packages/torch/testing/_internal/common_device_type.py", line 821, in dep_fn
2022-06-09T23:01:19.1185131Z     return fn(slf, *args, **kwargs)
2022-06-09T23:01:19.1186186Z   File "/opt/conda/lib/python3.7/site-packages/torch/testing/_internal/common_device_type.py", line 979, in only_fn
2022-06-09T23:01:19.1186977Z     return fn(self, *args, **kwargs)
2022-06-09T23:01:19.1187562Z   File "test_ops.py", line 312, in test_dtypes
2022-06-09T23:01:19.1188567Z     self.fail(msg)
2022-06-09T23:01:19.1189301Z AssertionError: The supported dtypes for special.entr on device type cuda are incorrect!
2022-06-09T23:01:19.1190555Z The following dtypes did not work in forward but are listed by the OpInfo: {torch.bool, torch.float32, torch.int8, torch.float64, torch.int16, torch.int32, torch.int64, torch.bfloat16, torch.float16, torch.uint8}.
2022-06-09T23:01:19.1191937Z The following dtypes did not work in backward but are listed by the OpInfo: {torch.float64, torch.bfloat16, torch.float32, torch.float16}.
2022-06-09T23:01:19.1192590Z 
2022-06-09T23:01:19.1192617Z 
2022-06-09T23:01:47.2679227Z   test_dtypes_special_erfcx_cuda (__main__.TestCommonCUDA) ... Some dtypes for special.erfcx on device type cuda are only partially supported!
2022-06-09T23:01:47.2700818Z The following dtypes only worked on some samples during forward: {torch.bool, torch.float32, torch.int8, torch.float64, torch.int16, torch.int32, torch.int64, torch.uint8}.
2022-06-09T23:01:47.2701438Z The following dtypes only worked on some samples during backward: {torch.float64, torch.float32}.
2022-06-09T23:01:47.2701717Z 
2022-06-09T23:01:47.2701822Z ok (28.150s)
2022-06-09T23:20:52.5593788Z ##[error]The action has timed out.

This comment was automatically generated by Dr. CI (expand for details).

Please report bugs/suggestions to the (internal) Dr. CI Users group.

Click here to manually regenerate this comment.

@eellison eellison changed the title Add Dynamic Output Shape Tagdfor ata-dependent ops, handle in FakeTensor Add Dynamic Output Shape Tag For data-dependent ops, handle in FakeTensor Jun 8, 2022
eellison added a commit that referenced this pull request Jun 9, 2022
@eellison eellison requested a review from ezyang June 9, 2022 00:31


# TODO: use tags when available
# operators whose output shape depends on input tensor data
Copy link
Contributor

Choose a reason for hiding this comment

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

…e in FakeTensor"


Adds a tag for operators which have an output whose shape depends on input Tensor data. This tag is tested through the fake_tensor tests. If an operator is not tagged appropriately, the fake tensor test will fallback to cpu to run the operator, and then output metadata will diverge. This helped me find `linalg_lstsq` among others. 

I included in the tags CompositeImplicitAutograd ops, although I'm not sure what the general policy is for these operators. 

One difficulty wrt/fake tensors was [aten::one_hot](https://codebrowser.bddppq.com/pytorch/pytorch/aten/src/ATen/native/Onehot.cpp.html#23). Because it is a `CompositeImplicitAutograd`, it won't be seen by `__torch_dispatch__`. It would be possible to handle this case either 
a) always throwing with `local_scalar_dense`, but this would add a huge amount of false negatives where we think operators have data-dependent output shapes but are actually not. 
b) Maybe I should also be defining `__torch_function__`  for fake_tensor to error on specific composites. (this didn't work when I tried it, didn't get invoked, so maybe there's something I'm missing)


Feel free to suggest a different name than `dynamic_output_shape`.


[ghstack-poisoned]
eellison added a commit that referenced this pull request Jun 9, 2022
@eellison
Copy link
Contributor Author

eellison commented Jun 9, 2022

@pytorchbot merge

@pytorchmergebot
Copy link
Collaborator

@pytorchbot successfully started a merge job. Check the current status here

@github-actions
Copy link
Contributor

github-actions bot commented Jun 9, 2022

Hey @eellison.
You've committed this PR, but it does not have both a 'release notes: ...' and 'topics: ...' label. Please add one of each to the PR. The 'release notes: ...' label should represent the part of PyTorch that this PR changes (fx, autograd, distributed, etc) and the 'topics: ...' label should represent the kind of PR it is (not user facing, new feature, bug fix, perf improvement, etc). The list of valid labels can be found here for the 'release notes: ...' and here for the 'topics: ...'.
For changes that are 'topic: not user facing' there is no need for a release notes label.

facebook-github-bot pushed a commit that referenced this pull request Jun 10, 2022
…sor (#79170)

Summary:
Pull Request resolved: #79170

Approved by: https://github.com/ezyang

Test Plan: contbuild & OSS CI, see https://hud.pytorch.org/commit/pytorch/pytorch/13a8867c01dd1191f21139915a8c821fa120cf58

Reviewed By: osalpekar

Differential Revision: D37059412

Pulled By: osalpekar

fbshipit-source-id: ee660b8792a03f1984216810c87f4975e9eac08e
@facebook-github-bot facebook-github-bot deleted the gh/eellison/307/head branch June 13, 2022 14:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants