2022-03-24 14:24:30 +00:00
|
|
|
# Owner(s): ["module: __torch_dispatch__"]
|
2021-10-29 19:15:30 +00:00
|
|
|
|
2022-02-24 15:59:39 +00:00
|
|
|
import tempfile
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
import torch
|
2022-02-24 15:59:39 +00:00
|
|
|
from copy import deepcopy
|
Support registering op returning symint in python (#95240)
Running an operator registered in python returning a symint will result in the following error:
```
RuntimeError: Unable to cast Python instance of type <class 'torch.SymInt'> to C++ type 'long'
```
The interaction of 2 things make the issue being triggered:
- We use boxed kernel here. For boxed kernel, we need convert py::object to IValue in torch/csrc/autograd/python_variable.cpp pushPyOutToStack .
- In the schema parsing code in torch/csrc/jit/frontend/schema_type_parser.cpp SchemaTypeParser::parseFakeAndRealType , if a SymInt is found, we register a Int type instead (not sure why we do this), and register SymInt as the real type.
The result is we would convert an SymInt to int in pushPyOutToStack and cause the issue.
The fix is to use real type when we convert py::object to IValue.
BTW, registering the same op using C++ API does not trigger the issue.
```
TORCH_LIBRARY(clib, m) {
m.def("sqsum(SymInt a, SymInt b) -> SymInt", [](SymInt a, SymInt b) -> SymInt {
return a * a + b * b;
});
}
```
The reason is, the kernel registered in C++ is unboxed kernel and it does not trigger the code path above that converts an py::object to IValue.
Pull Request resolved: https://github.com/pytorch/pytorch/pull/95240
Approved by: https://github.com/larryliu0820, https://github.com/ezyang
2023-02-22 04:56:37 +00:00
|
|
|
from torch.library import Library, impl
|
|
|
|
|
from torch.fx.experimental.proxy_tensor import ShapeEnv
|
|
|
|
|
from torch import SymInt
|
|
|
|
|
from torch._subclasses.fake_tensor import FakeTensorMode
|
Jiterator with Python Registration (#77121)
You can now do a lot of crazy things about redefining the behavior of an operator, and still be fast in cuda !!!
Example 1: swapping where's branches
```
code_string = "template <typename T> T inverted_where(bool cond, T a, T b){ return !cond ? a : b; }"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::where.self', jitted_fn, "CUDA")
# torch.where is now overridden
```
Example 2: approximate gelu with relu
```
code_string = "template <typename T> T fast_gelu(T a){ return a > 0 ? a : 0;}"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::gelu', jitted_fn, "CUDA")
# torch.nn.GELU and torch.nn.function.gelu are now overridden
```
Example 3: clipping output for numerical unstable kernels
```
code_string = "template <typename T> T clipped_exp(T a){ return a > T(10.0) ? T(22026.4657948) : exp(a); }"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::exp', jitted_fn, "CUDA")
# torch.exp(x) and x.exp() are now overridden
```
Example 4: Simulate buggy hardware behaviors
```
code_string = "template <typename T> T buggy_add(T a, T b){ return a + b + T(1); }"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::add.Tensor', jitted_fn, "CUDA")
torch.add(x, y), "x + y" and x.add(y) are now overridden
```
Pull Request resolved: https://github.com/pytorch/pytorch/pull/77121
Approved by: https://github.com/anjali411
2022-05-10 20:54:23 +00:00
|
|
|
from torch.cuda.jiterator import _create_jit_fn
|
2022-05-19 17:35:06 +00:00
|
|
|
import unittest
|
2023-04-18 13:51:23 +00:00
|
|
|
from torch.testing._internal.common_utils import TestCase, run_tests, TEST_WITH_ROCM, IS_WINDOWS, TEST_CUDA
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
from torch.utils._mode_utils import no_dispatch, all_same_mode
|
2022-04-20 14:01:17 +00:00
|
|
|
from torch.testing._internal.logging_tensor import LoggingTensor, LoggingTensorReentrant, LoggingTensorMode, \
|
2022-05-31 14:02:17 +00:00
|
|
|
log_input, capture_logs, capture_logs_with_logging_tensor_mode
|
2022-08-16 03:03:12 +00:00
|
|
|
from torch.utils._pytree import tree_map, tree_map_only
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
from torch.utils._python_dispatch import TorchDispatchMode, _get_current_dispatch_mode, _get_current_dispatch_mode_stack
|
2023-04-18 13:51:23 +00:00
|
|
|
from torch._custom_op import custom_op, CustomOp
|
|
|
|
|
from torch.fx.experimental.proxy_tensor import make_fx
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
import typing
|
2023-05-15 18:15:08 +00:00
|
|
|
from typing import Optional, Tuple, Union, List, Callable
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
from torch import Tensor
|
|
|
|
|
import itertools
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
|
2021-08-12 18:39:31 +00:00
|
|
|
import logging
|
2023-04-18 13:51:23 +00:00
|
|
|
import sys
|
2023-04-27 21:27:52 +00:00
|
|
|
import torch._dynamo
|
|
|
|
|
import torch.testing._internal.custom_op_db
|
|
|
|
|
import re
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
class TestDispatcherPythonBindings(TestCase):
|
|
|
|
|
def test_call_boxed(self) -> None:
|
|
|
|
|
sin = torch._C._dispatch_find_schema_or_throw("aten::sin", "")
|
|
|
|
|
x = torch.randn(3)
|
|
|
|
|
y = torch._C._dispatch_call_boxed(sin, x)
|
|
|
|
|
self.assertEqual(y, x.sin())
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
|
2022-06-10 03:02:28 +00:00
|
|
|
|
2022-05-04 21:51:09 +00:00
|
|
|
class TestPythonRegistration(TestCase):
|
|
|
|
|
def test_override_aten_ops_with_multiple_libraries(self) -> None:
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
my_lib1 = Library("aten", "IMPL")
|
|
|
|
|
my_lib2 = Library("aten", "IMPL")
|
|
|
|
|
|
|
|
|
|
# Example 1
|
|
|
|
|
def my_neg(*args, **kwargs):
|
|
|
|
|
return args[0]._neg_view()
|
|
|
|
|
|
|
|
|
|
# Now we are secretly making the operator a view op so autograd needs to know how
|
|
|
|
|
# to handle it
|
|
|
|
|
my_lib1.impl('neg', my_neg, "AutogradCPU")
|
|
|
|
|
|
|
|
|
|
self.assertTrue(torch.neg(x).is_neg())
|
|
|
|
|
|
|
|
|
|
# RuntimeError: impl("aten::neg", ...):
|
|
|
|
|
# Explicitly provided namespace (aten) in operator name does not match ...
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, "operator name does not match namespace"):
|
2022-06-02 14:37:02 +00:00
|
|
|
my_lib3 = Library("foo", "DEF")
|
|
|
|
|
my_lib3.define("neg(Tensor self) -> Tensor")
|
2022-05-04 21:51:09 +00:00
|
|
|
my_lib3.impl(torch.ops.aten.neg.default, my_neg, "AutogradCPU")
|
|
|
|
|
del my_lib3
|
|
|
|
|
|
|
|
|
|
# Example 2
|
|
|
|
|
def my_mul(*args, **kwargs):
|
|
|
|
|
return torch.zeros_like(args[0])
|
|
|
|
|
|
|
|
|
|
# torch.ops.aten.mul.Tensor
|
|
|
|
|
my_lib2.impl("aten::mul.Tensor", my_mul, "ZeroTensor")
|
|
|
|
|
|
|
|
|
|
y = torch._efficientzerotensor(2)
|
|
|
|
|
self.assertFalse(torch.mul(x, y)._is_zerotensor())
|
|
|
|
|
|
|
|
|
|
# Assert that a user can't override the behavior of a (ns, op, dispatch_key)
|
|
|
|
|
# combination if someone overrided the behavior for the same before them
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'already a kernel registered from python'):
|
|
|
|
|
my_lib2.impl(torch.ops.aten.mul.Tensor, my_mul, "ZeroTensor")
|
|
|
|
|
|
|
|
|
|
del my_lib1
|
|
|
|
|
|
|
|
|
|
# Validate that lib2 is not affected by removing lib1
|
|
|
|
|
self.assertFalse(torch.mul(x, y)._is_zerotensor())
|
|
|
|
|
|
|
|
|
|
del my_lib2
|
|
|
|
|
|
|
|
|
|
# Validate that the old behavior is restored for neg and mul
|
|
|
|
|
self.assertFalse(torch.neg(x).is_neg())
|
|
|
|
|
self.assertTrue(torch.mul(x, y)._is_zerotensor())
|
|
|
|
|
|
2022-06-02 14:37:02 +00:00
|
|
|
def test_error_if_fn_not_callable(self):
|
|
|
|
|
with self.assertRaisesRegex(TypeError, "Input function is required to be a callable"):
|
|
|
|
|
my_lib = Library("aten", "IMPL")
|
|
|
|
|
my_lib.impl(torch.ops.aten.neg.default, [], "AutogradCPU")
|
|
|
|
|
|
2022-05-04 21:51:09 +00:00
|
|
|
def test_override_cpu_sum(self) -> None:
|
|
|
|
|
# Example 1
|
|
|
|
|
run = [False]
|
|
|
|
|
|
|
|
|
|
def my_sum(*args, **kwargs):
|
|
|
|
|
run[0] = True
|
2023-04-07 18:26:35 +00:00
|
|
|
return args[0].clone()
|
2022-05-04 21:51:09 +00:00
|
|
|
|
|
|
|
|
my_lib1 = Library("aten", "IMPL")
|
|
|
|
|
my_lib1.impl('aten::sum', my_sum, "CPU")
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
self.assertEqual(torch.sum(x), x)
|
|
|
|
|
self.assertTrue(run[0])
|
|
|
|
|
del my_lib1
|
|
|
|
|
# Validate that the old behavior is restored for sum
|
|
|
|
|
self.assertEqual(torch.sum(x), torch.tensor(3))
|
|
|
|
|
|
Jiterator with Python Registration (#77121)
You can now do a lot of crazy things about redefining the behavior of an operator, and still be fast in cuda !!!
Example 1: swapping where's branches
```
code_string = "template <typename T> T inverted_where(bool cond, T a, T b){ return !cond ? a : b; }"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::where.self', jitted_fn, "CUDA")
# torch.where is now overridden
```
Example 2: approximate gelu with relu
```
code_string = "template <typename T> T fast_gelu(T a){ return a > 0 ? a : 0;}"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::gelu', jitted_fn, "CUDA")
# torch.nn.GELU and torch.nn.function.gelu are now overridden
```
Example 3: clipping output for numerical unstable kernels
```
code_string = "template <typename T> T clipped_exp(T a){ return a > T(10.0) ? T(22026.4657948) : exp(a); }"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::exp', jitted_fn, "CUDA")
# torch.exp(x) and x.exp() are now overridden
```
Example 4: Simulate buggy hardware behaviors
```
code_string = "template <typename T> T buggy_add(T a, T b){ return a + b + T(1); }"
jitted_fn = torch.cuda.jiterator._create_jit_fn(code_string)
my_lib = torch.library.Library("aten", "IMPL")
my_lib.impl('aten::add.Tensor', jitted_fn, "CUDA")
torch.add(x, y), "x + y" and x.add(y) are now overridden
```
Pull Request resolved: https://github.com/pytorch/pytorch/pull/77121
Approved by: https://github.com/anjali411
2022-05-10 20:54:23 +00:00
|
|
|
def test_override_cuda_with_jiterator(self) -> None:
|
|
|
|
|
def override_where_cuda() -> None:
|
|
|
|
|
# Example 1: Invert the behavior of where's condition input
|
|
|
|
|
not_where_code_string = '''
|
|
|
|
|
template <typename T> T inverted_where(bool cond, T a, T b){
|
|
|
|
|
return !cond ? a : b;
|
|
|
|
|
}
|
|
|
|
|
'''
|
|
|
|
|
jitted_where = _create_jit_fn(not_where_code_string)
|
|
|
|
|
|
|
|
|
|
CALLED = [False]
|
|
|
|
|
|
|
|
|
|
def inverted_where(*args, **kwargs):
|
|
|
|
|
CALLED[0] = True
|
|
|
|
|
return jitted_where(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
# overriding where's cuda kernel with Jiterator generated kernel
|
|
|
|
|
my_lib = Library("aten", "IMPL")
|
|
|
|
|
my_lib.impl('aten::where.self', inverted_where, "CUDA")
|
|
|
|
|
|
|
|
|
|
device = 'cuda'
|
|
|
|
|
cond = torch.tensor([True, True, False], device=device, dtype=torch.bool)
|
|
|
|
|
x = torch.tensor([1, 2, 3], device=device)
|
|
|
|
|
y = torch.tensor([-1, -2, -3], device=device)
|
|
|
|
|
|
|
|
|
|
self.assertEqual(torch.where(cond, x, y), torch.tensor([-1, -2, 3]))
|
|
|
|
|
self.assertTrue(CALLED[0])
|
|
|
|
|
del my_lib
|
|
|
|
|
|
|
|
|
|
# behavior restored after deregistration
|
|
|
|
|
self.assertEqual(torch.where(cond, x, y), torch.tensor([1, 2, -3]))
|
|
|
|
|
|
|
|
|
|
def override_gelu_cuda() -> None:
|
|
|
|
|
# Example 2: Use relu to approximate gelu for faster compute
|
|
|
|
|
fastest_gelu_code_string = '''
|
|
|
|
|
template <typename T> T fast_gelu(T a){
|
|
|
|
|
return a > 0 ? a : 0;
|
|
|
|
|
}
|
|
|
|
|
'''
|
|
|
|
|
jitted_gelu = _create_jit_fn(fastest_gelu_code_string)
|
|
|
|
|
|
|
|
|
|
CALLED = [False]
|
|
|
|
|
|
|
|
|
|
def fast_gelu(*args, **kwargs):
|
|
|
|
|
CALLED[0] = True
|
|
|
|
|
return jitted_gelu(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
# overriding gelu's cuda kernel with Jiterator generated relu kernel
|
|
|
|
|
my_lib = Library("aten", "IMPL")
|
|
|
|
|
my_lib.impl('aten::gelu', fast_gelu, "CUDA")
|
|
|
|
|
|
|
|
|
|
x = torch.rand([3, 3], device='cuda', dtype=torch.float)
|
|
|
|
|
self.assertEqual(torch.nn.functional.gelu(x), torch.nn.functional.relu(x))
|
|
|
|
|
self.assertTrue(CALLED[0])
|
|
|
|
|
del my_lib
|
|
|
|
|
|
|
|
|
|
# behavior restored after deregistration
|
|
|
|
|
self.assertNotEqual(torch.nn.functional.gelu(x), torch.nn.functional.relu(x))
|
|
|
|
|
|
|
|
|
|
def override_exp_cuda() -> None:
|
|
|
|
|
# Example 3: Preventing exp from exploding for float16
|
|
|
|
|
clipped_exp_code_string = '''
|
|
|
|
|
template <typename T> T clipped_exp(T a){
|
|
|
|
|
return a > T(10.0) ? T(22026.4657948) : exp(a);
|
|
|
|
|
}
|
|
|
|
|
'''
|
|
|
|
|
jitted_exp = _create_jit_fn(clipped_exp_code_string)
|
|
|
|
|
|
|
|
|
|
CALLED = [False]
|
|
|
|
|
|
|
|
|
|
def clipped_exp(*args, **kwargs):
|
|
|
|
|
CALLED[0] = True
|
|
|
|
|
return jitted_exp(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
# overriding exp's cuda kernel with clipped_exp kernel
|
|
|
|
|
my_lib = Library("aten", "IMPL")
|
|
|
|
|
my_lib.impl('aten::exp', clipped_exp, "CUDA")
|
|
|
|
|
|
|
|
|
|
x = torch.tensor([0.0, 100.0], device='cuda', dtype=torch.float16)
|
|
|
|
|
self.assertEqual(torch.exp(x), torch.tensor([1.0, 22026.4657948], dtype=torch.float16))
|
|
|
|
|
self.assertTrue(CALLED[0])
|
|
|
|
|
del my_lib
|
|
|
|
|
|
|
|
|
|
# behavior restored after deregistration
|
|
|
|
|
self.assertEqual(torch.exp(x), torch.tensor([1.0, torch.inf], dtype=torch.float16))
|
|
|
|
|
|
|
|
|
|
def override_add_cuda() -> None:
|
|
|
|
|
# Example 4: simulate a hardware bug, where the adder is always off by 1
|
|
|
|
|
buggy_add_code_string = '''
|
|
|
|
|
template <typename T> T buggy_add(T a, T b){
|
|
|
|
|
return a + b + T(1);
|
|
|
|
|
}
|
|
|
|
|
'''
|
|
|
|
|
jitted_add = _create_jit_fn(buggy_add_code_string)
|
|
|
|
|
|
|
|
|
|
CALLED = [False]
|
|
|
|
|
|
|
|
|
|
def buggy_add(*args, **kwargs):
|
|
|
|
|
CALLED[0] = True
|
|
|
|
|
return jitted_add(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
my_lib = Library("aten", "IMPL")
|
|
|
|
|
my_lib.impl('aten::add.Tensor', buggy_add, "CUDA")
|
|
|
|
|
|
|
|
|
|
x_cpu = torch.rand([3, 3], device='cpu')
|
|
|
|
|
y_cpu = torch.rand([3], device='cpu')
|
|
|
|
|
|
|
|
|
|
x_cuda = x_cpu.cuda()
|
|
|
|
|
y_cuda = y_cpu.cuda()
|
|
|
|
|
|
|
|
|
|
self.assertEqual(x_cuda + y_cuda, x_cpu + y_cpu + 1)
|
|
|
|
|
self.assertTrue(CALLED[0])
|
|
|
|
|
del my_lib
|
|
|
|
|
|
|
|
|
|
# behavior restored after deregistration
|
|
|
|
|
self.assertEqual(x_cuda + y_cuda, x_cpu + y_cpu)
|
|
|
|
|
|
|
|
|
|
if torch.cuda.is_available() and not TEST_WITH_ROCM:
|
|
|
|
|
override_where_cuda()
|
|
|
|
|
override_gelu_cuda()
|
|
|
|
|
override_exp_cuda()
|
|
|
|
|
override_add_cuda()
|
|
|
|
|
|
2022-05-04 21:51:09 +00:00
|
|
|
def test_extend_library_with_dispatch_key_arg(self):
|
|
|
|
|
def my_sum(*args, **kwargs):
|
2023-04-07 18:26:35 +00:00
|
|
|
return args[0].clone()
|
2022-05-04 21:51:09 +00:00
|
|
|
my_lib1 = Library("aten", "IMPL", dispatch_key="CPU")
|
|
|
|
|
|
|
|
|
|
# RuntimeError: Explicitly provided dispatch key (Conjugate) is
|
|
|
|
|
# inconsistent with the dispatch key of the enclosing TORCH_LIBRARY_IMPL block
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, "inconsistent with the dispatch key"):
|
|
|
|
|
my_lib1.impl('sum', my_sum, "Conjugate")
|
|
|
|
|
my_lib1.impl('aten::sum', my_sum)
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
self.assertEqual(torch.sum(x), x)
|
|
|
|
|
del my_lib1
|
|
|
|
|
|
2022-05-04 21:51:09 +00:00
|
|
|
def test_create_new_library(self) -> None:
|
|
|
|
|
my_lib1 = Library("foo", "DEF")
|
|
|
|
|
|
2022-05-10 15:54:54 +00:00
|
|
|
my_lib1.define("sum(Tensor self) -> Tensor")
|
|
|
|
|
|
2022-05-04 21:51:09 +00:00
|
|
|
# Example 1
|
2022-05-10 15:54:54 +00:00
|
|
|
@torch.library.impl(my_lib1, "sum", "CPU")
|
2022-05-04 21:51:09 +00:00
|
|
|
def my_sum(*args, **kwargs):
|
2023-04-07 18:26:35 +00:00
|
|
|
return args[0].clone()
|
2022-05-04 21:51:09 +00:00
|
|
|
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
self.assertEqual(torch.ops.foo.sum(x), x)
|
|
|
|
|
|
|
|
|
|
my_lib2 = Library("foo", "IMPL")
|
|
|
|
|
|
|
|
|
|
# Example 2
|
2022-05-10 15:54:54 +00:00
|
|
|
@torch.library.impl(my_lib2, torch.ops.foo.sum.default, "ZeroTensor")
|
2022-05-04 21:51:09 +00:00
|
|
|
def my_sum_zt(*args, **kwargs):
|
|
|
|
|
if args[0]._is_zerotensor():
|
|
|
|
|
return torch._efficientzerotensor(args[0].shape)
|
|
|
|
|
else:
|
2023-04-07 18:26:35 +00:00
|
|
|
return args[0].clone()
|
2022-05-04 21:51:09 +00:00
|
|
|
|
|
|
|
|
y = torch._efficientzerotensor(3)
|
|
|
|
|
self.assertTrue(torch.ops.foo.sum(y)._is_zerotensor())
|
|
|
|
|
self.assertEqual(torch.ops.foo.sum(x), x)
|
|
|
|
|
|
|
|
|
|
del my_lib2
|
|
|
|
|
del my_lib1
|
|
|
|
|
|
2023-04-07 18:26:35 +00:00
|
|
|
def test_create_new_library_fragment_no_existing(self):
|
|
|
|
|
my_lib = Library("foo", "FRAGMENT")
|
|
|
|
|
|
|
|
|
|
my_lib.define("sum2(Tensor self) -> Tensor")
|
|
|
|
|
|
|
|
|
|
@torch.library.impl(my_lib, "sum2", "CPU")
|
|
|
|
|
def my_sum(*args, **kwargs):
|
|
|
|
|
return args[0]
|
|
|
|
|
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
self.assertEqual(torch.ops.foo.sum2(x), x)
|
|
|
|
|
|
|
|
|
|
del my_lib
|
|
|
|
|
|
|
|
|
|
def test_create_new_library_fragment_with_existing(self):
|
|
|
|
|
my_lib1 = Library("foo", "DEF")
|
|
|
|
|
|
|
|
|
|
# Create a fragment
|
|
|
|
|
my_lib2 = Library("foo", "FRAGMENT")
|
|
|
|
|
|
|
|
|
|
my_lib2.define("sum4(Tensor self) -> Tensor")
|
|
|
|
|
|
|
|
|
|
@torch.library.impl(my_lib2, "sum4", "CPU")
|
|
|
|
|
def my_sum4(*args, **kwargs):
|
|
|
|
|
return args[0]
|
|
|
|
|
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
self.assertEqual(torch.ops.foo.sum4(x), x)
|
|
|
|
|
|
|
|
|
|
# Create another fragment
|
|
|
|
|
my_lib3 = Library("foo", "FRAGMENT")
|
|
|
|
|
|
|
|
|
|
my_lib3.define("sum3(Tensor self) -> Tensor")
|
|
|
|
|
|
|
|
|
|
@torch.library.impl(my_lib3, "sum3", "CPU")
|
|
|
|
|
def my_sum3(*args, **kwargs):
|
|
|
|
|
return args[0]
|
|
|
|
|
|
|
|
|
|
x = torch.tensor([1, 2])
|
|
|
|
|
self.assertEqual(torch.ops.foo.sum3(x), x)
|
|
|
|
|
|
|
|
|
|
del my_lib1
|
|
|
|
|
del my_lib2
|
|
|
|
|
del my_lib3
|
|
|
|
|
|
2022-05-19 17:35:06 +00:00
|
|
|
@unittest.skipIf(IS_WINDOWS, "Skipped under Windows")
|
|
|
|
|
def test_alias_analysis(self):
|
|
|
|
|
def test_helper(alias_analysis=""):
|
|
|
|
|
my_lib1 = Library("foo", "DEF")
|
|
|
|
|
|
|
|
|
|
called = [0]
|
|
|
|
|
|
|
|
|
|
@torch.library.define(my_lib1, "_op() -> None", alias_analysis=alias_analysis)
|
|
|
|
|
def _op(*args, **kwargs):
|
|
|
|
|
called[0] += 1
|
|
|
|
|
|
|
|
|
|
@torch.jit.script
|
|
|
|
|
def _test():
|
|
|
|
|
torch.ops.foo._op()
|
|
|
|
|
|
|
|
|
|
assert "foo::_op" in str(_test.graph)
|
|
|
|
|
|
|
|
|
|
with self.assertRaises(AssertionError):
|
|
|
|
|
test_helper("") # alias_analysis="FROM_SCHEMA"
|
|
|
|
|
|
|
|
|
|
test_helper("CONSERVATIVE")
|
|
|
|
|
|
2022-07-05 21:49:29 +00:00
|
|
|
def test_error_for_unsupported_ns_or_kind(self) -> None:
|
|
|
|
|
with self.assertRaisesRegex(ValueError, "Unsupported kind"):
|
|
|
|
|
my_lib1 = Library("myns", "BLA")
|
|
|
|
|
|
2023-04-07 18:26:35 +00:00
|
|
|
for kind in ('DEF', 'FRAGMENT'):
|
|
|
|
|
with self.assertRaisesRegex(ValueError, "reserved namespace"):
|
|
|
|
|
my_lib1 = Library("prim", kind)
|
2022-06-10 03:02:28 +00:00
|
|
|
|
Support registering op returning symint in python (#95240)
Running an operator registered in python returning a symint will result in the following error:
```
RuntimeError: Unable to cast Python instance of type <class 'torch.SymInt'> to C++ type 'long'
```
The interaction of 2 things make the issue being triggered:
- We use boxed kernel here. For boxed kernel, we need convert py::object to IValue in torch/csrc/autograd/python_variable.cpp pushPyOutToStack .
- In the schema parsing code in torch/csrc/jit/frontend/schema_type_parser.cpp SchemaTypeParser::parseFakeAndRealType , if a SymInt is found, we register a Int type instead (not sure why we do this), and register SymInt as the real type.
The result is we would convert an SymInt to int in pushPyOutToStack and cause the issue.
The fix is to use real type when we convert py::object to IValue.
BTW, registering the same op using C++ API does not trigger the issue.
```
TORCH_LIBRARY(clib, m) {
m.def("sqsum(SymInt a, SymInt b) -> SymInt", [](SymInt a, SymInt b) -> SymInt {
return a * a + b * b;
});
}
```
The reason is, the kernel registered in C++ is unboxed kernel and it does not trigger the code path above that converts an py::object to IValue.
Pull Request resolved: https://github.com/pytorch/pytorch/pull/95240
Approved by: https://github.com/larryliu0820, https://github.com/ezyang
2023-02-22 04:56:37 +00:00
|
|
|
def test_returning_symint(self) -> None:
|
|
|
|
|
shape_env = ShapeEnv()
|
|
|
|
|
fake_tensor_mode = FakeTensorMode(shape_env=shape_env)
|
|
|
|
|
|
|
|
|
|
ft = fake_tensor_mode.from_tensor(torch.rand(2, 3))
|
|
|
|
|
|
|
|
|
|
s0, s1 = ft.shape
|
|
|
|
|
|
|
|
|
|
tlib = Library("tlib", "DEF")
|
|
|
|
|
tlib.define("sqsum(SymInt a, SymInt b) -> SymInt")
|
|
|
|
|
|
|
|
|
|
@impl(tlib, "sqsum", "CompositeExplicitAutograd")
|
|
|
|
|
def sqsum(a: SymInt, b: SymInt):
|
|
|
|
|
return a * a + b * b
|
|
|
|
|
|
|
|
|
|
out = torch.ops.tlib.sqsum.default(s0, s1)
|
|
|
|
|
out_val = shape_env.evaluate_expr(out.node.expr)
|
|
|
|
|
self.assertEquals(out_val, 13)
|
|
|
|
|
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
class TestCustomOp(TestCase):
|
2023-05-15 21:12:23 +00:00
|
|
|
test_ns = '_test_custom_op'
|
|
|
|
|
|
|
|
|
|
def tearDown(self):
|
|
|
|
|
import torch._custom_op
|
|
|
|
|
keys = list(torch._custom_op.global_registry.keys())
|
|
|
|
|
for key in keys:
|
|
|
|
|
if not key.startswith(f'{TestCustomOp.test_ns}::'):
|
|
|
|
|
continue
|
|
|
|
|
torch._custom_op.global_registry[key]._destroy()
|
|
|
|
|
|
2023-04-18 13:51:23 +00:00
|
|
|
def test_invalid_schemas(self):
|
|
|
|
|
# function schmea validation goes through torchgen, so this is just a
|
|
|
|
|
# basic test.
|
|
|
|
|
with self.assertRaisesRegex(AssertionError, 'Invalid function schema: foo'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo', "(")
|
2023-04-18 13:51:23 +00:00
|
|
|
def foo(x):
|
|
|
|
|
...
|
|
|
|
|
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def test_name_must_match(self):
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'to have name'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo', "(Tensor x) -> Tensor")
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def bar(x):
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'to have name'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def baz(x: Tensor) -> Tensor:
|
|
|
|
|
...
|
|
|
|
|
|
2023-04-18 13:51:23 +00:00
|
|
|
def test_unsupported_schemas(self):
|
|
|
|
|
def foo(x):
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'does not support non-functional'):
|
2023-05-15 21:12:23 +00:00
|
|
|
custom_op(f'{TestCustomOp.test_ns}::foo', '(Tensor(a!) x) -> Tensor(a)')(foo)
|
2023-04-18 13:51:23 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'does not support view functions'):
|
2023-05-15 21:12:23 +00:00
|
|
|
custom_op(f'{TestCustomOp.test_ns}::foo', '(Tensor(a) x) -> Tensor(a)')(foo)
|
2023-04-18 13:51:23 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'no outputs'):
|
2023-05-15 21:12:23 +00:00
|
|
|
custom_op(f'{TestCustomOp.test_ns}::foo', '(Tensor x) -> ()')(foo)
|
2023-04-18 13:51:23 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'self'):
|
2023-05-15 21:12:23 +00:00
|
|
|
custom_op(f'{TestCustomOp.test_ns}::foo', '(Tensor self) -> ()')(foo)
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_schema_matches_signature(self):
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'signature to match'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah', '(Tensor y) -> Tensor')
|
2023-04-18 13:51:23 +00:00
|
|
|
def blah(x):
|
|
|
|
|
pass
|
|
|
|
|
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'signature to match'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah2', '(Tensor x, *, Tensor y) -> Tensor')
|
2023-04-18 13:51:23 +00:00
|
|
|
def blah2(x, y):
|
|
|
|
|
pass
|
|
|
|
|
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'signature to match'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah3', '(Tensor x, *, Tensor w, Tensor z) -> Tensor')
|
2023-04-18 13:51:23 +00:00
|
|
|
def blah3(x, *, y, z):
|
|
|
|
|
pass
|
|
|
|
|
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'signature to match'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah4', '(Tensor x, *, Tensor z, Tensor y) -> Tensor')
|
2023-04-18 13:51:23 +00:00
|
|
|
def blah4(x, *, y, z):
|
|
|
|
|
pass
|
|
|
|
|
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
with self.assertRaisesRegex(ValueError, 'not supported'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah5', '(Tensor x) -> Tensor')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def blah5(*args):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'not supported'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah6', '(*, Tensor z, Tensor y) -> Tensor')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def blah6(**kwargs):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'default arguments'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah7', '(Tensor x, *, Tensor y) -> Tensor')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def blah7(x=1, *, y):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'default arguments'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah8', '(Tensor x, *, Tensor y) -> Tensor')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def blah8(x, *, y=1):
|
|
|
|
|
pass
|
|
|
|
|
|
2023-04-18 13:51:23 +00:00
|
|
|
# kwonly-arg works
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::blah9', '(Tensor x, *, Tensor y) -> Tensor')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def blah9(x, *, y):
|
2023-04-18 13:51:23 +00:00
|
|
|
pass
|
|
|
|
|
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def test_unsupported_annotation_categories(self):
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'varargs'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(*args):
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'varkwargs'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(**kwargs):
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'must have a type annotation'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x):
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'default value'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Optional[Tensor] = None):
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'default value'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Optional[Tensor] = None):
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'either Tensor or a Tuple'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor) -> int:
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'either Tensor or a Tuple'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor) -> Tuple[Tensor, int]:
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'either Tensor or a Tuple'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor) -> Tuple[Tensor, ...]:
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
def test_supported_param_types(self):
|
|
|
|
|
def generate_examples(typ):
|
|
|
|
|
if typ is int:
|
|
|
|
|
return [17]
|
|
|
|
|
if typ is float:
|
|
|
|
|
return [3.14]
|
|
|
|
|
if typ is bool:
|
|
|
|
|
return [True]
|
2023-05-05 03:08:40 +00:00
|
|
|
if typ is str:
|
|
|
|
|
return ["foo"]
|
|
|
|
|
if typ is torch.dtype:
|
|
|
|
|
return [torch.float32]
|
|
|
|
|
if typ is torch.device:
|
|
|
|
|
return [torch.device('cpu')]
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
if typ == torch.types.Number:
|
|
|
|
|
return [2.718]
|
|
|
|
|
if typ is torch.Tensor:
|
|
|
|
|
return [torch.tensor(3)]
|
|
|
|
|
if typ == Optional[torch.types.Number]:
|
|
|
|
|
return [None, 2.718]
|
|
|
|
|
origin = typing.get_origin(typ)
|
|
|
|
|
if origin is Union:
|
|
|
|
|
args = typing.get_args(typ)
|
|
|
|
|
assert len(args) == 2 and (args[0] is type(None) or args[1] is type(None))
|
|
|
|
|
elt = args[0] if args[1] is type(None) else args[1]
|
|
|
|
|
return generate_examples(elt) + [None]
|
2023-05-15 18:15:08 +00:00
|
|
|
if origin is tuple:
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
args = typing.get_args(typ)
|
2023-05-15 18:15:08 +00:00
|
|
|
assert len(args) == 2 and args[1] == ...
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
examples = generate_examples(args[0])
|
|
|
|
|
return list(itertools.product(examples, examples)) + []
|
2023-05-05 03:08:40 +00:00
|
|
|
raise AssertionError(f"unsupported param type {typ}")
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
|
|
|
|
|
for typ in torch._custom_op.SUPPORTED_PARAM_TYPES:
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor, y: typ) -> Tensor:
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
yeet = None
|
|
|
|
|
|
|
|
|
|
@foo.impl(['cpu'])
|
|
|
|
|
def foo_cpu(x, y):
|
|
|
|
|
nonlocal yeet
|
|
|
|
|
yeet = y
|
|
|
|
|
return x.clone()
|
|
|
|
|
|
|
|
|
|
try:
|
|
|
|
|
for example in generate_examples(typ):
|
|
|
|
|
foo(torch.randn([]), example)
|
|
|
|
|
self.assertEqual(yeet, example, msg=f'{typ} {example}')
|
|
|
|
|
yeet = None
|
|
|
|
|
finally:
|
|
|
|
|
foo._destroy()
|
|
|
|
|
del foo
|
|
|
|
|
del foo_cpu
|
|
|
|
|
|
|
|
|
|
def test_unsupported_param_types(self):
|
|
|
|
|
# Not comprehensive (it doesn't need to be), just a check that our mechanism works
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'unsupported type'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
2023-05-15 18:15:08 +00:00
|
|
|
def foo(x: Tensor, y: Tuple[Optional[int], ...]) -> Tensor:
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'unsupported type'):
|
|
|
|
|
# int[N] in Dispatcher is a bit wild, so we don't try to support it.
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor, y: Tuple[int, int]) -> Tensor:
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'unsupported type'):
|
|
|
|
|
# We could theoretically support this, but the syntax for suporting
|
2023-05-15 18:15:08 +00:00
|
|
|
# int[] is Tuple[int, ...]
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor, y: List[int]) -> Tensor:
|
|
|
|
|
...
|
|
|
|
|
del foo
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'unsupported type'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: Tensor, y: Callable) -> Tensor:
|
|
|
|
|
...
|
|
|
|
|
del foo
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_custom_op_behaves_like_function(self):
|
|
|
|
|
from torch.testing._internal.custom_op_db import numpy_mul
|
|
|
|
|
self.assertEqual(numpy_mul.__name__, 'numpy_mul')
|
|
|
|
|
self.assertEqual(numpy_mul.__module__, 'torch.testing._internal.custom_op_db')
|
|
|
|
|
self.assertTrue(callable(numpy_mul))
|
|
|
|
|
|
|
|
|
|
def test_custom_op_repr(self):
|
|
|
|
|
from torch.testing._internal.custom_op_db import numpy_mul
|
|
|
|
|
expected = '<CustomOp(op="_torch_testing::numpy_mul")>'
|
|
|
|
|
self.assertEqual(repr(numpy_mul), expected)
|
|
|
|
|
|
|
|
|
|
def test_supported_schemas(self):
|
|
|
|
|
# All of these should already be tested by PyTorch codegen
|
|
|
|
|
# (we share the same mechanism), but here's a sanity check.
|
|
|
|
|
schemas = [
|
|
|
|
|
'(Tensor x) -> Tensor',
|
|
|
|
|
'(Tensor x) -> Tensor y',
|
|
|
|
|
'(Tensor[] x) -> Tensor y',
|
|
|
|
|
'(Tensor x) -> (Tensor, Tensor)',
|
|
|
|
|
'(Tensor x) -> (Tensor y, Tensor z)',
|
|
|
|
|
'(Tensor x) -> (Tensor y, Tensor z)',
|
|
|
|
|
]
|
|
|
|
|
other_schemas = [
|
|
|
|
|
'(Tensor x, Tensor w) -> (Tensor y, Tensor z)',
|
|
|
|
|
'(Tensor x, Tensor w) -> (Tensor, Tensor)',
|
|
|
|
|
'(Tensor x, Tensor w) -> Tensor',
|
|
|
|
|
'(Tensor? x, Tensor w) -> Tensor',
|
|
|
|
|
'(Tensor? x, Tensor[] w) -> Tensor',
|
|
|
|
|
'(Tensor x, int[] w) -> Tensor',
|
|
|
|
|
'(Tensor x, SymInt[] w) -> Tensor',
|
|
|
|
|
'(Tensor x, Scalar w) -> Tensor',
|
|
|
|
|
'(Tensor x, float w) -> Tensor',
|
|
|
|
|
'(Tensor x, float? w) -> Tensor',
|
|
|
|
|
'(Tensor x, bool[] w) -> Tensor',
|
|
|
|
|
]
|
|
|
|
|
|
|
|
|
|
def foo(x):
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
def bar(x, w):
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
for schema in schemas:
|
2023-05-15 21:12:23 +00:00
|
|
|
op = custom_op(f'{TestCustomOp.test_ns}::foo', schema)(foo)
|
2023-04-27 21:27:53 +00:00
|
|
|
op._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
for schema in other_schemas:
|
2023-05-15 21:12:23 +00:00
|
|
|
op = custom_op(f'{TestCustomOp.test_ns}::bar', schema)(bar)
|
2023-04-27 21:27:53 +00:00
|
|
|
op._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_reserved_ns(self):
|
|
|
|
|
from torch._custom_op import RESERVED_NS
|
|
|
|
|
|
|
|
|
|
for ns in RESERVED_NS:
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'is a reserved namespace'):
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
@custom_op(f'{ns}::foo', '(Tensor x) -> Tensor')
|
|
|
|
|
def foo(x):
|
|
|
|
|
...
|
|
|
|
|
with self.assertRaisesRegex(ValueError, 'is a reserved namespace'):
|
|
|
|
|
@custom_op(f'{ns}::foo2')
|
|
|
|
|
def foo2(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
def test_private_ctor(self):
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'CustomOp constructor is private'):
|
|
|
|
|
CustomOp(None, None, None, None)
|
|
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
def test_lifetime(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
# 3 references:
|
|
|
|
|
# - foo (in this function)
|
|
|
|
|
# - arg passed to sys.getrefcount
|
|
|
|
|
# - global_registry
|
|
|
|
|
self.assertEqual(sys.getrefcount(foo), 3)
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
# We can't define an op multiple times,
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'multiple times'):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
# Unless we delete the original op.
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
# Smoke test
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_autograd_notimplemented(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3, requires_grad=True)
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'Autograd has not been implemented'):
|
|
|
|
|
foo(x)
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
2023-05-15 18:15:08 +00:00
|
|
|
def foo(x: Tuple[torch.Tensor, ...]) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3, requires_grad=True)
|
|
|
|
|
y = torch.randn(3)
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'Autograd has not been implemented'):
|
|
|
|
|
foo([y, x])
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor, y: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3, requires_grad=True)
|
|
|
|
|
y = torch.randn(3)
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'Autograd has not been implemented'):
|
|
|
|
|
foo(y, x)
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_impl_cpu(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
@foo.impl('cpu')
|
|
|
|
|
def foo_cpu(x):
|
2023-04-18 13:51:23 +00:00
|
|
|
return x.sin()
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3)
|
2023-04-27 21:27:53 +00:00
|
|
|
result = foo(x)
|
|
|
|
|
self.assertEqual(result, foo_cpu(x))
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_impl_invalid_devices(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
def foo_impl(x):
|
|
|
|
|
return x.sin()
|
|
|
|
|
|
|
|
|
|
from torch._custom_op import SUPPORTED_DEVICE_TYPE_TO_KEY
|
|
|
|
|
|
|
|
|
|
for device_type in SUPPORTED_DEVICE_TYPE_TO_KEY.keys():
|
|
|
|
|
# Smoke test: should not raise error
|
|
|
|
|
foo.impl(device_type)(foo_impl)
|
|
|
|
|
|
|
|
|
|
# Not supported by this API: we can either support them in the future
|
|
|
|
|
# or provide some other CustomOp.def_* function. This depends on how
|
|
|
|
|
# common the use cases are.
|
|
|
|
|
for invalid_type in ['hip', 'xla', 'mkldnn', ['cpu', 'hip']]:
|
|
|
|
|
with self.assertRaisesRegex(ValueError, "we only support device_type"):
|
|
|
|
|
foo.impl(invalid_type)(foo_impl)
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
@unittest.skipIf(not TEST_CUDA, "requires CUDA")
|
|
|
|
|
def test_impl_separate(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
|
|
|
|
@foo.impl('cpu')
|
|
|
|
|
def foo_cpu(x):
|
|
|
|
|
return x.sin()
|
|
|
|
|
|
|
|
|
|
@foo.impl('cuda')
|
|
|
|
|
def foo_cuda(x):
|
|
|
|
|
return x.cos()
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3)
|
|
|
|
|
result = foo(x)
|
|
|
|
|
self.assertEqual(result, foo_cpu(x))
|
|
|
|
|
|
|
|
|
|
x_cuda = x.cuda()
|
|
|
|
|
result = foo(x_cuda)
|
|
|
|
|
self.assertEqual(result, foo_cuda(x_cuda))
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
@unittest.skipIf(not TEST_CUDA, "requires CUDA")
|
|
|
|
|
def test_impl_multiple(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
@foo.impl(['cpu', 'cuda'])
|
|
|
|
|
def foo_impl(x):
|
2023-04-18 13:51:23 +00:00
|
|
|
return x.cos()
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3)
|
2023-04-27 21:27:53 +00:00
|
|
|
result = foo(x)
|
|
|
|
|
self.assertEqual(result, foo_impl(x))
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
x_cuda = x.cuda()
|
2023-04-27 21:27:53 +00:00
|
|
|
result = foo(x_cuda)
|
|
|
|
|
self.assertEqual(result, foo_impl(x_cuda))
|
|
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
|
|
|
|
def test_impl_meta(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor, dim: int) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:52 +00:00
|
|
|
@foo.impl_abstract()
|
2023-04-18 13:51:23 +00:00
|
|
|
def foo_meta(x, dim):
|
|
|
|
|
output_shape = list(x.shape)
|
|
|
|
|
del output_shape[dim]
|
|
|
|
|
return x.new_empty(output_shape)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(2, 3, device='meta')
|
|
|
|
|
result = foo(x, 1)
|
|
|
|
|
self.assertEqual(result.shape, foo_meta(x, 1).shape)
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
2023-05-11 20:21:02 +00:00
|
|
|
def test_duplicate_impl(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
2023-05-11 20:21:02 +00:00
|
|
|
def foo(x: torch.Tensor, dim: int) -> torch.Tensor:
|
|
|
|
|
...
|
|
|
|
|
|
|
|
|
|
@foo.impl_abstract()
|
|
|
|
|
def foo_meta(x, dim):
|
|
|
|
|
output_shape = list(x.shape)
|
|
|
|
|
del output_shape[dim]
|
|
|
|
|
return x.new_empty(output_shape)
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(
|
|
|
|
|
RuntimeError,
|
|
|
|
|
r"already has a abstract impl.*at .*test_python_dispatch.py:\d+"):
|
|
|
|
|
@foo.impl_abstract()
|
|
|
|
|
def foo_meta2(x, dim):
|
|
|
|
|
output_shape = list(x.shape)
|
|
|
|
|
del output_shape[dim]
|
|
|
|
|
return x.new_empty(output_shape)
|
|
|
|
|
|
|
|
|
|
foo._destroy()
|
|
|
|
|
|
2023-04-27 21:27:52 +00:00
|
|
|
def test_new_data_dependent_symint(self):
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-27 21:27:52 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:53 +00:00
|
|
|
@foo.impl_abstract()
|
|
|
|
|
def foo_meta(x):
|
2023-04-27 21:27:52 +00:00
|
|
|
ctx = torch._custom_op.get_ctx()
|
|
|
|
|
with self.assertRaisesRegex(ValueError, "greater than or equal to 2"):
|
|
|
|
|
ctx.create_unbacked_symint(min=1)
|
|
|
|
|
with self.assertRaisesRegex(ValueError, "greater than or equal to 2"):
|
|
|
|
|
ctx.create_unbacked_symint(min=-1)
|
|
|
|
|
with self.assertRaisesRegex(ValueError, "SymInt"):
|
|
|
|
|
ctx.create_unbacked_symint(max=x.numel())
|
|
|
|
|
return torch.clone(x)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(2, 3, device='cpu')
|
2023-04-27 21:27:53 +00:00
|
|
|
make_fx(foo, tracing_mode='symbolic')(x)
|
|
|
|
|
foo._destroy()
|
2023-04-27 21:27:52 +00:00
|
|
|
|
|
|
|
|
def test_meta_for_data_dependent_shape_operation(self):
|
|
|
|
|
from torch.testing._internal.custom_op_db import numpy_nonzero
|
|
|
|
|
|
|
|
|
|
x = torch.randn(10, device='meta')
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, 'data-dependent output shape'):
|
|
|
|
|
numpy_nonzero(x)
|
|
|
|
|
|
2023-04-18 13:51:23 +00:00
|
|
|
def test_basic_make_fx(self):
|
|
|
|
|
# More serious tests are in our CustomOp opinfo db,
|
|
|
|
|
# this one is just a sanity check.
|
2023-05-15 21:12:23 +00:00
|
|
|
@custom_op(f'{TestCustomOp.test_ns}::foo')
|
Improved CustomOp API with schema inference (#100127)
This PR changes the CustomOp API. There are now two ways to create a
CustomOp object.
Method 1: with no schema string. We will infer what the schema string is
from your type annotations
```py
@custom_op("customlib::foo")
def foo(x: Tensor) -> Tensor:
...
```
Method 2: with a schema string, if the inference doesn't work well.
```py
@custom_op("customlib::foo", "(Tensor x) -> Tensor")
def foo(x):
...
```
Some details:
- We support most combinations of {Tensor, Number, int, float, bool} and
{Optional[typ], Tuple[typ, ...]} as inputs. The combinations we support are mostly
from me reading native_functions.yaml.
- We support only Tensor or Tuple of Tensor of fixed size returns.
- A lot of this PR is input validation for both of the above two
methods. For example, when a user provides a manual schema string, then
their function must not have any type annotations and the number of args
and arg names must match the schema.
Test Plan:
- new tests
Pull Request resolved: https://github.com/pytorch/pytorch/pull/100127
Approved by: https://github.com/ezyang
2023-04-27 21:27:53 +00:00
|
|
|
def foo(x: torch.Tensor) -> torch.Tensor:
|
2023-04-18 13:51:23 +00:00
|
|
|
...
|
|
|
|
|
|
2023-04-27 21:27:52 +00:00
|
|
|
@foo.impl_abstract()
|
2023-04-18 13:51:23 +00:00
|
|
|
def foo_meta(x):
|
|
|
|
|
return x.sum()
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3)
|
|
|
|
|
gm = make_fx(foo, tracing_mode='symbolic')(x)
|
2023-05-15 21:12:23 +00:00
|
|
|
self.assertTrue(f'{TestCustomOp.test_ns}.foo' in gm.code)
|
2023-04-27 21:27:53 +00:00
|
|
|
foo._destroy()
|
2023-04-18 13:51:23 +00:00
|
|
|
|
2023-04-27 21:27:52 +00:00
|
|
|
def test_abstract_registration_location(self):
|
2023-05-11 20:21:02 +00:00
|
|
|
loc = torch.testing._internal.custom_op_db.numpy_nonzero._get_impl('abstract').location
|
2023-04-27 21:27:52 +00:00
|
|
|
matches = re.match(r'.*custom_op_db.py:\d+', loc)
|
|
|
|
|
self.assertIsNotNone(matches)
|
|
|
|
|
|
|
|
|
|
def test_data_dependent_basic(self):
|
|
|
|
|
from torch.testing._internal.custom_op_db import numpy_nonzero
|
|
|
|
|
|
|
|
|
|
def f(x):
|
|
|
|
|
return numpy_nonzero(x)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(5, 5)
|
|
|
|
|
gm = make_fx(f, tracing_mode='symbolic')(x)
|
|
|
|
|
self.assertTrue('nonzero' in gm.code)
|
|
|
|
|
|
|
|
|
|
def test_data_dependent_fake_tracing(self):
|
|
|
|
|
from torch.testing._internal.custom_op_db import numpy_nonzero
|
|
|
|
|
|
|
|
|
|
def f(x):
|
|
|
|
|
return numpy_nonzero(x)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(5, 5)
|
|
|
|
|
with self.assertRaises(torch._subclasses.fake_tensor.DynamicOutputShapeException):
|
|
|
|
|
make_fx(f, tracing_mode='fake')(x)
|
|
|
|
|
|
|
|
|
|
@unittest.skipIf(IS_WINDOWS, "torch.compile doesn't work on windows")
|
|
|
|
|
def test_data_dependent_compile(self):
|
|
|
|
|
import torch._dynamo.testing
|
|
|
|
|
from torch._dynamo.utils import counters
|
|
|
|
|
counters.clear()
|
|
|
|
|
cnt = torch._dynamo.testing.CompileCounter()
|
|
|
|
|
|
|
|
|
|
@torch.compile(backend=cnt)
|
|
|
|
|
def f(x):
|
|
|
|
|
return torch.ops._torch_testing.numpy_nonzero(x.clone()).clone()
|
|
|
|
|
|
|
|
|
|
f(torch.randn(10))
|
|
|
|
|
|
|
|
|
|
self.assertEqual(
|
|
|
|
|
dict(counters['graph_break']),
|
|
|
|
|
{'dynamic shape operator: _torch_testing.numpy_nonzero.default': 1},
|
|
|
|
|
)
|
|
|
|
|
|
|
|
|
|
# pre-existing problem: torch.compile(dynamic=True) will, by default,
|
|
|
|
|
# graph break on data-dependent operations. Eventually we'll make it so
|
|
|
|
|
# that it never graph breaks on data-dependent operations.
|
|
|
|
|
@unittest.expectedFailure
|
|
|
|
|
def test_data_dependent_nms_dynamic_compile(self):
|
|
|
|
|
import torch._dynamo.testing
|
|
|
|
|
from torch._dynamo.utils import counters
|
|
|
|
|
counters.clear()
|
|
|
|
|
cnt = torch._dynamo.testing.CompileCounter()
|
|
|
|
|
|
|
|
|
|
@torch.compile(backend=cnt, dynamic=True)
|
|
|
|
|
def f(x, s, i):
|
|
|
|
|
return torch.ops._torch_testing.numpy_nms(x.clone(), s, i).clone()
|
|
|
|
|
|
|
|
|
|
f(torch.randn(20, 4), torch.randn(20), 0.1)
|
|
|
|
|
|
|
|
|
|
self.assertEqual(len(counters['graph_break']), 0)
|
|
|
|
|
|
|
|
|
|
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
class TestPythonDispatch(TestCase):
|
|
|
|
|
def test_basic(self) -> None:
|
|
|
|
|
with capture_logs() as logs:
|
2022-02-14 20:05:41 +00:00
|
|
|
x = LoggingTensor(torch.tensor([3.0]), requires_grad=True)
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
log_input("x", x)
|
|
|
|
|
y = x * x
|
|
|
|
|
saved_x = y.grad_fn._saved_self
|
|
|
|
|
grad_y = LoggingTensor(torch.tensor([1.0]))
|
|
|
|
|
log_input("grad_y", grad_y)
|
2021-08-12 18:39:31 +00:00
|
|
|
g, = torch.autograd.grad((y,), (x,), (grad_y,))
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
|
|
|
|
|
self.assertEqual(g.elem, torch.tensor([6.0]))
|
|
|
|
|
with torch.no_grad():
|
|
|
|
|
self.assertEqual(saved_x, x)
|
|
|
|
|
self.assertEqual(saved_x._version, x._version)
|
|
|
|
|
x.add_(2)
|
|
|
|
|
self.assertEqual(saved_x, x)
|
|
|
|
|
# TODO: figure out why broken
|
|
|
|
|
# self.assertEqual(saved_x._version, x._version)
|
2021-08-12 18:39:31 +00:00
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
$0 = input('x')
|
2022-03-07 22:32:41 +00:00
|
|
|
$1 = torch._ops.aten.mul.Tensor($0, $0)
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
$2 = input('grad_y')
|
2022-06-15 19:49:42 +00:00
|
|
|
True = torch._ops.aten.is_same_size.default($1, $2)
|
2022-03-07 22:32:41 +00:00
|
|
|
$3 = torch._ops.aten.mul.Tensor($2, $0)
|
|
|
|
|
$4 = torch._ops.aten.mul.Tensor($2, $0)
|
|
|
|
|
$5 = torch._ops.aten.add.Tensor($4, $3)''')
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
|
|
|
|
|
def test_out(self) -> None:
|
|
|
|
|
with capture_logs() as logs:
|
|
|
|
|
x = LoggingTensor(torch.ones(1))
|
|
|
|
|
y = LoggingTensor(torch.zeros(1))
|
|
|
|
|
log_input("x", x)
|
|
|
|
|
log_input("y", y)
|
|
|
|
|
torch.abs(x, out=y)
|
|
|
|
|
|
|
|
|
|
self.assertEqual(y.elem, torch.ones(1))
|
|
|
|
|
# TODO: arguably this shouldn't pass and we should complain
|
|
|
|
|
# that out isn't a kwarg
|
2021-08-12 18:39:31 +00:00
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
$0 = input('x')
|
|
|
|
|
$1 = input('y')
|
2022-03-07 22:32:41 +00:00
|
|
|
$2 = torch._ops.aten.abs.out($0, out=$1)''')
|
2021-08-12 18:39:31 +00:00
|
|
|
|
2021-08-09 16:59:01 +00:00
|
|
|
def test_kwarg_only(self) -> None:
|
|
|
|
|
with capture_logs() as logs:
|
|
|
|
|
x = LoggingTensor(torch.ones(1))
|
|
|
|
|
y = LoggingTensor(torch.ones(1, 1))
|
|
|
|
|
z = LoggingTensor(torch.ones(1))
|
|
|
|
|
log_input("x", x)
|
|
|
|
|
log_input("y", y)
|
|
|
|
|
log_input("z", z)
|
|
|
|
|
torch.addmv(x, y, z)
|
|
|
|
|
torch.addmv(x, y, z, beta=1)
|
|
|
|
|
torch.addmv(x, y, z, beta=2)
|
|
|
|
|
torch.addmv(x, y, z, alpha=2)
|
|
|
|
|
torch.addmv(x, y, z, beta=2, alpha=2)
|
|
|
|
|
|
|
|
|
|
# The expectation is that beta/alpha don't show up when they're
|
|
|
|
|
# defaulted. This is even if the user explicitly specified it.
|
2021-08-12 18:39:31 +00:00
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
2021-08-09 16:59:01 +00:00
|
|
|
$0 = input('x')
|
|
|
|
|
$1 = input('y')
|
|
|
|
|
$2 = input('z')
|
2022-03-07 22:32:41 +00:00
|
|
|
$3 = torch._ops.aten.addmv.default($0, $1, $2)
|
|
|
|
|
$4 = torch._ops.aten.addmv.default($0, $1, $2)
|
|
|
|
|
$5 = torch._ops.aten.addmv.default($0, $1, $2, beta=2)
|
|
|
|
|
$6 = torch._ops.aten.addmv.default($0, $1, $2, alpha=2)
|
|
|
|
|
$7 = torch._ops.aten.addmv.default($0, $1, $2, beta=2, alpha=2)''')
|
2021-08-09 16:59:01 +00:00
|
|
|
|
|
|
|
|
def test_kwarg_only_and_positional_default(self) -> None:
|
|
|
|
|
with capture_logs() as logs:
|
|
|
|
|
x = LoggingTensor(torch.ones(1))
|
|
|
|
|
log_input("x", x)
|
2022-07-13 18:38:12 +00:00
|
|
|
torch.ops.aten._foobar(x)
|
|
|
|
|
torch.ops.aten._foobar(x, False)
|
|
|
|
|
torch.ops.aten._foobar(x, arg3=False)
|
|
|
|
|
torch.ops.aten._foobar(x, False, arg3=False)
|
2021-08-09 16:59:01 +00:00
|
|
|
|
2022-07-13 18:38:12 +00:00
|
|
|
# What we are testing here is that we omit arg2
|
2021-08-09 16:59:01 +00:00
|
|
|
# if it is defaulted, even if a kwarg is set
|
2021-08-12 18:39:31 +00:00
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
2021-08-09 16:59:01 +00:00
|
|
|
$0 = input('x')
|
2022-07-13 18:38:12 +00:00
|
|
|
$1 = torch._ops.aten._foobar.default($0)
|
|
|
|
|
$2 = torch._ops.aten._foobar.default($0, False)
|
|
|
|
|
$3 = torch._ops.aten._foobar.default($0, arg3=False)
|
|
|
|
|
$4 = torch._ops.aten._foobar.default($0, False, arg3=False)''')
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
|
2022-05-16 16:38:52 +00:00
|
|
|
def test_produce_real_type(self) -> None:
|
|
|
|
|
with capture_logs() as logs:
|
|
|
|
|
x = LoggingTensor(torch.ones(2, 2))
|
|
|
|
|
log_input("x", x)
|
|
|
|
|
x.to(dtype=torch.double) # non-optional dtype
|
|
|
|
|
torch.cumprod(x, 0, dtype=torch.double) # optional dtype
|
|
|
|
|
x[:, 1].contiguous(memory_format=torch.contiguous_format) # optional memory format
|
|
|
|
|
# There doesn't appear to be any layout signatures which are
|
|
|
|
|
# triggerable using tensor subclasses (need to use a mode)
|
|
|
|
|
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
|
|
|
|
$0 = input('x')
|
|
|
|
|
$1 = torch._ops.aten._to_copy.default($0, dtype=torch.float64)
|
|
|
|
|
$2 = torch._ops.aten.cumprod.default($0, 0, dtype=torch.float64)
|
|
|
|
|
$3 = torch._ops.aten.slice.Tensor($0, 0, 0, 9223372036854775807)
|
|
|
|
|
$4 = torch._ops.aten.select.int($3, 1, 1)
|
|
|
|
|
$5 = torch._ops.aten.clone.default($4, memory_format=torch.contiguous_format)''')
|
|
|
|
|
|
2022-11-11 14:33:41 +00:00
|
|
|
def test_optional_tensor_list(self) -> None:
|
|
|
|
|
def weird(xs):
|
2023-01-14 07:32:39 +00:00
|
|
|
print("woof")
|
2022-11-11 14:33:41 +00:00
|
|
|
return torch.empty(())
|
|
|
|
|
|
|
|
|
|
my_lib = Library("my_lib", "DEF")
|
|
|
|
|
my_lib.define("weird(Tensor?[] self) -> Tensor")
|
|
|
|
|
my_lib.impl("weird", weird, "CPU")
|
|
|
|
|
with capture_logs() as logs:
|
|
|
|
|
x = LoggingTensor(torch.ones(2, 2))
|
|
|
|
|
log_input("x", x)
|
|
|
|
|
torch.ops.my_lib.weird.default([None, x])
|
|
|
|
|
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
|
|
|
|
$0 = input('x')
|
|
|
|
|
$1 = torch._ops.my_lib.weird.default([None, LoggingTensor(tensor([[1., 1.],
|
|
|
|
|
[1., 1.]]))])''')
|
|
|
|
|
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
def test_list_ret(self) -> None:
|
|
|
|
|
# test all sequence types are permissible returns
|
|
|
|
|
for list_type in (list, tuple):
|
2022-08-10 19:45:23 +00:00
|
|
|
class A(torch._C._TensorBase):
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
2022-03-07 22:32:41 +00:00
|
|
|
if func.overloadpacket == torch.ops.aten.split:
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
with no_dispatch():
|
|
|
|
|
return list_type(torch.split(*args))
|
|
|
|
|
else:
|
|
|
|
|
raise AssertionError(f"unrecognized func: {func}")
|
|
|
|
|
|
|
|
|
|
self.assertEqual(
|
|
|
|
|
torch.split(A(torch.tensor([0, 1])), 2),
|
2021-08-12 18:39:31 +00:00
|
|
|
torch.split(torch.tensor([0, 1]), 2)
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
)
|
|
|
|
|
|
|
|
|
|
def test_invalid_ret(self) -> None:
|
|
|
|
|
# test invalid return gets reasonable error message
|
|
|
|
|
class A(torch._C._TensorBase):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
return "arf"
|
|
|
|
|
|
2021-07-23 17:35:50 +00:00
|
|
|
# Wobbles depending on NDEBUG mode of pybind11
|
2022-03-15 19:11:08 +00:00
|
|
|
self.assertRaisesRegex(
|
2021-08-12 18:39:31 +00:00
|
|
|
RuntimeError, "Unable to cast", lambda: A(torch.zeros(1)).neg(),
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
)
|
2023-02-07 20:08:53 +00:00
|
|
|
self.assertRaisesRegex(
|
2022-01-28 16:08:55 +00:00
|
|
|
RuntimeError, "Unable to cast", lambda: A(torch.zeros(1)).detach(),
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
)
|
|
|
|
|
|
2022-01-28 16:08:55 +00:00
|
|
|
def test_detach_appears_twice_when_called_once(self) -> None:
|
|
|
|
|
with capture_logs() as logs:
|
2022-02-14 20:05:41 +00:00
|
|
|
x = LoggingTensor(torch.tensor([3.0]), requires_grad=True)
|
2022-01-28 16:08:55 +00:00
|
|
|
log_input("x", x)
|
|
|
|
|
x.detach()
|
|
|
|
|
# FIXME: We actually want this to emit a single detach. However,
|
|
|
|
|
# it currently emits two, for reasons unclear to us. Leaving
|
|
|
|
|
# this test here to make sure we don't regress even further (it
|
|
|
|
|
# would be bad if calling .detach() once emits 3+ detaches).
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
|
|
|
|
$0 = input('x')
|
2022-03-07 22:32:41 +00:00
|
|
|
$1 = torch._ops.aten.detach.default($0)
|
|
|
|
|
$2 = torch._ops.aten.detach.default($1)''')
|
2022-01-28 16:08:55 +00:00
|
|
|
|
2021-09-22 18:09:11 +00:00
|
|
|
def test_storage(self) -> None:
|
|
|
|
|
# For now, just make sure it doesn't crash. Ideally, we should
|
|
|
|
|
# return some virtual storage that is safe to work with
|
|
|
|
|
x = LoggingTensor(torch.ones(1))
|
|
|
|
|
self.assertRaises(RuntimeError, lambda: x.storage())
|
|
|
|
|
|
|
|
|
|
def test_make_wrapper_subclass_noalloc(self) -> None:
|
|
|
|
|
# This is ludicrously big (8TB) and this should pass because wrapper
|
|
|
|
|
# subclasses don't allocate
|
|
|
|
|
torch.Tensor._make_wrapper_subclass(LoggingTensor, (1000000000000,))
|
|
|
|
|
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
def test_version(self) -> None:
|
|
|
|
|
x = LoggingTensor(torch.ones(1))
|
|
|
|
|
prev_vc = x._version
|
|
|
|
|
x.detach().add_(2)
|
|
|
|
|
cur_vc = x._version
|
|
|
|
|
self.assertNotEqual(prev_vc, cur_vc)
|
|
|
|
|
x.data.add_(2)
|
|
|
|
|
self.assertEqual(cur_vc, x._version)
|
|
|
|
|
|
2021-08-18 14:45:45 +00:00
|
|
|
def test_subclass_priority(self) -> None:
|
|
|
|
|
class ErrorA(RuntimeError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
class ErrorB(RuntimeError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
# The big tests for code coverage are test_precedence_semantics in
|
|
|
|
|
# test_overrides.py; this is just to make sure it is wired up at all
|
|
|
|
|
# correctly for __torch_dispatch__
|
|
|
|
|
class A(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
raise ErrorA
|
|
|
|
|
|
|
|
|
|
class B(A):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
raise ErrorB
|
|
|
|
|
|
|
|
|
|
self.assertRaises(ErrorA, lambda: torch.add(A(torch.empty(1)), A(torch.empty(1))))
|
|
|
|
|
self.assertRaises(ErrorB, lambda: torch.add(A(torch.empty(1)), B(torch.empty(1))))
|
|
|
|
|
self.assertRaises(ErrorB, lambda: torch.add(B(torch.empty(1)), A(torch.empty(1))))
|
|
|
|
|
self.assertRaises(ErrorB, lambda: torch.add(B(torch.empty(1)), B(torch.empty(1))))
|
|
|
|
|
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
def test_format(self) -> None:
|
|
|
|
|
x = LoggingTensor(torch.ones(1))
|
|
|
|
|
s1 = str(x)
|
|
|
|
|
s2 = repr(x)
|
|
|
|
|
s3 = f"{x}"
|
|
|
|
|
self.assertExpectedInline(s1, """LoggingTensor(tensor([1.]))""")
|
|
|
|
|
self.assertEqual(s1, s2)
|
|
|
|
|
self.assertEqual(s1, s3)
|
|
|
|
|
|
|
|
|
|
def test_custom_autograd(self) -> None:
|
|
|
|
|
escape = [None]
|
|
|
|
|
|
|
|
|
|
class Square(torch.autograd.Function):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def forward(ctx, x):
|
|
|
|
|
y = x ** 2
|
|
|
|
|
ctx.save_for_backward(x)
|
|
|
|
|
return y
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def backward(ctx, grad_output):
|
|
|
|
|
assert isinstance(grad_output, LoggingTensor)
|
2021-08-12 18:39:31 +00:00
|
|
|
x, = ctx.saved_tensors
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
assert isinstance(x, LoggingTensor)
|
|
|
|
|
escape[0] = x
|
|
|
|
|
return grad_output * 2 * x
|
|
|
|
|
|
|
|
|
|
with capture_logs() as logs:
|
2022-02-14 20:05:41 +00:00
|
|
|
x = LoggingTensor(torch.ones(1), requires_grad=True)
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
log_input("x", x)
|
|
|
|
|
x.grad = LoggingTensor(torch.zeros(1))
|
|
|
|
|
log_input("x.grad", x.grad)
|
|
|
|
|
y = Square.apply(x)
|
|
|
|
|
grad_output = LoggingTensor(torch.ones(1))
|
|
|
|
|
log_input("grad_output", grad_output)
|
|
|
|
|
y.backward(grad_output)
|
|
|
|
|
|
|
|
|
|
with torch.no_grad():
|
|
|
|
|
self.assertEqual(escape[0], x)
|
|
|
|
|
self.assertEqual(escape[0]._version, x._version)
|
|
|
|
|
# TODO: figure out why x.requires_grad = False doesn't
|
|
|
|
|
# trigger an error for LoggingTensor
|
|
|
|
|
x.add_(2)
|
|
|
|
|
self.assertEqual(escape[0], x)
|
|
|
|
|
# TODO: figure out why this is broken
|
|
|
|
|
# self.assertEqual(escape[0]._version, x._version)
|
|
|
|
|
|
2021-08-12 18:39:31 +00:00
|
|
|
self.assertExpectedInline('\n'.join(logs), '''\
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
$0 = input('x')
|
|
|
|
|
$1 = input('x.grad')
|
2022-03-07 22:32:41 +00:00
|
|
|
$2 = torch._ops.aten.pow.Tensor_Scalar($0, 2)
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
$3 = input('grad_output')
|
2022-06-15 19:49:42 +00:00
|
|
|
True = torch._ops.aten.is_same_size.default($2, $3)
|
2022-05-06 16:24:42 +00:00
|
|
|
$4 = torch._ops.aten.mul.Tensor($3, 2)
|
2022-03-07 22:32:41 +00:00
|
|
|
$5 = torch._ops.aten.mul.Tensor($4, $0)
|
|
|
|
|
$6 = torch._ops.aten.add_.Tensor($1, $5)''')
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
|
2021-09-10 20:07:37 +00:00
|
|
|
def test_subclass_creation(self):
|
|
|
|
|
# Make sure these statements runs without error
|
|
|
|
|
# In particular checking that when internal detach returns
|
|
|
|
|
# subclasses, these are cleanly overwritten.
|
|
|
|
|
class Foo(torch.Tensor):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
err_msg = "subclass Foo but.*already associated to a python object of type LoggingTensor"
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, err_msg):
|
|
|
|
|
a = torch.Tensor._make_subclass(Foo, LoggingTensor(torch.rand(2)))
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, err_msg):
|
|
|
|
|
b = LoggingTensor(torch.rand(2)).as_subclass(Foo)
|
2021-09-22 18:09:11 +00:00
|
|
|
with self.assertRaisesRegex(RuntimeError, err_msg):
|
2021-09-10 20:07:37 +00:00
|
|
|
Foo(LoggingTensor(torch.rand(2)))
|
|
|
|
|
|
2021-09-22 18:09:11 +00:00
|
|
|
with self.assertRaisesRegex(TypeError, "Foo must define __torch_dispatch__"):
|
|
|
|
|
torch.Tensor._make_wrapper_subclass(Foo, (2, 2))
|
2021-09-10 20:07:37 +00:00
|
|
|
|
2021-09-21 17:45:44 +00:00
|
|
|
def test_new_ones(self) -> None:
|
|
|
|
|
class MyTensor(torch.Tensor):
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
return MyTensor(3)
|
|
|
|
|
|
|
|
|
|
self.assertEqual(type(MyTensor(2).new_ones(3)), MyTensor)
|
|
|
|
|
|
2021-10-13 20:32:02 +00:00
|
|
|
def test_like(self) -> None:
|
|
|
|
|
class MyTensor(torch.Tensor):
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
return MyTensor(3)
|
|
|
|
|
|
|
|
|
|
for f in ["empty", "ones", "rand", "randn", "zeros"]:
|
|
|
|
|
f_name = f + "_like"
|
|
|
|
|
self.assertEqual(type(getattr(torch, f_name)(MyTensor(2))), MyTensor)
|
|
|
|
|
|
|
|
|
|
self.assertEqual(type(torch.full_like(MyTensor(2), 1.)), MyTensor)
|
|
|
|
|
self.assertEqual(type(torch.randint_like(MyTensor(2), high=3)), MyTensor)
|
|
|
|
|
|
2021-11-18 15:06:26 +00:00
|
|
|
def test_make_wrapper_subclass_propagates_metadata(self) -> None:
|
|
|
|
|
class WrapperTensor(torch.Tensor):
|
|
|
|
|
elem: torch.Tensor
|
|
|
|
|
|
|
|
|
|
__slots__ = ['elem']
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem, *args, **kwargs):
|
|
|
|
|
r = torch.Tensor._make_wrapper_subclass( # type: ignore[attr-defined]
|
|
|
|
|
cls, elem.size(),
|
|
|
|
|
dtype=elem.dtype, layout=elem.layout,
|
|
|
|
|
device=elem.device, requires_grad=elem.requires_grad,
|
|
|
|
|
strides=elem.stride(), storage_offset=elem.storage_offset())
|
|
|
|
|
r.elem = elem
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
raise RuntimeError("NYI")
|
|
|
|
|
|
|
|
|
|
# non-contiguous strides, non-zero storage offset
|
|
|
|
|
x = torch.randn(4, 6).t().diagonal(offset=2)
|
|
|
|
|
y = WrapperTensor(x)
|
|
|
|
|
self.assertEqual(y.size(), x.size())
|
|
|
|
|
self.assertEqual(y.stride(), x.stride())
|
|
|
|
|
self.assertEqual(y.storage_offset(), x.storage_offset())
|
|
|
|
|
|
2022-02-24 15:59:39 +00:00
|
|
|
def test_wrapper_subclass_serializes(self) -> None:
|
|
|
|
|
with tempfile.TemporaryFile() as f:
|
|
|
|
|
x = LoggingTensor(torch.randn(3))
|
|
|
|
|
torch.save(x, f)
|
|
|
|
|
f.seek(0)
|
|
|
|
|
x_loaded = torch.load(f)
|
|
|
|
|
self.assertTrue(type(x_loaded) is type(x))
|
|
|
|
|
self.assertEqual(x.elem, x_loaded.elem)
|
|
|
|
|
self.assertFalse(x is x_loaded)
|
|
|
|
|
|
|
|
|
|
def test_deepcopy_wrapper_subclass(self) -> None:
|
|
|
|
|
x = LoggingTensor(torch.randn(3))
|
|
|
|
|
x_copy = deepcopy(x)
|
|
|
|
|
self.assertTrue(type(x_copy) is type(x))
|
|
|
|
|
self.assertEqual(x.elem, x_copy.elem)
|
|
|
|
|
self.assertFalse(x is x_copy)
|
|
|
|
|
|
|
|
|
|
def test_deepcopy_wrapper_subclass_with_clone_returning_different_type(self) -> None:
|
|
|
|
|
|
|
|
|
|
class MyWrapperTensor(torch.Tensor):
|
|
|
|
|
elem: torch.Tensor
|
|
|
|
|
|
|
|
|
|
__slots__ = ['elem']
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem, *args, **kwargs):
|
|
|
|
|
r = torch.Tensor._make_wrapper_subclass( # type: ignore[attr-defined]
|
|
|
|
|
cls, elem.size(),
|
|
|
|
|
dtype=elem.dtype, layout=elem.layout,
|
|
|
|
|
device=elem.device, requires_grad=elem.requires_grad,
|
|
|
|
|
strides=elem.stride(), storage_offset=elem.storage_offset())
|
|
|
|
|
r.elem = elem
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
2022-03-07 22:32:41 +00:00
|
|
|
if func.overloadpacket.__name__ == "clone":
|
2022-02-24 15:59:39 +00:00
|
|
|
# Return a plain tensor from clone().
|
|
|
|
|
return args[0].elem.clone()
|
|
|
|
|
raise RuntimeError("NYI")
|
|
|
|
|
|
|
|
|
|
# NB: The default Tensor.__torch_function__ implementation called for deepcopy
|
|
|
|
|
# disables __torch_function__ by the time we get to clone(), so there is no need to
|
|
|
|
|
# explicitly disable __torch_function__ for this subclass.
|
|
|
|
|
|
|
|
|
|
x = MyWrapperTensor(torch.randn(3))
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError,
|
|
|
|
|
"for which cloning returns another instance of the same subclass"):
|
|
|
|
|
x_copy = deepcopy(x)
|
|
|
|
|
|
|
|
|
|
def test_deepcopy_non_wrapper_subclass(self) -> None:
|
|
|
|
|
|
|
|
|
|
# Ensure correct error is thrown for common error cases.
|
|
|
|
|
class SubTensorError1(torch.Tensor):
|
|
|
|
|
# Default implementation of new_empty() returns a plain tensor.
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
class SubTensorError2(torch.Tensor):
|
|
|
|
|
# new_empty() incorrectly returns a different type (i.e. a plain tensor).
|
|
|
|
|
def new_empty(self, shape):
|
|
|
|
|
return torch.Tensor(shape)
|
|
|
|
|
|
|
|
|
|
for error_cls in [SubTensorError1, SubTensorError2]:
|
|
|
|
|
x = error_cls(3)
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError,
|
|
|
|
|
"for which that function returns another instance of the same subclass"):
|
|
|
|
|
x_copy = deepcopy(x)
|
|
|
|
|
|
|
|
|
|
# Ensure a correctly implemented new_empty() causes deepcopy() to work.
|
|
|
|
|
class SubTensorSuccess(torch.Tensor):
|
|
|
|
|
def new_empty(self, shape):
|
|
|
|
|
return type(self)(shape)
|
|
|
|
|
|
|
|
|
|
x = SubTensorSuccess(3)
|
|
|
|
|
x_copy = deepcopy(x)
|
|
|
|
|
self.assertIs(type(x_copy), type(x))
|
|
|
|
|
|
2021-11-29 16:29:05 +00:00
|
|
|
def test_index_put_where_only_index_is_subclass(self) -> None:
|
|
|
|
|
called_funcs = []
|
|
|
|
|
|
|
|
|
|
class MyTensor(torch.Tensor):
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
elem: torch.Tensor
|
|
|
|
|
__slots__ = ['elem']
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem, *args, **kwargs):
|
|
|
|
|
r = torch.Tensor._make_wrapper_subclass(
|
|
|
|
|
cls, elem.size(),
|
|
|
|
|
dtype=elem.dtype, layout=elem.layout,
|
|
|
|
|
device=elem.device, requires_grad=elem.requires_grad
|
|
|
|
|
)
|
|
|
|
|
r.elem = elem
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
called_funcs.append(func)
|
|
|
|
|
return MyTensor(torch.tensor(3))
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3, 3)
|
|
|
|
|
idxs = (MyTensor(torch.tensor(0)),)
|
|
|
|
|
v = torch.randn(1)
|
|
|
|
|
res = x.index_put_(idxs, v)
|
2022-03-07 22:32:41 +00:00
|
|
|
self.assertEqual(called_funcs, [torch.ops.aten.index_put_.default])
|
2021-11-29 16:29:05 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_torch_dispatch_mode_basic(self) -> None:
|
2022-05-24 01:23:24 +00:00
|
|
|
with capture_logs(is_mode=True) as logs:
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with LoggingTensorMode():
|
2022-05-24 01:23:24 +00:00
|
|
|
torch.empty([])
|
2022-08-06 01:18:40 +00:00
|
|
|
self.assertExpectedInline('\n'.join(logs), """\
|
|
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)""")
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_torch_dispatch_mode_unrelated_tensors(self) -> None:
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
x = torch.randn([])
|
|
|
|
|
y = torch.randn([])
|
2022-05-24 01:23:24 +00:00
|
|
|
with capture_logs(is_mode=True) as logs:
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with LoggingTensorMode():
|
2022-05-24 01:23:24 +00:00
|
|
|
x + y
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), """\
|
|
|
|
|
$2 = torch._ops.aten.add.Tensor($0, $1)""")
|
|
|
|
|
|
|
|
|
|
def test_nested_push_logging_tensor_mode(self):
|
|
|
|
|
x = torch.randn([])
|
|
|
|
|
y = torch.randn([])
|
|
|
|
|
with capture_logs(is_mode=True) as logs:
|
2022-07-22 15:10:52 +00:00
|
|
|
with LoggingTensorMode():
|
|
|
|
|
with LoggingTensorMode():
|
2022-05-24 01:23:24 +00:00
|
|
|
torch.empty([])
|
|
|
|
|
x + y
|
|
|
|
|
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), """\
|
2022-08-06 01:18:40 +00:00
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)
|
|
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)
|
2022-05-24 01:23:24 +00:00
|
|
|
$3 = torch._ops.aten.add.Tensor($1, $2)
|
|
|
|
|
$3 = torch._ops.aten.add.Tensor($1, $2)""")
|
|
|
|
|
|
|
|
|
|
def test_capture_logs_with_torch_dispatch_mode(self):
|
|
|
|
|
x = torch.randn([])
|
|
|
|
|
y = torch.randn([])
|
|
|
|
|
with capture_logs_with_logging_tensor_mode() as logs:
|
|
|
|
|
torch.empty([])
|
|
|
|
|
x + y
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), """\
|
2022-08-06 01:18:40 +00:00
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)
|
2022-05-24 01:23:24 +00:00
|
|
|
$3 = torch._ops.aten.add.Tensor($1, $2)""")
|
|
|
|
|
|
|
|
|
|
x = torch.randn([])
|
|
|
|
|
y = torch.randn([])
|
|
|
|
|
|
|
|
|
|
with capture_logs_with_logging_tensor_mode() as logs1:
|
|
|
|
|
with capture_logs_with_logging_tensor_mode() as logs2:
|
|
|
|
|
torch.empty([])
|
|
|
|
|
x + y
|
|
|
|
|
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs2), """\
|
2022-08-06 01:18:40 +00:00
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)
|
|
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)
|
2022-05-24 01:23:24 +00:00
|
|
|
$3 = torch._ops.aten.add.Tensor($1, $2)
|
|
|
|
|
$3 = torch._ops.aten.add.Tensor($1, $2)""")
|
|
|
|
|
|
|
|
|
|
self.assertEqual(logs1, logs2)
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_torch_dispatch_mode_subclass_priority(self) -> None:
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
class ErrorA(RuntimeError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
class ErrorB(RuntimeError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
class A(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with AMode():
|
|
|
|
|
raise ErrorA
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
|
|
|
|
|
class B(A):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with BMode():
|
|
|
|
|
func(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
class AMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
raise ErrorA
|
|
|
|
|
|
|
|
|
|
class BMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
raise ErrorB
|
|
|
|
|
|
|
|
|
|
a = A(torch.empty(1))
|
|
|
|
|
b = B(torch.empty(1))
|
|
|
|
|
with self.assertRaises(ErrorA):
|
|
|
|
|
a + a
|
|
|
|
|
with self.assertRaises(ErrorB):
|
2022-05-03 17:13:03 +00:00
|
|
|
a + b
|
|
|
|
|
|
|
|
|
|
# B has precedence over A due to the subclass relationship yet
|
|
|
|
|
# modes take precedence over arguments
|
|
|
|
|
with self.assertRaises(ErrorA):
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with AMode():
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
b + b
|
|
|
|
|
with self.assertRaises(ErrorB):
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with BMode():
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
a + a
|
|
|
|
|
with self.assertRaises(ErrorB):
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with BMode():
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
a + b
|
|
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_mode_with_make_subclass(self):
|
|
|
|
|
class SubTensor(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
class BasicMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
return func(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(3)
|
|
|
|
|
with BasicMode():
|
|
|
|
|
y = SubTensor(x)
|
|
|
|
|
self.assertIsInstance(y, SubTensor)
|
|
|
|
|
|
|
|
|
|
def test_torch_dispatch_mode_respects_no_dispatch(self) -> None:
|
2022-05-24 01:23:24 +00:00
|
|
|
with capture_logs(is_mode=True) as logs1:
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with LoggingTensorMode():
|
2022-05-24 01:23:24 +00:00
|
|
|
torch.ones([2, 3])
|
|
|
|
|
with no_dispatch():
|
|
|
|
|
torch.ones([2, 3])
|
|
|
|
|
with capture_logs(is_mode=True) as logs2:
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with LoggingTensorMode():
|
2022-05-24 01:23:24 +00:00
|
|
|
torch.ones([2, 3])
|
|
|
|
|
self.assertEqual(logs1, logs2)
|
[Reland] Add python mode (#64360)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/64360
This PR adds a (private) enable_python_mode context manager.
(see torch/utils/_python_dispatch.py).
enable_python_mode accepts the type of a __torch_dispatch__ object
as its argument. Whenever an operator gets called inside of the
context manager, it dispatches to the __torch_dispatch__ of
the passed-in type.
Example usage:
```
with enable_python_mode(LoggingTensor):
z = torch.empty([])
assert isinstance(z, LoggingTensor)
```
There are quite a few changes that were made to support this.
First, we added TorchDispatchTypeObject, a C++ struct that represents the
type of a `__torch_dispatch__` object (e.g. LoggingTensor).
It holds both the PyObject* representing the class and a PyInterpreter*
so we know which Python interpreter it came from.
Next, we updated the concrete_dispatch_fn in python_variable.cpp to accept
a `const std::shared_ptr<TorchDispatchTypeObject>&` argument. When this
is null, dispatching happens as usual. When it is non-null, we prepend
the TorchDispatchTypeObject's PyObject* to the overloaded args list so that
it is considered first for dispatch.
To get that to work, we changed how `handle_torch_dispatch_no_python_arg_parser`
works. The "overloaded args list" previously only consisted of Tensor PyObjects,
but now it can have types in addition to Tensors!
- We renamed `append_overloaded_arg` to `append_overloaded_arg`
- We added a new `append_overloaded_type` that appends a type to
overloaded_args
- We added special handling in `handle_torch_dispatch_no_python_arg_parser`
and `append_overloaded_arg` to handle types in addition to Tensors.
Then, there is PythonMode and PythonModeTLS.
- We reuse the DispatchKey::Python dispatch key as a mode key
- We use PythonMode::enter and PythonMode::exit to enable/disable
DispatchKey::Python and set the PythonModeTLS.
- PythonModeTLS stores a TorchDispatchTypeObject as metadata.
- PythonMode is in libtorch_python, and PythonModeTLS is in ATen.
This split is due to the libtorch_python library boundary (because we need
to save TLS in ATen/ThreadLocalState)
- We modify the PythonFallbackKernel to look up
the relevant TorchDispatchTypeObject (if Python Mode is active) and
dispatch using it.
There are two more miscellaneous changes:
- internal_new_from_data (torch/csrc/utils/tensor_new.cpp) gets an
exclude guard. enable_python_mode currently does not handle
torch.tensor and the exclude guard is to prevent a bug.
Future:
- This PR does not allow for the nesting of Python modes. In the future we
should be able to enable this with a more sane no_dispatch API and by changing
the TLS to a stack. For now I did not need this for CompositeImplicitAutograd testing.
Test Plan: - new tests
Reviewed By: ezyang
Differential Revision: D30698082
Pulled By: zou3519
fbshipit-source-id: 7094a90eee6aa51f8b71bc4d91cfb6f49e9691f8
2021-09-16 16:00:34 +00:00
|
|
|
|
2022-08-16 03:03:12 +00:00
|
|
|
def test_shallow_copy_and_detach(self) -> None:
|
|
|
|
|
seen = set()
|
|
|
|
|
test_case = self
|
|
|
|
|
|
|
|
|
|
class TestMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
tree_map_only(torch.Tensor, lambda t: test_case.assertIn(t, seen), (args, kwargs))
|
|
|
|
|
if kwargs is None:
|
|
|
|
|
kwargs = {}
|
|
|
|
|
r = func(*args, **kwargs)
|
|
|
|
|
tree_map_only(torch.Tensor, lambda t: seen.add(t), r)
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
with TestMode():
|
|
|
|
|
x = torch.randn(3, requires_grad=True)
|
|
|
|
|
loss = (x * x).sum()
|
|
|
|
|
loss.backward()
|
|
|
|
|
|
2022-05-03 17:13:03 +00:00
|
|
|
def test_exception_handling(self):
|
|
|
|
|
class A(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
class AMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
2022-05-03 17:13:03 +00:00
|
|
|
if func.__name__ == 'randn.default':
|
|
|
|
|
raise RuntimeError()
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
return A(torch.zeros(()))
|
2022-05-03 17:13:03 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with AMode():
|
2022-05-03 17:13:03 +00:00
|
|
|
try:
|
|
|
|
|
torch.randn(())
|
|
|
|
|
except RuntimeError:
|
|
|
|
|
pass
|
|
|
|
|
self.assertTrue(isinstance(torch.zeros(()), A))
|
|
|
|
|
|
2022-06-01 18:47:38 +00:00
|
|
|
def test_with_mode_created_separately(self):
|
|
|
|
|
class ErrorA(RuntimeError):
|
|
|
|
|
pass
|
|
|
|
|
|
|
|
|
|
class A(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
raise ErrorA()
|
|
|
|
|
|
|
|
|
|
x = A()
|
|
|
|
|
with self.assertRaises(ErrorA):
|
|
|
|
|
with x:
|
|
|
|
|
torch.empty([])
|
|
|
|
|
|
|
|
|
|
def test_with_nested_modes(self):
|
|
|
|
|
class ErrorA(RuntimeError):
|
|
|
|
|
def __init__(self, msg):
|
2023-05-11 23:57:25 +00:00
|
|
|
super().__init__(msg)
|
2022-06-01 18:47:38 +00:00
|
|
|
|
|
|
|
|
class A(TorchDispatchMode):
|
|
|
|
|
def __init__(self, msg):
|
|
|
|
|
self.msg = msg
|
|
|
|
|
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
raise ErrorA(self.msg)
|
|
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(ErrorA, "layer2"):
|
|
|
|
|
with A("layer1"):
|
2023-01-12 16:44:29 +00:00
|
|
|
with A("layer2"):
|
2022-06-01 18:47:38 +00:00
|
|
|
torch.empty([])
|
|
|
|
|
|
2022-06-17 18:47:18 +00:00
|
|
|
def test_make_subclass_with_modes(self):
|
2022-06-01 18:47:38 +00:00
|
|
|
class ModeTensor(torch.Tensor):
|
|
|
|
|
def __new__(cls, elem, mode):
|
|
|
|
|
r = torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
r.elem = elem
|
|
|
|
|
r.mode = mode
|
|
|
|
|
return r
|
|
|
|
|
|
2022-06-17 18:47:18 +00:00
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
raise NotImplementedError("Shouldn't be here")
|
2022-06-01 18:47:38 +00:00
|
|
|
|
|
|
|
|
class Mode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
def unwrap(e):
|
|
|
|
|
if isinstance(e, ModeTensor):
|
|
|
|
|
return e.elem
|
|
|
|
|
else:
|
|
|
|
|
return e
|
|
|
|
|
|
|
|
|
|
def wrap(t):
|
|
|
|
|
if isinstance(t, torch.Tensor):
|
|
|
|
|
return ModeTensor(t, self)
|
|
|
|
|
else:
|
|
|
|
|
return t
|
|
|
|
|
|
|
|
|
|
return wrap(func(*tuple(unwrap(a) for a in args), **kwargs))
|
|
|
|
|
|
2022-06-17 18:47:18 +00:00
|
|
|
class BasicMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
return func(*args, **kwargs)
|
|
|
|
|
|
2022-06-01 18:47:38 +00:00
|
|
|
x = torch.tensor(4.)
|
|
|
|
|
with Mode():
|
|
|
|
|
y = x + x
|
|
|
|
|
z = y + y
|
|
|
|
|
self.assertIsInstance(y, ModeTensor)
|
|
|
|
|
self.assertIsInstance(z, ModeTensor)
|
|
|
|
|
|
2022-06-17 18:47:18 +00:00
|
|
|
with Mode():
|
|
|
|
|
with BasicMode(): # we can't nest two modes that call make_subclass because it only accepts vanilla tensors
|
|
|
|
|
y = x + x
|
|
|
|
|
z = y + y
|
|
|
|
|
self.assertIsInstance(y, ModeTensor)
|
|
|
|
|
self.assertIsInstance(z, ModeTensor)
|
|
|
|
|
|
|
|
|
|
assert self.assertRaisesRegex(RuntimeError, "subclass Mode but.* associated to a python object of type Mode")
|
|
|
|
|
|
2022-07-06 20:18:50 +00:00
|
|
|
def test_notimplemented_mode(self):
|
|
|
|
|
sub_count = 0
|
|
|
|
|
|
|
|
|
|
class PoliteMode(TorchDispatchMode):
|
|
|
|
|
def __init__(self):
|
|
|
|
|
self.pre_count = 0
|
|
|
|
|
self.post_count = 0
|
|
|
|
|
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
self.pre_count += 1
|
|
|
|
|
if any(t is not torch.Tensor for t in types):
|
|
|
|
|
return NotImplemented
|
|
|
|
|
self.post_count += 1
|
|
|
|
|
return func(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
class SubTensor(torch.Tensor):
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
r = torch.Tensor._make_wrapper_subclass(cls, elem.shape)
|
|
|
|
|
r.elem = elem
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
nonlocal sub_count
|
|
|
|
|
sub_count += 1
|
|
|
|
|
|
|
|
|
|
def unwrap(t):
|
|
|
|
|
if isinstance(t, SubTensor):
|
|
|
|
|
return t.elem
|
|
|
|
|
else:
|
|
|
|
|
return t
|
|
|
|
|
|
|
|
|
|
return func(*tree_map(unwrap, args), **tree_map(unwrap, kwargs))
|
|
|
|
|
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
a = SubTensor(torch.randn(2))
|
2022-07-12 20:14:48 +00:00
|
|
|
with PoliteMode() as mode:
|
2022-07-06 20:18:50 +00:00
|
|
|
a.abs()
|
|
|
|
|
|
|
|
|
|
self.assertEqual(mode.pre_count, 2)
|
|
|
|
|
self.assertEqual(mode.post_count, 1)
|
|
|
|
|
self.assertEqual(sub_count, 1)
|
|
|
|
|
|
|
|
|
|
# make sure this doesn't error
|
|
|
|
|
with PoliteMode():
|
|
|
|
|
with PoliteMode():
|
|
|
|
|
a.abs()
|
|
|
|
|
|
2023-01-12 16:44:29 +00:00
|
|
|
def test_nesting_same_mode(self):
|
|
|
|
|
# If the pushed mode is the same instance as the current mode, we allow pushing an already active mode.
|
2022-06-17 18:47:18 +00:00
|
|
|
|
2023-01-12 16:44:29 +00:00
|
|
|
with capture_logs(is_mode=True) as logs:
|
|
|
|
|
with LoggingTensorMode() as reenabled:
|
|
|
|
|
with reenabled:
|
|
|
|
|
torch.empty([])
|
|
|
|
|
self.assertExpectedInline('\n'.join(logs), """\
|
|
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)
|
|
|
|
|
$0 = torch._ops.aten.empty.memory_format([], device=device(type='cpu'), pin_memory=False)""")
|
2022-06-01 18:47:38 +00:00
|
|
|
|
2022-05-03 17:13:03 +00:00
|
|
|
|
2022-06-03 21:26:18 +00:00
|
|
|
def test_error_using_class_method_on_mode(self):
|
|
|
|
|
class A(TorchDispatchMode):
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
return func(args, kwargs)
|
|
|
|
|
|
|
|
|
|
x = torch.tensor(5.)
|
2022-10-19 14:36:40 +00:00
|
|
|
with self.assertRaisesRegex(RuntimeError, "classmethod is not supported, please make it a plain method"):
|
2022-06-03 21:26:18 +00:00
|
|
|
with A():
|
|
|
|
|
x + x
|
|
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_get_cur_mode(self):
|
|
|
|
|
class A(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
2022-06-10 14:23:25 +00:00
|
|
|
pass
|
|
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
self.assertEqual(_get_current_dispatch_mode(), None)
|
2022-06-10 14:23:26 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with A() as mode1:
|
|
|
|
|
self.assertEqual(_get_current_dispatch_mode(), mode1)
|
2022-06-10 14:23:26 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with mode1:
|
|
|
|
|
with A() as mode2:
|
|
|
|
|
self.assertEqual(_get_current_dispatch_mode(), mode2)
|
2022-06-10 14:23:26 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_get_mode_stack(self):
|
|
|
|
|
class A(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
2022-06-10 14:23:26 +00:00
|
|
|
pass
|
|
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
self.assertEqual(_get_current_dispatch_mode_stack(), [])
|
2022-06-10 14:23:26 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with A() as mode1:
|
|
|
|
|
self.assertEqual(_get_current_dispatch_mode_stack(), [mode1])
|
2022-06-10 14:23:26 +00:00
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
with mode1:
|
|
|
|
|
with A() as mode2:
|
|
|
|
|
self.assertEqual(_get_current_dispatch_mode_stack(), [mode1, mode2])
|
2022-06-10 14:23:26 +00:00
|
|
|
|
|
|
|
|
def test_all_same_mode(self):
|
|
|
|
|
x = LoggingTensorMode()
|
|
|
|
|
y = LoggingTensorMode()
|
|
|
|
|
self.assertTrue(all_same_mode([x, x, x]))
|
|
|
|
|
self.assertFalse(all_same_mode([x, None]))
|
|
|
|
|
self.assertFalse(all_same_mode([x, y]))
|
|
|
|
|
|
2022-05-02 20:06:43 +00:00
|
|
|
def test_tolist_numpy_with_torch_dispatch_mode(self) -> None:
|
2021-10-13 20:49:31 +00:00
|
|
|
x = LoggingTensor(torch.tensor([2.0, 3.0]))
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, "is not supported for tensor subclasses."):
|
|
|
|
|
x.tolist()
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, "is not supported for tensor subclasses."):
|
|
|
|
|
x.numpy()
|
|
|
|
|
with self.assertRaises(AssertionError):
|
|
|
|
|
self.assertEqual(x, None)
|
|
|
|
|
|
2023-04-21 07:17:19 +00:00
|
|
|
def test_record_stream(self) -> None:
|
|
|
|
|
class TestMode(TorchDispatchMode):
|
|
|
|
|
def __init__(self, testcase):
|
|
|
|
|
self.testcase = testcase
|
|
|
|
|
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
self.testcase.assertEqual(func.name(), "aten::record_stream")
|
|
|
|
|
self.testcase.assertIsInstance(args[0], torch.Tensor)
|
|
|
|
|
self.testcase.assertIsInstance(args[1], torch.Stream)
|
|
|
|
|
self.testcase.assertEqual(args[1].stream_id, 1)
|
|
|
|
|
self.testcase.assertEqual(args[1].device_index, 2)
|
|
|
|
|
self.testcase.assertEqual(args[1].device_type, 3)
|
|
|
|
|
|
|
|
|
|
t = torch.tensor(5.)
|
|
|
|
|
s = torch.Stream(stream_id=1, device_index=2, device_type=3)
|
|
|
|
|
with TestMode(self):
|
|
|
|
|
t.record_stream(s)
|
|
|
|
|
|
|
|
|
|
def test_return_stream(self) -> None:
|
|
|
|
|
l_def = torch.library.Library("test_return_stream", "DEF")
|
|
|
|
|
l_def.define("return_stream(Tensor self) -> Stream")
|
|
|
|
|
l_impl = torch.library.Library("test_return_stream", "IMPL", "CPU")
|
|
|
|
|
l_impl.impl("return_stream", lambda _: torch.Stream(stream_id=0, device_index=1, device_type=2))
|
|
|
|
|
|
|
|
|
|
class TestMode(TorchDispatchMode):
|
|
|
|
|
def __torch_dispatch__(self, func, types, args=(), kwargs=None):
|
|
|
|
|
return torch.Stream(stream_id=1, device_index=2, device_type=3)
|
|
|
|
|
|
|
|
|
|
t = torch.tensor(5.)
|
|
|
|
|
s = torch.ops.test_return_stream.return_stream(t)
|
|
|
|
|
self.assertIsInstance(s, torch.Stream)
|
|
|
|
|
self.assertEqual(s.stream_id, 0)
|
|
|
|
|
self.assertEqual(s.device_index, 1)
|
|
|
|
|
self.assertEqual(s.device_type, 2)
|
|
|
|
|
|
|
|
|
|
with TestMode():
|
|
|
|
|
s = torch.ops.test_return_stream.return_stream(t)
|
|
|
|
|
self.assertIsInstance(s, torch.Stream)
|
|
|
|
|
self.assertEqual(s.stream_id, 1)
|
|
|
|
|
self.assertEqual(s.device_index, 2)
|
|
|
|
|
self.assertEqual(s.device_type, 3)
|
|
|
|
|
|
[Modes] remove enable and rewrite mode stack (squashed) (#84774)
Based on @ezyang's suggestion, mode stack now has "one true mode" which is the _only_ mode that can ever be active at the C++ level. That mode's torch dispatch is just to take the top mode in the stack, reenable itself (if we aren't at the end of the mode stack), and run the top mode's torch_{dispatch|function}
This maintains that in the middle of a mode's torch dispatch, the mode itself will not be active. It changes the function the user has to call to see what the current mode is (no longer queries the C++, it's python only) but allows the user to also see the entire mode stack easily
Removes `enable_torch_dispatch_mode` and `.restore()` since neither makes sense in this new setup
### Background
Why do we want this? Well, a pretty common pattern that was coming up was that users had to do something like
```python
## PRE-PR UX
def f(mode):
with mode.restore(): # user needs to understand this restore thing?
...
with Mode() as m:
pass
f(m)
```
Many users were getting error from forgetting to call `.restore` or from forgetting to add the (tbh weird) "mode instantiation" step where they use the mode as a context manager with an empty body. Really, they wanted to treat modes like context managers and just write
```python
## FROM FEEDBACK, USER DESIRED CODE. POSSIBLE POST-PR
def f(mode):
with mode:
...
f(Mode())
```
** Technical Details **
With the old mode stack, we basically had a linked list so the mode itself could only be used once and had a fixed parent. In this new design, the mode stack is just a python list that we're pushing to and popping from. There's only one mode that's ever active at the C++ level and it runs the next mode in the Python list. The modes don't have state on them anymore
Pull Request resolved: https://github.com/pytorch/pytorch/pull/84774
Approved by: https://github.com/ezyang, https://github.com/zou3519
2022-09-26 20:42:07 +00:00
|
|
|
def test_subclass_autograd_device_check(self) -> None:
|
2021-12-02 15:45:35 +00:00
|
|
|
class NonWrapperSubclass(torch.Tensor):
|
2021-09-24 15:37:41 +00:00
|
|
|
elem: torch.Tensor
|
|
|
|
|
|
|
|
|
|
__slots__ = ['elem']
|
|
|
|
|
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem, *args, **kwargs):
|
|
|
|
|
# Wrong device here!
|
|
|
|
|
r = torch.Tensor._make_subclass(cls, elem.to("meta"), elem.requires_grad)
|
|
|
|
|
# ...the real tensor is held as an element on the tensor.
|
|
|
|
|
r.elem = elem
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
def unwrap(e):
|
2021-12-02 15:45:35 +00:00
|
|
|
return e.elem if isinstance(e, NonWrapperSubclass) else e
|
2021-09-24 15:37:41 +00:00
|
|
|
|
|
|
|
|
def wrap(e):
|
2021-12-02 15:45:35 +00:00
|
|
|
return NonWrapperSubclass(e) if isinstance(e, torch.Tensor) else e
|
2021-09-24 15:37:41 +00:00
|
|
|
|
2022-05-03 17:13:03 +00:00
|
|
|
rs = tree_map(wrap, func(*tree_map(unwrap, args), **tree_map(unwrap, kwargs)))
|
2021-12-02 15:45:35 +00:00
|
|
|
logging.getLogger("NonWrapperSubclass").info(f"{func.__module__}.{func.__name__}", args, kwargs, rs)
|
2021-09-24 15:37:41 +00:00
|
|
|
return rs
|
|
|
|
|
|
2021-12-02 15:45:35 +00:00
|
|
|
x = NonWrapperSubclass(torch.tensor([3.0, 4.0], requires_grad=True))
|
2021-09-24 15:37:41 +00:00
|
|
|
y = torch.randn(2, requires_grad=True)
|
2021-09-22 17:57:59 +00:00
|
|
|
z = x * y
|
2021-12-02 15:45:35 +00:00
|
|
|
self.assertIsInstance(z, NonWrapperSubclass)
|
2021-09-24 15:37:41 +00:00
|
|
|
z.sum().backward(torch.tensor(1))
|
2021-09-22 17:57:59 +00:00
|
|
|
self.assertEqual(x.grad, y)
|
2021-09-24 15:37:41 +00:00
|
|
|
self.assertEqual(y.grad, x)
|
2021-09-22 17:57:59 +00:00
|
|
|
|
2021-12-02 15:45:35 +00:00
|
|
|
def test_none_wrapping(self):
|
|
|
|
|
# A Tensor subclass that returns None when doing add
|
|
|
|
|
# See LoggingTensor above for more details on the subclass
|
|
|
|
|
class SubclassWithNone(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem, *args, **kwargs):
|
|
|
|
|
r = torch.Tensor._make_wrapper_subclass(
|
|
|
|
|
cls, elem.size(),
|
|
|
|
|
dtype=elem.dtype, layout=elem.layout,
|
|
|
|
|
device=elem.device, requires_grad=elem.requires_grad
|
|
|
|
|
)
|
|
|
|
|
r.elem = elem
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
def unwrap(e):
|
|
|
|
|
return e.elem if isinstance(e, SubclassWithNone) else e
|
|
|
|
|
|
|
|
|
|
def wrap(e):
|
|
|
|
|
return SubclassWithNone(e) if isinstance(e, torch.Tensor) else e
|
|
|
|
|
|
2022-05-03 17:13:03 +00:00
|
|
|
rs = tree_map(wrap, func(*tree_map(unwrap, args), **tree_map(unwrap, kwargs)))
|
2022-03-07 22:32:41 +00:00
|
|
|
if func.overloadpacket.__name__ == "add":
|
2021-12-02 15:45:35 +00:00
|
|
|
return None
|
|
|
|
|
else:
|
|
|
|
|
return rs
|
|
|
|
|
|
|
|
|
|
x = SubclassWithNone(torch.rand(2))
|
|
|
|
|
# Make sure both run without error
|
|
|
|
|
self.assertIsInstance(x * 2, SubclassWithNone)
|
|
|
|
|
self.assertIsNone(x + 2)
|
|
|
|
|
|
|
|
|
|
x.requires_grad_()
|
|
|
|
|
out = x.acos().sum()
|
|
|
|
|
|
|
|
|
|
# The backward of acos does add then rsqrt so here we make sure that the
|
|
|
|
|
# undefined Tensor generated by the user code is nicely handled.
|
|
|
|
|
# If acos formula changes in the future, this can be replaced by any other
|
|
|
|
|
# function that does add then something in the backward in a composite way
|
2021-12-08 16:43:33 +00:00
|
|
|
with self.assertRaisesRegex(RuntimeError, "but got None"):
|
2021-12-02 15:45:35 +00:00
|
|
|
out.backward()
|
|
|
|
|
|
2022-01-20 02:07:36 +00:00
|
|
|
def test_storage_can_be_converted_to_python_object(self):
|
2022-05-24 01:23:24 +00:00
|
|
|
s = torch.Storage()
|
|
|
|
|
z = LoggingTensor(torch.empty([]))
|
|
|
|
|
z.set_(s)
|
2022-01-20 02:07:36 +00:00
|
|
|
|
2022-02-14 20:05:41 +00:00
|
|
|
def test_autograd_in_attr(self):
|
|
|
|
|
# We want the wrapped Tensor to require gradients!
|
|
|
|
|
true_t = torch.rand(2, requires_grad=True)
|
2022-04-20 14:01:17 +00:00
|
|
|
t = LoggingTensorReentrant(true_t)
|
2022-02-14 20:05:41 +00:00
|
|
|
|
|
|
|
|
out = t + 2
|
|
|
|
|
|
|
|
|
|
self.assertFalse(out.requires_grad)
|
|
|
|
|
self.assertIsNone(out.grad_fn)
|
|
|
|
|
|
2022-02-15 18:54:32 +00:00
|
|
|
self.assertTrue(out.elem.requires_grad)
|
|
|
|
|
self.assertIsNotNone(out.elem.grad_fn)
|
2022-02-14 20:05:41 +00:00
|
|
|
|
|
|
|
|
with self.assertRaisesRegex(RuntimeError, "does not require grad"):
|
2022-02-15 18:54:32 +00:00
|
|
|
out.sum().backward()
|
2022-02-14 20:05:41 +00:00
|
|
|
|
2022-02-15 18:54:32 +00:00
|
|
|
out.elem.sum().backward()
|
2022-02-14 20:05:41 +00:00
|
|
|
|
|
|
|
|
self.assertIsNone(t.grad)
|
2022-02-15 18:54:32 +00:00
|
|
|
self.assertIsNotNone(t.elem.grad)
|
2022-02-14 20:05:41 +00:00
|
|
|
|
2022-03-03 04:12:21 +00:00
|
|
|
def test_dispatch_super_call(self):
|
|
|
|
|
called = []
|
|
|
|
|
|
|
|
|
|
class SubTensor(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem)
|
|
|
|
|
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
called.append(func)
|
|
|
|
|
return super().__torch_dispatch__(func, types, args, kwargs)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(2)
|
|
|
|
|
y = torch.randn(2)
|
|
|
|
|
self.assertEqual(SubTensor(x) + SubTensor(y), x + y)
|
2022-03-07 22:32:41 +00:00
|
|
|
self.assertEqual(called, [torch.ops.aten.add.Tensor])
|
2022-03-03 04:12:21 +00:00
|
|
|
|
2022-03-23 18:52:42 +00:00
|
|
|
def test_dispatch_super_call_list_arg(self):
|
|
|
|
|
called = []
|
|
|
|
|
|
|
|
|
|
class SubTensorWithListArg(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem)
|
|
|
|
|
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
called.append(func)
|
|
|
|
|
return super().__torch_dispatch__(func, types, list(args), kwargs)
|
|
|
|
|
|
|
|
|
|
x = torch.randn(2)
|
|
|
|
|
self.assertEqual(SubTensorWithListArg(x).neg(), x.neg())
|
|
|
|
|
self.assertEqual(called, [torch.ops.aten.neg.default])
|
|
|
|
|
|
2022-03-03 04:12:21 +00:00
|
|
|
def test_dispatch_super_dont_autograd(self):
|
|
|
|
|
called = []
|
|
|
|
|
|
|
|
|
|
class SubTensor(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
return torch.Tensor._make_subclass(cls, elem, elem.requires_grad)
|
|
|
|
|
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
called.append(func)
|
|
|
|
|
# This argument still requires grad because it was passed
|
|
|
|
|
# through directly...
|
|
|
|
|
self.assertTrue(args[0].requires_grad)
|
|
|
|
|
r = super().__torch_dispatch__(func, types, args, kwargs)
|
|
|
|
|
# But the output better not require grad, because that means
|
|
|
|
|
# you did autograd again in torch dispatch (oops)
|
|
|
|
|
self.assertFalse(r.requires_grad)
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
x = SubTensor(torch.randn(2, requires_grad=True))
|
|
|
|
|
x.neg()
|
2022-03-07 22:32:41 +00:00
|
|
|
self.assertEqual(called, [torch.ops.aten.neg.default])
|
2022-03-03 04:12:21 +00:00
|
|
|
|
2022-04-15 03:21:50 +00:00
|
|
|
def test_set_data(self):
|
|
|
|
|
called = 0
|
|
|
|
|
|
|
|
|
|
class SubTensor(torch.Tensor):
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
nonlocal called
|
|
|
|
|
called += 1
|
|
|
|
|
return super().__torch_dispatch__(func, types, args, kwargs)
|
|
|
|
|
|
|
|
|
|
x = SubTensor(torch.empty(2))
|
|
|
|
|
x.data
|
|
|
|
|
self.assertEqual(called, 1)
|
|
|
|
|
x.data = torch.empty(2)
|
|
|
|
|
self.assertEqual(called, 1)
|
|
|
|
|
x.data
|
|
|
|
|
self.assertEqual(called, 2)
|
|
|
|
|
self.assertIs(type(x), SubTensor)
|
|
|
|
|
x.set_(torch.empty(2))
|
|
|
|
|
self.assertEqual(called, 3)
|
|
|
|
|
x.data
|
|
|
|
|
self.assertEqual(called, 4)
|
|
|
|
|
self.assertIs(type(x), SubTensor)
|
|
|
|
|
|
2022-03-09 15:38:00 +00:00
|
|
|
def test_construct_int_tensor(self):
|
|
|
|
|
class SubTensor(torch.Tensor):
|
|
|
|
|
pass
|
|
|
|
|
# should not fail
|
|
|
|
|
SubTensor(torch.zeros(2, dtype=torch.int))
|
|
|
|
|
|
2022-02-23 14:38:58 +00:00
|
|
|
def test_multiple_ops_subclass(self):
|
|
|
|
|
# This is a Direct Subclass, don't do that!
|
|
|
|
|
class MySubclass(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, elem):
|
|
|
|
|
r = torch.Tensor._make_subclass(cls, elem)
|
|
|
|
|
return r
|
|
|
|
|
|
|
|
|
|
__torch_function__ = torch._C._disabled_torch_function_impl
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args=(), kwargs=None):
|
|
|
|
|
with no_dispatch():
|
|
|
|
|
return func(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
x = MySubclass(torch.rand(2, 2, dtype=torch.complex64))
|
|
|
|
|
y = x.conj()
|
|
|
|
|
# Details of the bug that this tests for:
|
|
|
|
|
# Here, y dispatch keys are: {PythonTLSSnapshot, AutogradCPU, Conjugate, Python, CPU}
|
|
|
|
|
# There are a few calls to the dispatcher that are going to happen here:
|
|
|
|
|
# - call_exp: User calling exp on y
|
|
|
|
|
# - PythonTLSSnapshot: records the TLS on entry and redispatch
|
|
|
|
|
# - AutogradCPU: no input requires grad, so does nothing and redispatch
|
|
|
|
|
# - Conjugate: no special implementation for exp: use the fallback that
|
|
|
|
|
# first clone the Tensor (to materialize the conj) then redispatch
|
|
|
|
|
# - call_clone: conjugate fallback calling clone on y
|
|
|
|
|
# - PythonTLSSnapshot: records the TLS on entry and redispatch
|
|
|
|
|
# - (AutogradCPU: skipped as autograd added itself to the exclude set above)
|
|
|
|
|
# - Conjugate: special implementation for clone: just skip this key
|
|
|
|
|
# - Python: Reset the TLS based on the snapshot above and call the user implementation (this
|
|
|
|
|
# actually calls into the dispatcher again but since we disable both our keys
|
|
|
|
|
# before, not detailed here)
|
|
|
|
|
# - exit Python: restore the TLS and exit
|
|
|
|
|
# - exit Conjugate: nothing was inplace so just exit
|
|
|
|
|
# - exit PythonTLSSnapshot: done with this call, reset the saved TLS to empty
|
|
|
|
|
# - Python: Reset the TLS again based on the snapshot. <- this used to fail
|
|
|
|
|
# - More steps....
|
|
|
|
|
y.exp()
|
|
|
|
|
|
2022-05-24 16:23:05 +00:00
|
|
|
@staticmethod
|
|
|
|
|
def subclass_helper(cls, data, use_wrapper_subclass, **kwargs):
|
|
|
|
|
if use_wrapper_subclass:
|
|
|
|
|
kwargs["device"] = data.device
|
|
|
|
|
kwargs["dtype"] = data.dtype
|
|
|
|
|
kwargs["layout"] = data.layout
|
|
|
|
|
kwargs["requires_grad"] = True
|
|
|
|
|
return torch.Tensor._make_wrapper_subclass(cls, data.size(), **kwargs) # type: ignore[attr-defined]
|
|
|
|
|
else:
|
|
|
|
|
return torch.Tensor._make_subclass(cls, data, True, **kwargs)
|
|
|
|
|
|
2022-05-19 22:52:45 +00:00
|
|
|
def test_is_contiguous_slow_path(self):
|
|
|
|
|
data = torch.randn(3, 3)
|
|
|
|
|
contiguous_data = data.clone()
|
|
|
|
|
not_contiguous_data = torch.as_strided(data.clone(), (2, 2), (1, 2))
|
|
|
|
|
|
|
|
|
|
for use_wrapper_subclass in [True, False]:
|
|
|
|
|
class ExampleTensor1(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
2022-06-01 19:38:12 +00:00
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="strides")
|
2022-05-19 22:52:45 +00:00
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class ExampleTensor2(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
2022-06-01 19:38:12 +00:00
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="strides")
|
2022-05-19 22:52:45 +00:00
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.is_contiguous:
|
|
|
|
|
return contiguous_data.is_contiguous()
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class ExampleTensor3(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
2022-06-01 19:38:12 +00:00
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="strides")
|
2022-05-19 22:52:45 +00:00
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.is_contiguous:
|
|
|
|
|
return not_contiguous_data.is_contiguous()
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
err_msg = "no implementation found for 'torch.ops.aten.is_contiguous'"
|
|
|
|
|
e = ExampleTensor1(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
|
|
|
|
e.is_contiguous()
|
|
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
|
|
|
|
e.contiguous()
|
|
|
|
|
|
|
|
|
|
e = ExampleTensor2(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.is_contiguous(), True)
|
|
|
|
|
e.contiguous() # this will just return the original TensorImpl since is_contiguous = True
|
|
|
|
|
|
|
|
|
|
err_msg = "no implementation found for"
|
|
|
|
|
e = ExampleTensor3(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.is_contiguous(), False)
|
|
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
|
|
|
|
e.contiguous()
|
2022-02-23 14:38:58 +00:00
|
|
|
|
Consistent compute numel/contiguous strategy with SymInts (#85858)
Previously, our handling for contiguity was inconsistent in the following ways:
- is_strides_like 2d/3d and is_non_overlapping_and_dense always were computed
based on sizes_and_strides_, even if you had symbolic ints
- Furthermore, even if you set custom policy for strides, these quantities were
not overridable by subclasses
- Furthermore, we didn't even store these fields on ExtraMeta
- We duplicate implementations of compute_contiguous (plain, channels last,
channels last 3d)
- We inconsistently called refresh_numel()/refresh_contiguous(), versus
recomputing it ourselves
This factor makes a consistent strategy for all of the boolean fields, and
for numel computation. After this refactor:
- All layout boolean fields are interposable via strides policy
and can be overridden from Python; you will never access a garbage field
- All layout boolean fields are on ExtraMeta
- You can always call refresh_numel/contiguous, no matter if your Tensor is
contiguous or not
- The numel/layout boolean fields are always populated consistently with
the sizes strides fields (either on Tensor or ExtraMeta), even if you
have custom policy
- There is only one implementation of the actual computation logic
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision: [D39907696](https://our.internmc.facebook.com/intern/diff/D39907696)
Pull Request resolved: https://github.com/pytorch/pytorch/pull/85858
Approved by: https://github.com/albanD
2022-09-30 17:01:35 +00:00
|
|
|
def test_fancy_strides(self):
|
|
|
|
|
calls = []
|
|
|
|
|
|
|
|
|
|
class ExampleTensor(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, False, dispatch_sizes_strides_policy="strides")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func in [
|
|
|
|
|
torch.ops.aten.is_contiguous.default,
|
|
|
|
|
torch.ops.aten.is_contiguous.memory_format,
|
|
|
|
|
torch.ops.aten.is_strides_like_format.default,
|
|
|
|
|
torch.ops.aten.is_non_overlapping_and_dense.default,
|
|
|
|
|
torch.ops.aten.stride.default
|
|
|
|
|
]:
|
|
|
|
|
calls.append((func, list(args)[1:]))
|
|
|
|
|
return None
|
|
|
|
|
with no_dispatch():
|
|
|
|
|
return func(*args, **kwargs)
|
|
|
|
|
|
|
|
|
|
e = ExampleTensor(torch.randn(2, 2))
|
|
|
|
|
self.assertFalse(e.is_contiguous(memory_format=torch.channels_last))
|
|
|
|
|
self.assertEqual(calls, [(torch.ops.aten.is_contiguous.memory_format, [torch.channels_last])])
|
|
|
|
|
calls.clear()
|
|
|
|
|
self.assertFalse(torch.ops.aten.is_strides_like_format.default(e, torch.channels_last))
|
|
|
|
|
self.assertEqual(calls, [(torch.ops.aten.is_strides_like_format.default, [torch.channels_last])])
|
|
|
|
|
calls.clear()
|
|
|
|
|
self.assertTrue(torch.ops.aten.is_non_overlapping_and_dense.default(e))
|
|
|
|
|
self.assertEqual(calls, [(torch.ops.aten.is_non_overlapping_and_dense.default, [])])
|
|
|
|
|
|
2022-05-24 16:23:05 +00:00
|
|
|
def test_device_slowpath(self):
|
|
|
|
|
for use_wrapper_subclass in [True]:
|
|
|
|
|
class ExampleTensor1(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_device=True)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class ExampleTensor2(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_device=True)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.prim.device:
|
|
|
|
|
return torch.device('meta')
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class ExampleTensor3(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_device=True)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.prim.device:
|
|
|
|
|
return torch.device('meta')
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
err_msg = "no implementation found for 'torch.ops.prim.device'"
|
|
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
|
|
|
|
e = ExampleTensor1(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
e.device()
|
|
|
|
|
|
|
|
|
|
ten = torch.rand([1])
|
|
|
|
|
e = ExampleTensor2(torch.randn(3, 3, device='cpu'), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.device.type, 'meta')
|
|
|
|
|
self.assertEqual(ten.type_as(e).device.type, 'meta')
|
|
|
|
|
|
|
|
|
|
e = ExampleTensor3(torch.randn(3, 3, device='cpu'), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.device.type, 'meta')
|
|
|
|
|
self.assertEqual(ten.type_as(e).device.type, 'meta')
|
|
|
|
|
|
2022-06-02 16:45:17 +00:00
|
|
|
def test_dim_slowpath(self):
|
|
|
|
|
data = torch.randn(3, 3)
|
|
|
|
|
|
|
|
|
|
for use_wrapper_subclass in [True, False]:
|
|
|
|
|
class DimNotImplementedTensor(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="sizes")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class DimImplementedTensor(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="sizes")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.dim:
|
|
|
|
|
return data.dim()
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
err_msg = "no implementation found for 'torch.ops.aten.dim'"
|
|
|
|
|
e = DimNotImplementedTensor(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
|
|
|
|
e.dim()
|
|
|
|
|
|
|
|
|
|
t = DimImplementedTensor(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(t.dim(), 2)
|
|
|
|
|
|
2022-06-02 23:54:02 +00:00
|
|
|
def test_maybe_tuple_bug(self):
|
|
|
|
|
class T(torch.Tensor):
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_function__(cls, *args, **kwargs):
|
|
|
|
|
pass
|
|
|
|
|
a = torch.rand(3)
|
|
|
|
|
|
|
|
|
|
a[[T(), T()]]
|
2022-01-20 02:07:36 +00:00
|
|
|
|
2022-06-09 00:57:43 +00:00
|
|
|
def test_standard_is_not_subclass(self):
|
|
|
|
|
# https://github.com/pytorch/pytorch/issues/79079
|
|
|
|
|
self.assertFalse(torch._C._dispatch_isTensorSubclassLike(torch.empty(0)))
|
|
|
|
|
|
2022-06-10 03:02:28 +00:00
|
|
|
def test_strides_slow_path(self):
|
|
|
|
|
for use_wrapper_subclass in [True, False]:
|
|
|
|
|
class StridesNotImplemented(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="strides")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class StridesCustomReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="strides")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
2022-08-23 22:14:05 +00:00
|
|
|
if func == torch.ops.aten.sym_stride.default:
|
2022-06-10 03:02:28 +00:00
|
|
|
return (4, 2)
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class StridesDefaultReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="strides")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
2022-08-23 22:14:05 +00:00
|
|
|
if func == torch.ops.aten.sym_stride.default:
|
2022-06-10 03:02:28 +00:00
|
|
|
return None
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
2022-08-23 22:14:05 +00:00
|
|
|
err_msg = "no implementation found for 'torch.ops.aten.sym_stride'"
|
2022-06-10 03:02:28 +00:00
|
|
|
e = StridesNotImplemented(torch.randn(3, 3), use_wrapper_subclass)
|
2023-01-30 12:49:29 +00:00
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
2022-06-10 03:02:28 +00:00
|
|
|
e.stride()
|
|
|
|
|
|
|
|
|
|
e = StridesCustomReturn(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.stride(), (4, 2))
|
|
|
|
|
|
|
|
|
|
e = StridesDefaultReturn(torch.randn(6, 2), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.stride(), (2, 1))
|
|
|
|
|
|
2022-06-13 18:07:07 +00:00
|
|
|
def test_sizes_slow_path(self):
|
|
|
|
|
for use_wrapper_subclass in [True, False]:
|
|
|
|
|
data = torch.randn(6, 2)
|
|
|
|
|
|
|
|
|
|
class SizesNotImplemented(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="sizes")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.dim:
|
|
|
|
|
return data.dim()
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class SizesCustomReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="sizes")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.dim:
|
|
|
|
|
return data.dim()
|
2022-07-08 01:17:33 +00:00
|
|
|
if func.overloadpacket == torch.ops.aten.sym_size:
|
2022-06-13 18:07:07 +00:00
|
|
|
return (5, 3)
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class SizesDefaultReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="sizes")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.dim:
|
|
|
|
|
return data.dim()
|
2022-07-08 01:17:33 +00:00
|
|
|
if func.overloadpacket == torch.ops.aten.sym_size:
|
2022-06-13 18:07:07 +00:00
|
|
|
return None
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
2022-07-08 01:17:33 +00:00
|
|
|
err_msg = "no implementation found for 'torch.ops.aten.sym_size'"
|
2022-06-13 18:07:07 +00:00
|
|
|
e = SizesNotImplemented(torch.randn(3, 3), use_wrapper_subclass)
|
2023-01-30 12:49:29 +00:00
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
2022-06-13 18:07:07 +00:00
|
|
|
e.size()
|
|
|
|
|
|
|
|
|
|
e = SizesCustomReturn(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.size(), (5, 3))
|
|
|
|
|
|
|
|
|
|
e = SizesDefaultReturn(torch.randn(4, 2), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.size(), (4, 2))
|
|
|
|
|
|
2023-05-12 15:59:48 +00:00
|
|
|
def test_data_ptr_respects_numel_slow_path(self):
|
|
|
|
|
data = torch.randn(6, 2)
|
|
|
|
|
|
|
|
|
|
class NumelDefaultReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_sizes_strides_policy="sizes")
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.dim:
|
|
|
|
|
return data.dim()
|
|
|
|
|
if func.overloadpacket == torch.ops.aten.sym_numel:
|
|
|
|
|
numel_called[0] = True
|
|
|
|
|
return None
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
for use_wrapper_subclass in (False, True):
|
|
|
|
|
numel_called = [False]
|
|
|
|
|
e = NumelDefaultReturn(torch.randn(2, 2), use_wrapper_subclass)
|
|
|
|
|
e.data_ptr()
|
|
|
|
|
self.assertTrue(numel_called[0])
|
|
|
|
|
|
2022-07-05 16:43:21 +00:00
|
|
|
def test_layout_slow_path(self):
|
|
|
|
|
for use_wrapper_subclass in [True, False]:
|
|
|
|
|
data = torch.randn(6, 2)
|
|
|
|
|
|
|
|
|
|
class LayoutNotImplemented(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_layout=True)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class LayoutCustomReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_layout=True)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.prim.layout:
|
|
|
|
|
return torch.sparse_csr
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
class LayoutDefaultReturn(torch.Tensor):
|
|
|
|
|
@staticmethod
|
|
|
|
|
def __new__(cls, data, wrapper):
|
|
|
|
|
return TestPythonDispatch.subclass_helper(cls, data, wrapper, dispatch_layout=True)
|
|
|
|
|
|
|
|
|
|
@classmethod
|
|
|
|
|
def __torch_dispatch__(cls, func, types, args, kwargs):
|
|
|
|
|
if func.overloadpacket == torch.ops.prim.layout:
|
|
|
|
|
return data.layout
|
|
|
|
|
return NotImplemented
|
|
|
|
|
|
|
|
|
|
err_msg = "no implementation found for 'torch.ops.prim.layout'"
|
|
|
|
|
e = LayoutNotImplemented(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
with self.assertRaisesRegex(TypeError, err_msg):
|
|
|
|
|
e.layout
|
|
|
|
|
|
|
|
|
|
e = LayoutCustomReturn(torch.randn(3, 3), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.layout, torch.sparse_csr)
|
|
|
|
|
|
|
|
|
|
e = LayoutDefaultReturn(torch.randn(4, 2), use_wrapper_subclass)
|
|
|
|
|
self.assertEqual(e.layout, torch.strided)
|
|
|
|
|
|
2022-09-15 00:43:36 +00:00
|
|
|
class TestPythonDispatcher(TestCase):
|
|
|
|
|
def test_basic(self):
|
|
|
|
|
x = torch.randn(2, requires_grad=True)
|
|
|
|
|
r = torch._C._EnablePythonDispatcher()
|
|
|
|
|
torch.add(x, x)
|
|
|
|
|
|
2022-09-20 18:07:46 +00:00
|
|
|
def test_lstsq(self):
|
|
|
|
|
a = torch.randn(4, 3)
|
|
|
|
|
b = torch.rand(4, 3)
|
|
|
|
|
expected_shape = torch.linalg.lstsq(a, b).solution.shape
|
|
|
|
|
r = torch._C._EnablePythonDispatcher()
|
|
|
|
|
python_disp_shape = torch.linalg.lstsq(a, b).solution.shape
|
|
|
|
|
self.assertEqual(expected_shape, python_disp_shape)
|
|
|
|
|
|
2021-08-12 18:39:31 +00:00
|
|
|
if __name__ == '__main__':
|
Dispatch to Python via __torch_dispatch__ (#59760)
Summary:
Pull Request resolved: https://github.com/pytorch/pytorch/pull/59760
See https://github.com/pytorch/pytorch/issues/59049
There are some moving parts to this PR, I'll structure this explanation so the straightforward parts go first, and then the less straightforward parts.
**The actual dispatch to Python.** The core logic of dispatch to Python lives in `concrete_dispatch_fn` in `torch/csrc/autograd/python_variable.cpp`. It takes the input IValue stack, scans all the arguments for Tensor arguments, and defers most of the heavy lifting to `handle_torch_function_no_python_arg_parser` which actually does all of the logic for calling out to torch dispatch (in particular, this function handles multiple dispatch situations for you). Because we have a different function name than regular `__torch_function__` handling, `handle_torch_function_no_python_arg_parser` is generalized to accept a magic method name to look for when testing if Tensors have custom handling or not. Unlike `__torch_function__`, by default there is no `__torch_dispatch__` on Tensor classes.
**Maintaining the Python dispatch key.** In order to get to the dispatch to Python logic, we must tag Tensors with the `__torch_dispatch__` magic method with the newly added Python dispatch key (separated from PythonFuncTorch to allow for a transitional period while they migrate to this mechanism). We expose a new private property `_is_python_dispatch` that assists in debugging if a Tensor is participating in Python dispatch or not. We apply the Python dispatch key the first time a PyObject for a Tensor is constructed (THPVariable_NewWithVar), testing if `__torch_dispatch__` exists with then newly added `check_has_torch_dispatch`.
**Shallow copy and detach.** For the simple examples tested in this PR, most creations of Tensor route through the dispatcher. The exception to this is `shallow_copy_and_detach`, which bypasses the dispatcher and is used when saving tensors for backwards. When a Tensor is Python dispatch, we override the behavior of `shallow_copy_and_detach` to instead directly call into `__torch_dispatch__` to perform a `detach` operation (in the same way it would be invoked if you called `detach` directly). Because this Python call is triggered directly from c10::TensorImpl, it must be indirected through `PyInterpreter::detach`, which is the general mechanism for dynamic dispatching to the Python interpreter associated with a TensorImpl.
**torchdeploy compatibility.** The dispatch to Python logic cannot be directly registered to the dispatcher as it is compiled in the Python library, which will get loaded multiple times per torchdeploy interpreter. Thus, we must employ a two phase process. First, we register a fallback inside a non-Python library (aten/src/ATen/core/PythonFallbackKernel.cpp). Its job is to determine the appropriate PyInterpreter to handle the Python dispatch by going through all of the arguments and finding the first argument that has a PyObject/PyInterpreter. With this PyInterpreter, it makes another dynamic dispatch via "dispatch" which will go to the correct torchdeploy interpreter to handle dispatching to actual Python.
**Testing.** We provide a simple example of a LoggingTensor for testing, which can be used to generate TorchScript-like traces to observe what operations are being called when a Tensor is invoked. Although a LoggingTensor would be better implemented via an is-a relationship rather than a has-a relationship (as is done in the test), we've done it this way to show that arbitrarily complex compositions of tensors inside a tensor work properly.
**Known limitations.**
* We haven't adjusted any operator code, so some patterns may not work (as they lose the Python subclass in an unrecoverable way)
* `__torch_function__` must be explicitly disabled with `_disabled_torch_function_impl` otherwise things don't work quite correctly (in particular, what is being disabled is default subclass preservation behavior.)
* We don't ever populate kwargs, even when an argument is kwarg-only
Signed-off-by: Edward Z. Yang <ezyang@fb.com>
Differential Revision:
D29017912
D29017912
Test Plan: Imported from OSS
Reviewed By: bdhirsh
Pulled By: ezyang
fbshipit-source-id: a67714d9e541d09203a8cfc85345b8967db86238
2021-06-25 18:49:20 +00:00
|
|
|
run_tests()
|