gopikrsmscs/torch-issues huggingface dataset:
14k github models on PyTorch 2.0 pass rates dashboard 
Labels: triaged, oncall: pt2, module: dynamo

We are weekly running dynamo-eager, dynamo-eager-fullgraph, export and inductor on 14k ```nn.Modules``` crawled from 1.4k github projects to get coverage level, find and fix bugs. This dashboard page is used to track the pass rates of different backends. 

How to repro:
* Checkout https://github.com/jansel/pytorch-jit-paritybench
* Batch evaluation with different backends:
  * dynamo-eager: ```python main.py --backend eager```
  * dynamo-eager-fullgraph: ```python main.py --backend eager --fullgraph```
  * export: ```python main.py --compile_mode export```
  * inductor: ```python main.py```
* Adhoc evaluation:
  * ```pytest ./generated/{filename}.py -k test_{n}``` (e.g, ```pytest ./generated/test_KunpengLi1994_VSRN.py -k test_002```)
  * ```python -e ./generated/{filename}.py --backend eager```

Bugs umbrella task(#92670)

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh @voznesenskym @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire @davidberard98
ONNX exporter error
Labels: needs reproduction, module: onnx, triaged, onnx-needs-info

### 🐛 Describe the bug

when try to convert yolov5 weight from torch to ONNX, I got this error "**_RuntimeError: Expected all tensors to be on the same device, but found at least two devices, cpu and cuda:0! (when checking argument for argument weight in method wrapper___slow_conv2d_forward)_**" . I have checked and definitely that input tensor and model loaded on the same device (cuda).  This error was raised from line 216 of rpn.py in torchvision (r.append(top_n_idx + offset)). Someone can help me? Thank you for your help

### Versions

Collecting environment information...
PyTorch version: 1.11.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.4 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: version 3.24.0
Libc version: glibc-2.31

Python version: 3.8.13 (default, Mar 28 2022, 11:38:47)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.13.0-41-generic-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: 11.2.152
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 2080
Nvidia driver version: 515.43.04
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.4.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.4.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.4.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.4.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.4.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.4.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.4.0
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.22.4
[pip3] torch==1.11.0
[pip3] torch-tensorrt==1.1.0
[pip3] torch2trt==0.4.0
[pip3] torchsummary==1.5.1
[pip3] torchvision==0.12.0
[conda] numpy                     1.22.4                   pypi_0    pypi
[conda] torch                     1.11.0                   pypi_0    pypi
[conda] torch-tensorrt            1.1.0                    pypi_0    pypi
[conda] torch2trt                 0.4.0                    pypi_0    pypi
[conda] torchsummary              1.5.1                    pypi_0    pypi
[conda] torchvision               0.12.0                   pypi_0    pypi
Batch multiplication for torch.sparse matrix multiplication
Labels: module: sparse, triaged, module: linear algebra

### 🚀 The feature, motivation and pitch

In the same way, there is a batchwise multiplication for ```torch.mm``` named ```torch.bmm``` I would appreciate if you would add a **batchwise multiplication** for ```torch.sparse.mm``` and ```torch.sparse.addmm``` that creates a sparse gradient. 



### Alternatives

_No response_

### Additional context

The sparse functions can be found ```[here](https://pytorch.org/docs/stable/sparse.html)```

cc @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jianyuh @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
MPS: allow selecting specific MTLDevice by registryID via environment variable
Labels: triaged, enhancement, module: mps

### 🚀 The feature, motivation and pitch

Hello :wave: _very_ new to pytorch and running it on both M1 macs and on a mac with a couple Radeons.

I would like to be able to use more than one of the Radeons at times (in different processes), or to select one specifically so I can use the other GPU for other tasks while I work on other things, etc.

I think this should (hopefully?) be pretty trivial -- I'm not familiar enough with the build system and intricacies of conda/pip etc to have run a build just yet, but I have a draft PR on my fork here:
https://github.com/jaeschliman/pytorch/pull/1

Open to any changes, pointers, etc.

Thanks!

### Alternatives

At first considered selecting by peerGroup and peerIndex, but Apple's docs state that registryID is stable across processes, so it looks like the correct choice.

### Additional context

https://developer.apple.com/documentation/metal/mtldevice/2915737-registryid?language=objc

cc @kulinseth @albanD
compiling failed from source
Labels: module: sparse, module: build, module: cuda, triaged

### 🐛 Describe the bug

I wanna install pytorch from source. When I began to compile , build process stopped as following :
![image](https://user-images.githubusercontent.com/73052387/189466551-6dc30a24-fc90-4922-8933-ac90e15ba162.png)


### Versions

in conda:

cudatoolkit 11.2.72
magma-cuda112 2.5.2

system:
cuda 11.2
driver 460.32.03


cc @nikitaved @pearu @cpuhrsch @amjames @bhosmer @malfet @seemethere @ngimel
Allow passing dict (as opposed to OrderedDict) to nn.Sequential
Labels: module: nn, triaged, needs research

Feature request: `torch.nn.Sequential` now accepts `collection.OrderedDict` as a way of naming the modules it contains. However, since vanilla `dict` is ordered in python>=3.7 and pytorch currently targets python>=3.7, passing a `dict` should be accepted (ideally, any map str->nn.Module). Currently this throws an error (nn.Sequential insists on collections.OrderedDict).

cc @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
Use graph partitioner to remove ops that can be captured with cudagraphs in TorchInductor
Labels: triaged, oncall: pt2

Currently, in TorchInductor cudagraphs usage is all-or-nothing. This test decided if we use it:
https://github.com/pytorch/torchdynamo/blob/116ae7f868fc46c197cb08094f3117525d1b9de8/torchinductor/compile_fx.py#L63-L68

This could lead to some performance cliffs where adding a single bad op to your graph flips off cudagraphs and hurts performance for unrelated ops.

We should try partitioning the graph to allow using cudagraphs on fragments where it is supported.  Many of the huggingface models use CPU tensors, which forces cudagraphs off.  It possible we could see some speedups there.

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
PyTorch-DirectML RFC
Labels: feature, triaged

### 🚀 The feature, motivation and pitch

We propose to add a DirectML backend as an out-of-tree plugin extension for PyTorch. The DirectML backend will provide hardware acceleration across all DirectX12 compatible GPUs for Windows and the Windows Subsystem for Linux. The RFC PR can be found here: https://github.com/pytorch/rfcs/pull/46. 

### Alternatives

_No response_

### Additional context

_No response_
Test aten decompositions match their alias information
Labels: triaged, better-engineering, module: primTorch

Came up in discussion with @samdow and @Chillee.

Given an aten operator that has some schema, its decomposition should match the schema's alias information. For example, an out-of-place operation like at::sin must not mutate its input or return a Tensor whose storage aliases the input's.

We have decompositions of ATen operators somewhere in the codebase. We also have decomposition OpInfo tests. So this issue is just to add additional checks that an operator's decomposition is faithful to its schema 

cc @ezyang @mruberry @ngimel @Lezcano @fdrocha
Explore TBB for TorchInductor C++ backend
Labels: triaged, oncall: pt2, module: cpu inductor

Currently, the TorchInductor C++ backend uses OpenMP, though especially for small kernels there is pretty high warmup time to launch threads.  And we have seen our 1-thread performance give bigger speedups over eager than our N-thread performance.

[Thread Building Blocks](https://www.intel.com/content/www/us/en/developer/tools/oneapi/onetbb.html) might deliver better performance here, so we should explore it as an alternative.

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Add documentation about backward graph gc behavior
Labels: module: docs, triaged

### 📚 The doc issue

At least add documentation about
> pyobject traversal only travels one-hop into the backward graph past the tensor, so appending that extra node to the graph prevents gc from clearing the cycle.

_Originally posted by @soulitzer in https://github.com/pytorch/pytorch/issues/84413#issuecomment-1234817185_

And add link to this in `checkpoint` documentation.

### Suggest a potential alternative/fix

_No response_

cc @svekars @holly1238
About the different ways to print models
Labels: module: printing, triaged

### 🐛 Describe the bug

Hi. I seem to have found a bug in a print model

```
import torchvision.models as models
vgg = models.vgg16( pretrained=True)
net = vgg.features[0:1]
print(net)

net[0].out_channels = 32
print(net)          # Note: the bug is here, the result should not be Conv2d(3, 32, kernel_size=(3, 3), stride=(1, 1), padding=(1, 1))

# The following results
# torch.Size([64, 3, 3, 3])  torch.Size([64])
for parameters in net.parameters():
    print(parameters.shape)

summary(net ,(3,112,112))
```

### Versions

```
Collecting environment information...
PyTorch version: 1.9.0
Is debug build: False
CUDA used to build PyTorch: 11.1
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.5 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.10

Python version: 3.7.10 (default, Feb 26 2021, 18:47:35)  [GCC 7.3.0] (64-bit runtime)
Python platform: Linux-4.15.0-142-generic-x86_64-with-debian-buster-sid
Is CUDA available: True
CUDA runtime version: 11.1.105
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3060
Nvidia driver version: 515.48.07
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] info-nce-pytorch==0.1.4
[pip3] numpy==1.20.3
[pip3] numpy-quaternion==2022.4.2
[pip3] torch==1.9.0
[pip3] torchelastic==0.2.0
[pip3] torchtext==0.10.0
[pip3] torchvision==0.10.0
[conda] blas                      1.0                         mkl
[conda] cudatoolkit               11.1.74              h6bb024c_0    nvidia
[conda] info-nce-pytorch          0.1.4                    pypi_0    pypi
[conda] mkl                       2021.4.0           h06a4308_640
[conda] mkl-service               2.4.0            py37h7f8727e_0
[conda] mkl_fft                   1.3.1            py37hd3c417c_0
[conda] mkl_random                1.2.2            py37h51133e4_0
[conda] numpy                     1.20.3                   pypi_0    pypi
[conda] numpy-quaternion          2022.4.2                 pypi_0    pypi
[conda] pytorch                   1.9.0           py3.7_cuda11.1_cudnn8.0.5_0    pytorch
[conda] torchelastic              0.2.0                    pypi_0    pypi
[conda] torchtext                 0.10.0                     py37    pytorch
[conda] torchvision               0.10.0               py37_cu111    pytorch```
Set dtype if tensor converted to numpy
Labels: needs reproduction, triaged, module: numpy

### 🚀 The feature, motivation and pitch

Currently I have tensors which I need to convert and then subtract them. If I subtract in torch, I get a vector with entries unequal zero. But I subtract the converted tensors in numpy, I get a zero tensor. 

Very likely it is caused by precision loss in the conversion.

So I like to fix the dtype when I use tensor.numpy(), which might solve the issue.

### Alternatives

_No response_

### Additional context

_No response_

cc @mruberry @rgommers
test_public_bindings is not robust to various build options
Labels: triaged, topic: build

After building pytorch with USE_DISTRIBUTED=0, test_public_bindings fails locally with:
```
======================================================================
ERROR: test_correct_module_names (__main__.TestPublicBindings)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test/test_public_bindings.py", line 370, in test_correct_module_names
    for _, modname, ispkg in pkgutil.walk_packages(path=torch.__path__, prefix=torch.__name__ + '.'):
  File "/raid/rzou/pt/workspace-env/lib/python3.7/pkgutil.py", line 107, in walk_packages
    yield from walk_packages(path, info.name+'.', onerror)
  File "/raid/rzou/pt/workspace-env/lib/python3.7/pkgutil.py", line 107, in walk_packages
    yield from walk_packages(path, info.name+'.', onerror)
  File "/raid/rzou/pt/workspace-env/lib/python3.7/pkgutil.py", line 92, in walk_packages
    __import__(info.name)
  File "/raid/rzou/pt/workspace/torch/distributed/algorithms/_comm_hooks/__init__.py", line 2, in <module>
    from . import default_hooks as default
  File "/raid/rzou/pt/workspace/torch/distributed/algorithms/_comm_hooks/default_hooks.py", line 6, in <module>
    class DefaultState(object):
  File "/raid/rzou/pt/workspace/torch/distributed/algorithms/_comm_hooks/default_hooks.py", line 24, in DefaultState
    process_group: dist.ProcessGroup
AttributeError: module 'torch.distributed' has no attribute 'ProcessGroup'

----------------------------------------------------------------------
```
It would be nice for test_public_bindings to ignore distributed if it wasn't built.
JIT will affect the gradient computation of forward mode
Labels: oncall: jit

### 🐛 Describe the bug

JIT will affect the gradient computation of forward mode for some API

For example, if we directly call `jit_fn` with forward mode, it will output the correct gradient:

```py
import torch

def fn(input, target):
    weight = None
    reduction = "mean"
    return torch.nn.functional.multilabel_soft_margin_loss(input, target, weight=weight, reduction=reduction, )

input = torch.tensor([[1., 1.]], dtype=torch.float32)
target = torch.tensor([[2., 2.]], dtype=torch.float32)

inputs1 = (input.clone().requires_grad_(), target.clone().requires_grad_())
inputs2 = (input.clone().requires_grad_(), target.clone().requires_grad_())

jit_fn = torch.jit.trace(fn, (input, target))
print(torch.autograd.functional.jacobian(jit_fn, inputs2, vectorize=True, strategy='forward-mode'))
# [tensor([[-0.6345, -0.6345]], grad_fn=<ReshapeAliasBackward0>), tensor([[-0.5000, -0.5000]], grad_fn=<ReshapeAliasBackward0>)
```

However, if we call `jit_fn(*inputs1)` before the gradient computation in forward mode with `inputs2`, the gradient will be all 0, which is wrong

```py
import torch

def fn(input, target):
    weight = None
    reduction = "mean"
    return torch.nn.functional.multilabel_soft_margin_loss(input, target, weight=weight, reduction=reduction, )

input = torch.tensor([[1., 1.]], dtype=torch.float32)
target = torch.tensor([[2., 2.]], dtype=torch.float32)

inputs1 = (input.clone().requires_grad_(), target.clone().requires_grad_())
inputs2 = (input.clone().requires_grad_(), target.clone().requires_grad_())


jit_fn = torch.jit.trace(fn, (input, target))
jit_fn(*inputs1)
print(torch.autograd.functional.jacobian(jit_fn, inputs2, vectorize=True, strategy='forward-mode'))
# [tensor([[0., 0.]]), tensor([[0., 0.]])]
```

Interestingly, this cannot affect the gradient computation in reverse mode.

Many APIs suffer from this problem, like `lp_pool1d`


### Versions

pytorch: 1.12.1
Autograd will take `init` module API into account when using `jit`
Labels: oncall: jit

### 🐛 Describe the bug

As mentioned in doc,
> All the functions in this module (`init`) are intended to be used to initialize neural network parameters, so they all run in :func:`torch.no_grad` mode and will not be taken into account by autograd.

However, autograd will take `init` module API into account when using `jit`.

```py
import torch

def fn(input):
    return torch.nn.init.ones_(input)

input = torch.rand([4])
jit_fn = torch.jit.trace(fn, (input.clone(), ))

fn(input.clone().requires_grad_()) # work
jit_fn(input.clone().requires_grad_())
# RuntimeError: a leaf Variable that requires grad is being used in an in-place operation.
```

### Versions

pytorch: 1.12.1
Support FP16 with torch._fake_quantize_learnable_per_channel_affine & torch._fake_quantize_learnable_per_tensor_affine
Labels: oncall: quantization, triaged

### 🚀 The feature, motivation and pitch

The PyTorch operators `torch._fake_quantize_learnable_per_channel_affine` and `torch._fake_quantize_learnable_per_tensor_affine` currently only support `torch.float32` datatypes, while the non-learnable scale operators `torch.fake_quantize_per_channel_affine` and `torch.fake_quantize_per_tensor_affine` support more datatypes (ie torch.float16).  This makes using the learnable scale fake quantization operators break some pipelines which use CUDA mixed precision training, and otherwise breaks the consistency between the learnable and non-learnable scale fake quantize operators.

The non-learnable scale fake quantize operators originally only supported `torch.float32` (see [this issue ](https://github.com/pytorch/pytorch/issues/50417) that ran into this problem, and [this issue](https://github.com/pytorch/pytorch/issues/42351) which tracked the implementation of more datatypes).  I'd like to know if there is a timeline to expand support for extra datatypes for the learnable scale fake quantization operators as well.

### Alternatives

_No response_

### Additional context

_No response_

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
JIT script calculation/dtype inconsistent depending on operator expression
Labels: oncall: jit

### 🐛 Describe the bug

In the following simple snippet, we expect `sum_terms` to be equal to `one_expression` (both have all entries -1), and that is indeed the case in the python interpreter. With the `@torch.jit.script` decorator, that is no longer the case, indicating a bug with the JIT compiler.

```
import torch

@torch.jit.script  # code works as expected if decorator is removed
def func(a, b):
    term_1 = 1 * (a & b)
    term_2 = -1 * (a != b)
    sum_terms = term_1 + term_2
    one_expression = 1 * (a & b) - 1 * (a != b)
    # workaround
    # one_expression = (a & b).to(torch.int64) - (a != b).to(torch.int64)
    print(sum_terms == one_expression)


a = torch.zeros(10, dtype=bool, device='cuda')
b = torch.ones(10, dtype=bool, device='cuda')
func(a, b)
```

This might have to do with the inconsistent types yielded, `term_1` of `CUDABoolType{10}` whereas `term_2` of `CUDALongType{10}`.

Also in this minimal version, I get the following error. But in my original programme containing identical code I don't--only the values are wrong (all entries 1 instead of -1). I have yet to figure out why the RuntimeError occurs in only one of the two.

```
Traceback (most recent call last):
  File "test.py", line 22, in <module>
    func(a, b)
RuntimeError: The following operation failed in the TorchScript interpreter.
Traceback of TorchScript (most recent call last):
  File "test.py", line 15, in func
        1 * (a & b) - 1 * (a != b),
    )
    one_expression = 1 * (a & b) - 1 * (a != b)
                     ~~~~~~~~~~~~~~~~~~~~~~~~~ <--- HERE
    print(sum_terms == one_expression)
RuntimeError: Subtraction, the `-` operator, with two bool tensors is not supported. Use the `^` or `logical_xor()` operator instead.
```


### Versions

```
Collecting environment information...
PyTorch version: 1.12.0+cu102
Is debug build: False
CUDA used to build PyTorch: 10.2
ROCM used to build PyTorch: N/A

OS: Ubuntu 20.04.5 LTS (x86_64)
GCC version: (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: glibc-2.31

Python version: 3.8.10 (default, Jun 22 2022, 20:18:18)  [GCC 9.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-46-generic-x86_64-with-glibc2.29
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 2080 Ti
Nvidia driver version: 515.65.01
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.23.1
[pip3] torch==1.12.0
[pip3] torchvision==0.13.0
[conda] Could not collect
```
torch.nn.functional.interpolate fails on some degenerate shapes, but passes on others
Labels: triaged, module: interpolation

Not sure if this can be counted as bug or not. If you have an input with an empty batch dimension, everything works fine

```py
>>> t = torch.rand(0, 3, 16, 16)
>>> interpolate(t, (15, 17))
tensor([], size=(0, 3, 15, 17))
```

If any other dimension is zero, it will throw an error:

```py
>>> t = torch.rand(4, 0, 16, 16)
>>> interpolate(t, (15, 17))
RuntimeError: Non-empty 4D data tensor expected but got a tensor with sizes [4, 0, 16, 16]
>>> t = torch.rand(4, 3, 0, 16)
>>> interpolate(t, (15, 17))
RuntimeError: Input and output sizes should be greater than 0, but got input (H: 0, W: 16) output (H: 15, W: 17)
>>> t = torch.rand(4, 3, 16, 0)
>>> interpolate(t, (15, 17))
RuntimeError: Input and output sizes should be greater than 0, but got input (H: 16, W: 0) output (H: 15, W: 17)
```

The latter two are somewhat understandable. Still, since no interpolation will happen in either case, shouldn't we align the behavior?
INTERNAL ASSERT when the type of argument is not considered in JIT
Labels: oncall: jit

### 🐛 Describe the bug

INTERNAL ASSERT when the type of argument is not considered in JIT. For example, some argument may be fed with boolean, but `torch.jit.trace` doesn't consider such cases and output INTERNAL ASSERT directly

```py
import torch

def fn(input):
    return torch.add(input, other=True)
input = torch.tensor([1.])

fn(input) # tensor([2.])
jit_fn = torch.jit.trace(fn, input)
```

```
RuntimeError: 0INTERNAL ASSERT FAILED at "/opt/conda/conda-bld/pytorch_1646756402876/work/torch/csrc/jit/ir/alias_analysis.cpp":607, please report a bug to PyTorch. We don't have an op for aten::add but it isn't a special case.  Argument types: Tensor, bool, int, 

Candidates:
	aten::add.Tensor(Tensor self, Tensor other, *, Scalar alpha=1) -> (Tensor)
	aten::add.Scalar(Tensor self, Scalar other, Scalar alpha=1) -> (Tensor)
	aten::add.out(Tensor self, Tensor other, *, Scalar alpha=1, Tensor(a!) out) -> (Tensor(a!))
	aten::add.t(t[] a, t[] b) -> (t[])
	aten::add.str(str a, str b) -> (str)
	aten::add.int(int a, int b) -> (int)
	aten::add.complex(complex a, complex b) -> (complex)
	aten::add.float(float a, float b) -> (float)
	aten::add.int_complex(int a, complex b) -> (complex)
	aten::add.complex_int(complex a, int b) -> (complex)
	aten::add.float_complex(float a, complex b) -> (complex)
	aten::add.complex_float(complex a, float b) -> (complex)
	aten::add.int_float(int a, float b) -> (float)
	aten::add.float_int(float a, int b) -> (float)
	aten::add(Scalar a, Scalar b) -> (Scalar)
...
		aten::add.complex_float(complex a, float b) -> (complex)
		aten::add.int_float(int a, float b) -> (float)
		aten::add.float_int(float a, int b) -> (float)
		aten::add(Scalar a, Scalar b) -> (Scalar)
```

It seems that many APIs suffer from this issue, such as `ne, le, ge, div, mul, ...`

### Versions

pytorch: 1.12.1
Beta distribution behaves incorrectly for small parameters
Labels: module: distributions, triaged, module: edge cases

### 🐛 Describe the bug

The `Beta(alpha, alpha)` distribution should converge to `Bernoulli(0.5)` as `alpha -> 0`. However, we get a `Dirac(0.5)`, which is what we expect for `alpha -> infty` (last line, correct).

```python
import torch

print("Torch version:", torch.__version__)

torch.manual_seed(0)

beta = torch.distributions.Beta(1e-3, 1e-3)
print("Sample from Beta(1e-6, 1e-6):", beta.sample())

beta = torch.distributions.Beta(1e3, 1e+3)
print("Sample from Beta(1e+3, 1e+3):", beta.sample())
```

Gives:

```
Torch version: 1.12.1
Sample from Beta(1e-6, 1e-6): tensor(0.5000)
Sample from Beta(1e+3, 1e+3): tensor(0.4966)
```

### Versions

```
Collecting environment information...
PyTorch version: 1.12.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5.1 (x86_64)
GCC version: Could not collect
Clang version: 13.1.6 (clang-1316.0.21.2.5)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.7 (default, Sep 16 2021, 08:50:36)  [Clang 10.0.0 ] (64-bit runtime)
Python platform: macOS-10.16-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.22.4
[pip3] numpydoc==1.1.0
[pip3] pytorch-ignite==0.4.9
[pip3] torch==1.12.1
[pip3] torchaudio==0.12.1
[pip3] torchmetrics==0.9.3
[pip3] torchvision==0.13.1
[conda] blas                      1.0                         mkl  
[conda] ffmpeg                    4.3                  h0a44026_0    pytorch
[conda] mkl                       2021.4.0           hecd8cb5_637  
[conda] mkl-service               2.4.0            py39h9ed2024_0  
[conda] mkl_fft                   1.3.1            py39h4ab4a9b_0  
[conda] mkl_random                1.2.2            py39hb2f4e1b_0  
[conda] numpy                     1.22.4                   pypi_0    pypi
[conda] numpydoc                  1.1.0              pyhd3eb1b0_1  
[conda] pytorch                   1.12.1                  py3.9_0    pytorch
[conda] pytorch-ignite            0.4.9                    pypi_0    pypi
[conda] torchaudio                0.12.1                 py39_cpu    pytorch
[conda] torchmetrics              0.9.3                    pypi_0    pypi
[conda] torchvision               0.13.1                 py39_cpu    pytorch
```

cc @fritzo @neerajprad @alicanb @nikitaved
torch.hub.load local model
Labels: triaged, module: hub

### 🐛 Describe the bug

python code:
```
model_name = 'x3d_m'
# model = torch.hub.load('facebookresearch/pytorchvideo', model_name, pretrained=True)
model = torch.hub.load('/Users/kpinfo/.cache/torch/hub/pytorch_vision_master/', model_name, source='local')
```
error:
```
ImportError: cannot import name 'get_model_weights' from 'torchvision.models
```
 I have run "model = torch.hub.load('facebookresearch/pytorchvideo', model_name, pretrained=True)" well. But sometimes it will stuck and exit for timeout. I find x3d_m model have load in "/Users/kpinfo/.cache/torch/hub/checkpoints/X3D_M.pyth" , and I want load this local model when I need x3d model next time.


### Versions

Collecting environment information...
PyTorch version: 1.11.0
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 10.15.2 (x86_64)
GCC version: Could not collect
Clang version: 11.0.3 (clang-1103.0.32.62)
CMake version: Could not collect
Libc version: N/A

Python version: 3.7.11 (default, Jul 27 2021, 07:03:16)  [Clang 10.0.0 ] (64-bit runtime)
Python platform: Darwin-19.2.0-x86_64-i386-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] efficientnet-pytorch==0.7.1
[pip3] mypy-extensions==0.4.3
[pip3] numpy==1.21.6
[pip3] pytorchvideo==0.1.3
[pip3] torch==1.11.0
[pip3] torchaudio==0.11.0
[pip3] torchvision==0.12.0
[conda] efficientnet-pytorch      0.7.1                    pypi_0    pypi
[conda] numpy                     1.21.6                   pypi_0    pypi
[conda] pytorchvideo              0.1.3                    pypi_0    pypi
[conda] torch                     1.11.0                   pypi_0    pypi
[conda] torchaudio                0.11.0                   pypi_0    pypi
[conda] torchvision               0.12.0                   pypi_0    pypi

cc @nairbv @NicolasHug @vmoens @jdsgomes
Autogenerated out functions are missing at::cpu:: and co bindings
Labels: triaged, module: codegen, topic: build

### 🐛 Describe the bug

Example: look at `build/aten/src/ATen/ops/prod_cpu_dispatch.h`. On my build it looks like

```
TORCH_API at::Tensor prod(const at::Tensor & self, c10::optional<at::ScalarType> dtype=c10::nullopt);
TORCH_API at::Tensor prod(const at::Tensor & self, int64_t dim, bool keepdim=false, c10::optional<at::ScalarType> dtype=c10::nullopt);
TORCH_API at::Tensor & prod_out(at::Tensor & out, const at::Tensor & self, int64_t dim, bool keepdim=false, c10::optional<at::ScalarType> dtype=c10::nullopt);
TORCH_API at::Tensor & prod_outf(const at::Tensor & self, int64_t dim, bool keepdim, c10::optional<at::ScalarType> dtype, at::Tensor & out);
```

However, notice that there are two functional overloads, but only one `prod_out` overload. We're missing the Tensor, ScalarType overload for out.

This is affecting static runtime.

cc @bhosmer @bdhirsh @d1jang @tenpercent 

### Versions

master
Serialize the warmed up torchscript module
Labels: oncall: jit

### 🚀 The feature, motivation and pitch

- JIT and torchscript can provide a huge performance boost for models, but the long warm-up time for large models like stable diffusion unet(~90s) can be a huge blocker for production, even individual use
- If there could be a way of serializing the warmed-up module (even with limitation that needs to be run on specific hardware), would be super helpful

### Alternatives

- Tried to `torch._C._jit_set_profiling_executor(False) eliminates the extra recompilations` but this eliminates performance gain

### Additional context

_No response_
Capture scalar outputs / dynamically sized outputs by default, partition graphs for backends that can't handle it
Labels: triaged, ezyang's list, oncall: pt2, module: dynamic shapes

Capturing scalar outputs improves perf e.g. by capturing the optimizer. Now that the fx subgraph capability matcher has landed, it should be easy for backends which do not support scalars to compile subgraphs even with this config turned on. Additionally, having a config option be off by default means its test coverage is extremely limited. 

cc @ezyang @soumith @msaroufim @wconstab @ngimel @bdhirsh
Accept SymInts and SymFloats For Scalar Inputs
Labels: triaged

### 🚀 The feature, motivation and pitch

When we are a tracing context  (ProxyTensor/FakeTensor/TorchDynamo) tensor -> scalar conversions can cause graph breaks because the tracking tensors do not have real data associated with them. This can occur with user invocations: `x.item()` and in implicit Tensor->Scalar conversions when a 0-element tensor is passed in as a `Scalar` argument. 

ProxyTensor and FakeTensor do some amount of [constant](https://github.com/pytorch/pytorch/pull/84387) tracking for cases where the value of the 0-element tensor is known statically, but there are other cases where this will occur. 

For example, in [adagrad](https://github.com/pytorch/pytorch/blob/master/torch/optim/adagrad.py#L279): `param.addcdiv_(grad, std, value=-clr)`

`addcdiv` has the signature: `addcdiv(Tensor self, Tensor tensor1, Tensor tensor2, *, Scalar value=1) -> Tensor`.  When the config capture_scalar_outputs is true, `-clr` will be a 0-element tensor, and the dispatcher call of _local_scalar_dense in converting `-clr` to a scalar will cause a graph break. 

If Scalars could contain SymInts/Symfloats, `-clr` could be returned from `_local_scalar_dense` as a SymFloat without graph breaking. 

More generally, this might allow us to re-factor the "capture scalar inputs" config to work by tracing SymInts/Symfloats instead of wrapping scalars to tensors, and potentially track other dynamic shape operations that occur from indexing tensor data.
Uneven and/or Dynamically sized collectives
Labels: good first issue, triaged, module: c10d

### 🚀 The feature, motivation and pitch

A recurring question we get is how to handle uneven or dynamic sized collectives.

For example, users want to:

- Scatter tensors of different sizes.
- Dynamically determine broadcast tensor sizes on the source rank.

There are plenty of forum questions on this subject that validate the need for such new API.

In addition to be a constant source of problem for our users, such APIs are particularly difficult to efficiently and correctly implement when using NCCL. This stems from the fact that shape calculation happens on CPU but values must transit in CUDA tensors as NCCL doesn't support CPU tensors.

This device mismatch issue is not trivial and resulted in quite a few bugs in c10d's object collectives.

## The API

Add a `torch.distributed.dynamic` package that supports slower collectives that are significantly flexible and address those concerns.

The overall design of those collectives is that they should not assume perfect uniform knowledge across all ranks.

The module would have variants of broadcast, all_gather, gather, scatter, all_to_all that can handle dynamic and uneven tensor sizes transparently for users.

It's unclear whether we should extend this to reduce collectives as we'd have to deal with the issue of missing data.



### Alternatives

Not implement this module and keep suggesting work-arounds to users.

### Additional context

Data-dependent collective shapes is particularly common with models that employ sparse-computation like Mixture-of-Experts.
torch.jit.script IndentationError: unexpected indent
Labels: oncall: jit

### 🐛 Describe the bug

```
import torch
import torchvision
import torchvision.models as models
import torch.nn as nn
from torch.utils.mobile_optimizer import optimize_for_mobile

class ModifiedResNet18Model(torch.nn.Module):
	def __init__(self):
		super(ModifiedResNet18Model, self).__init__()
		model = models.resnet18(pretrained=True)
		modules = list(model.children())[:-1]      
		model = nn.Sequential(*modules)
		self.features = model

		for param in self.features.parameters():
			param.requires_grad = False

		self.fc = nn.Sequential(
			nn.Dropout(),
			nn.Linear(512,1024),
			nn.ReLU(inplace=True),
                        nn.Dropout(),
			nn.Linear(1024,512),
			nn.ReLU(inplace=True),
			nn.Linear(512, 4))
	
	def forward(self, x):
		x = self.features(x)
		x = nn.functional.adaptive_avg_pool2d(x, 1).reshape(x.shape[0], -1)
		x = self.fc(x)
		return x
		
		

model = ModifiedResNet18Model()
print(model)
model_scripted = torch.jit.script(model) # throwing the error
opti_model = optimize_for_mobile(model_scripted)
opti_model._save_for_lite_interpreter("resnet4.ptl")
print('Create Model Success')



```

### Versions

Torch  Version: 1.11.0+cu113
TorchVision  Version: 0.12.0+cu113

**Error** 
Traceback (most recent call last):
  File "C:\Users\Visionhealth\Desktop\Experiment_3\onlyforpruning\testtorchscript.py", line 37, in <module>
    model_scripted = torch.jit.script(model)
  File "C:\Users\Visionhealth\AppData\Local\Programs\Python\Python310\lib\site-packages\torch\jit\_script.py", line 1265, in script
    return torch.jit._recursive.create_script_module(
  File "C:\Users\Visionhealth\AppData\Local\Programs\Python\Python310\lib\site-packages\torch\jit\_recursive.py", line 453, in create_script_module
    AttributeTypeIsSupportedChecker().check(nn_module)
  File "C:\Users\Visionhealth\AppData\Local\Programs\Python\Python310\lib\site-packages\torch\jit\_check.py", line 74, in check
    init_ast = ast.parse(textwrap.dedent(source_lines))
  File "C:\Users\Visionhealth\AppData\Local\Programs\Python\Python310\lib\ast.py", line 50, in parse
    return compile(source, filename, mode, flags,
  File "<unknown>", line 1
    def __init__(self):
IndentationError: unexpected indent
module: multiprocessing SimpleQueue put cannot bigger 716 in windows.And it is not has any info.The program is blocked and does not move.
Labels: module: multiprocessing, triaged

### 🐛 Describe the bug

#run the code.It is not has any info,and not work.
#python3.9.13 64-bit windows10  torch1.12.1+cu116
#the last code is connection.py  line 205          self._send_bytes(m[offset:offset + size])

from torch import multiprocessing as mp
ctx = mp.get_context("spawn")
free_queue = ctx.SimpleQueue()
full_queue = ctx.SimpleQueue()


for m in range(1536):
    print("put data index:",m)
    if(m==716):
        print("The program is blocked and does not move in 716.")
    free_queue.put(m)
print("It is not go end.")

### Versions

Collecting environment information...
PyTorch version: 1.12.1+cu116
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 家庭中文版
GCC version: (GCC) 5.3.0
Clang version: Could not collect
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.13 (tags/v3.9.13:6de2ca5, May 17 2022, 16:36:42) [MSC v.1929 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.19044-SP0
Is CUDA available: True
CUDA runtime version: 11.7.64
GPU models and configuration: GPU 0: NVIDIA GeForce GTX 1070
Nvidia driver version: 516.59
cuDNN version: C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v11.7\bin\cudnn_ops_train64_8.dll
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.23.2
[pip3] torch==1.12.1+cu116
[pip3] torch-tb-profiler==0.4.0
[pip3] torchaudio==0.12.1+cu116
[pip3] torchvision==0.13.1+cu116
[conda] Could not collect

cc @VitalyFedyunin
Tensor slice copy across multiple devices fails silently
Labels: triaged, module: advanced indexing

### 🐛 Describe the bug

When trying to update certain elements between two tensors with the source on GPU memory and the target on CPU memory, the .copy_ operation fails silently. Below is an example:

```
import torch as pt

dims = (4,5,)
gpu0 = pt.device(0)

# src and tgt matrices...src on gpu0...target on CPU
src = pt.randn(*dims).to(gpu0)
tgt = pt.zeros(dims)

# mask and idxs
mask = src > 0                     # sample function...mask on GPU
idxs = mask.nonzero(as_tuple=True) # idxs on GPU as well

# copy elements
tgt[idxs].copy_(src[idxs])  # does not update tgt
```

### Versions

Collecting environment information...
PyTorch version: 1.10.0+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: Could not collect
CMake version: version 3.17.3
Libc version: glibc-2.25

Python version: 3.6.9 (default, Jun 29 2022, 11:45:57)  [GCC 8.4.0] (64-bit runtime)
Python platform: Linux-5.4.0-124-generic-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: True
CUDA runtime version: 11.3.109
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3070 Ti
Nvidia driver version: 470.141.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.2.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.2.1
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.2.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.2.1
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.2.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.2.1
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.2.1
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.19.5
[pip3] torch==1.10.0+cu113
[pip3] torch-scatter==2.0.5
[pip3] torchaudio==0.10.0+cu113
[pip3] torchvision==0.11.1+cu113
[conda] blas                      1.0                         mkl  
[conda] mkl                       2020.0                      166  
[conda] mkl-service               2.3.0            py37he904b0f_0  
[conda] mkl_fft                   1.0.15           py37ha843d7b_0  
[conda] mkl_random                1.1.0            py37hd6b4f25_0  
[conda] numpy                     1.18.1           py37h4f9e942_0  
[conda] numpy-base                1.18.1           py37hde5b4d6_1  
[conda] numpydoc                  0.9.2                      py_0
Tensor Subclass that doesn't require grad may wrap a Tensor subclass that requires grad
Labels: triaged, tensor subclass

From a practical perspective, this only happens today in functorch. 

## The Problem

We have some composite operations that check if a Tensor requires grad. If it does, then it goes down one path; if it doesn't, then it goes down a "non-differentiable" path.

In functorch, we can have Tensor subclasses that do not require grad that wrap Tensors that do require grad. Unfortunately, the composite operations check if a Tensor requires grad and return false on the Tensor subclass, causing it to go down a non-differentiable path.

See https://github.com/pytorch/pytorch/pull/84137 for example. This problem is related to composite compliance: https://github.com/pytorch/pytorch/issues/69991

cc @ezyang
[optim] asgd : handling of complex params as real params (NaN vs inf)
Labels: module: optimizer, triaged, module: edge cases

### 🐛 Describe the bug

With patch in https://github.com/pytorch/pytorch/pull/84472

```python

def print_grad(grad):
    print("PRINT GRAD HOOK:", grad)
    return grad

a1 = torch.tensor([-0.4329+0.3561j,  0.1633+0.4901j], requires_grad=True)


a1_real = a1.real.clone().detach()
a1_imag = a1.imag.clone().detach()
a1_real.requires_grad_()
a1_imag.requires_grad_()
optimizer_constructor = torch.optim.ASGD

# Attach hook
a1.register_hook(print_grad)
a1_real.register_hook(print_grad)
a1_imag.register_hook(print_grad)

optim1 = optimizer_constructor([a1])
optim2 = optimizer_constructor([a1_real, a1_imag])

for i in range(10):
    print(f"*****{i}****")
    print(a1)
    print(a1_real, a1_imag)
    optim1.zero_grad()
    optim2.zero_grad()

    if i == 0:
        torch.testing.assert_close(a1.grad, None)
        torch.testing.assert_close(a1_real.grad, None)
        torch.testing.assert_close(a1_imag.grad, None)
    else:
        torch.testing.assert_close(a1.grad.real, a1_real.grad, equal_nan=True)
        torch.testing.assert_close(a1.grad.imag, a1_imag.grad, equal_nan=True)

    a2 = torch.complex(a1_real, a1_imag)
    torch.testing.assert_close(a1, a2)

    o = f(a1)
    o2 = f(a2)
    o.backward()
    print("GRAD:", a1.grad)
    o2.backward()
    print("REAL GRAD", a1.grad.real, a1_real.grad)
    print("IMAG GRAD", a1.grad.imag, a1_imag.grad)
    torch.testing.assert_close(a1.grad.real, a1_real.grad, equal_nan=True) # Fails here (optimizer shouldn't affect this ideally)!
    torch.testing.assert_close(a1.grad.imag, a1_imag.grad, equal_nan=True)

    optim1.step()
    optim2.step()

```

Fails with 
```
AssertionError: Tensor-likes are not close!

Mismatched elements: 1 / 2 (50.0%)
Greatest absolute difference: nan at index (1,) (up to 1e-05 allowed)
Greatest relative difference: nan at index (1,) (up to 1.3e-06 allowed)
```

NOTE:

Interestingly value printed by the hook for a1.grad is different from the next print at
`print("REAL GRAD", a1.grad.real, a1_real.grad)`.

cc: @albanD @soulitzer 

### Versions

PR : https://github.com/pytorch/pytorch/pull/84472

cc @vincentqb @jbschlosser @albanD
Add nvfuser support for prims.copy_to
Labels: oncall: jit, triaged, open source, cla signed, release notes: jit, module: nvfuser, module: primTorch, no-stale

I use nvFuser's `aliasOutputToInput` here and since it implicitly adds outputs to the fusion, I need to drop those within Python.

Now we can lower the batch_norm implementation from torch._decomp to nvprims(see `test_batch_norm_forward_nvprims`).

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel @kevinstephano @jjsjann123 @ezyang @mruberry @ngimel @Lezcano @fdrocha @peterbell10
list of tensors can't be converted to a torch tensor while list of lists gets easily converted to a pytorch tensor
Labels: triaged, module: numpy

### 🐛 Describe the bug

```
import torch
import numpy as np
a = [torch.tensor([1,2]),torch.tensor([0.4,0.5]),torch.tensor([1,4])]
torch.tensor(np.array(a))
```
This is going to give type error
![image](https://user-images.githubusercontent.com/95900977/188446921-f81bd5d4-861b-4ee6-8bd3-94a19dd5647f.png)

While this works correctly
```
a = [[1,2],[0.4,0.5],[1,4]]
torch.tensor(np.array(a))
``` 
![image](https://user-images.githubusercontent.com/95900977/188447134-e351c793-85b5-4f3a-bb88-25892c40d6d1.png)






### Versions

PyTorch version: 1.12.1+cu113
Is debug build: False
CUDA used to build PyTorch: 11.3
ROCM used to build PyTorch: N/A

OS: Ubuntu 18.04.6 LTS (x86_64)
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Clang version: 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
CMake version: version 3.22.6
Libc version: glibc-2.26

Python version: 3.7.13 (default, Apr 24 2022, 01:04:09)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.188+-x86_64-with-Ubuntu-18.04-bionic
Is CUDA available: True
CUDA runtime version: 11.1.105
GPU models and configuration: GPU 0: Tesla T4
Nvidia driver version: 460.32.03
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.5
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.0.5
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.0.5
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.12.1+cu113
[pip3] torchaudio==0.12.1+cu113
[pip3] torchsummary==1.5.1
[pip3] torchtext==0.13.1
[pip3] torchvision==0.13.1+cu113
[conda] Could not collect

cc @mruberry @rgommers
OpInfo tests should compare gpu to cpu implementations
Labels: module: tests, triaged, topic: not user facing

I believe that currently we do not have any OpInfo based tests that compare the results of gpu to cpu implementations.
Seems like this would be very useful to have, and shouldn't be too hard to implement.
You could just take the intersection of cpu and gpu dtypes for each OpInfo and compare outputs.


(FYI, I came across a discrepancy between gpu and cpu implementations (of `nn.functional.grid_sample`) which made me think of this. )



cc @mruberry