gopikrsmscs/torch-issues huggingface dataset:
torch.linalg.cond gives inconsistent results on CPU/CUDA
Labels: triaged, module: NaNs and Infs, module: linear algebra

### 🐛 Describe the bug

`torch.linalg.cond` computes the conditional number of a matrix. But if the matrix is not invertiable it should give back infinity but we can get different results on cpu and gpu:
- CPU: 1.4825e+08
- GPU: 9.8031e+14
- numpy: inf

Code to reproduce:
```
import torch
import numpy as np

torch.manual_seed(420)
torch.cuda.manual_seed_all(420)
input = torch.ones(2, 2)
output = torch.linalg.cond(input)

cuda_input = torch.ones(2, 2).cuda()
cuda_output = torch.linalg.cond(cuda_input)

print(output) # gives large number (1.4825e+08)
print(cuda_output) # gives even larger number (9.8031e+14)
print(np.linalg.cond(input)) # gives inf
```


### Versions

torch 1.12.1+cu113

cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
New APIs for cuda graph inspection and manipulation
Labels: triaged, module: cuda graphs

A stalled #85519 adds capabilities to dump cuda graphs for inspection. We would like to extend it to
1) provide a way to get all nodes from the graph
2) modify nodes to patch in addresses for the inputs to avoid copying inputs. Note, this is more complicated than just comparing old and new pointers and swapping one for another because kernels could operate on input slices, so one would need to inspect if kernel argument falls within the range of the original input tensor and, if so, replace it with the corresponding new address + offset. 

cc @mcarilli @ezyang @eqy
DISABLED test_expanded_reduction_cpu (__main__.CpuTests)
Labels: triaged, skipped, module: inductor, module: dynamo

Platforms: linux

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/test_expanded_reduction_cpu%2CCpuTests)).

cc @jansel @lezcano @fdrocha @mlazos @soumith @voznesenskym @yanboliang
torch.clamp does not clamp out of -0 from 0 when ran on the CPU
Labels: triaged, module: numpy, module: edge cases

### 🐛 Describe the bug

when ran on the CPU, `torch.clamp` does not clamp out of -0 from 0 (i.e. when min is 0, it does not change -0 to 0 as it should). 
- output on cpu: -0.
- output on gpu: 0.
- output with numpy: 0.

See this code snippet to produce the bug:
```
import torch
import numpy as np

torch.manual_seed(420)
torch.cuda.manual_seed_all(420)
x = torch.tensor([-0., 0., 0.])
y = torch.clamp(x, min=0, max=1)  # prints [-0., 0., 0.]
print(y)

x = x.cuda()
y = torch.clamp(x, min=0, max=1)  # prints [0., 0., 0.]
print(y)

x = np.array([-0., 0., 0.])
y = np.clip(x, 0, 1)
print(y)  # prints [0., 0., 0.]
```

### Versions

torch 1.12.1

cc @mruberry @rgommers
[MPS] sum on a size=1 dim is ~5x slower than squeeze
Labels: triaged, module: mps

### 🐛 Describe the bug

For a dimension with size 1, MPS's implementation of sum is ~5x slower than squeeze. This becomes more painful when the tensor is larger, as shown in the benchmarks below.

## Proposed Solution:
Would it help to have MPS's kernel for sum call squeeze when the size of the sum'd dimension is already 1 (for the case where dimensions should not be kept)? --> I have not checked whether this is already the case.

## Benchmarks
![image](https://user-images.githubusercontent.com/31798555/196279577-d624549b-ce8c-47d8-9058-df4702194020.png)
[sum_benchmark.txt](https://github.com/pytorch/pytorch/files/9804411/sum_benchmark.txt) --> changed this to a TXT so GH would let me upload it, but to run, change the extension back to .py.


### Versions

master
```
Collecting environment information...
PyTorch version: 1.14.0a0+gitb40f443
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 12.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.102)
CMake version: version 3.22.1
Libc version: N/A

Python version: 3.10.6 (main, Oct  7 2022, 15:17:36) [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-12.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
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: False

Versions of relevant libraries:
[pip3] numpy==1.23.1
[pip3] torch==1.14.0a0+gitb40f443
[conda] numpy                     1.23.1          py310h220015d_0  
[conda] numpy-base                1.23.1          py310h742c864_0  
[conda] torch                     1.14.0a0+gitb40f443           dev_0    <develop>
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Bug in Histogram Observer Implementation
Labels: oncall: quantization, triaged

### 🐛 Describe the bug

It seems to me that the `HistogramObserver` implementation has a bug. In [L 1181](https://github.com/pytorch/pytorch/blob/e85dbcc9b075961ab082975348c5cf1d99b7da76/torch/ao/quantization/observer.py#L1181) the forward pass is as follows:

```
combined_histogram = self._combine_histograms(
    combined_histogram,
    self.histogram,
    self.upsample_rate,
    downsample_rate,
    start_idx,
    self.bins,
)
```
Where `_combine_histograms` is defined as:
```
def _combine_histograms(
    self,
    orig_hist: torch.Tensor,
    new_hist: torch.Tensor,
    upsample_rate: int,
    downsample_rate: int,
    start_idx: int,
    Nbins: int,
) -> torch.Tensor:
```

Therefore, ` combined_histogram` gets mapped to `orig_hist` while `self.histogram` gets mapped to `new_hist`. It seems to me like it should be the other way around given the variable names.

Can someone clarify?

Thank you!!

### Versions

latest main

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
cppextension host compiler check ignores executable symbolic link in CUDA bin directory
Labels: module: build, module: cpp-extensions, triaged

### 🐛 Describe the bug

PyTorch 1.12 added a [host compiler version check](https://github.com/pytorch/pytorch/blob/b40f4434ac3512a21dcec91467df1b179898503f/torch/utils/cpp_extension.py#L409-L420) when building PyTorch extensions. However, one way of specifying the host compiler executable used by nvcc is to include a symbolic link to the desired compiler executable in the CUDA home directory, and it seems that the compiler version check does not take this into account. This results in an error, even though nvcc may well be setup to use the correct host compiler version. 

It may well be good to check for other ways that nvcc may be informed which compiler to use and factor these into the version check too.

It seems a simple workaround is to simply to set the ```TORCH_DONT_CHECK_COMPILER_ABI``` environment variable. But it would be nice to not rely on this, as it is useful to know when the compiler version is genuinely wrong.



### Versions

PyTorch 1.12

cc @malfet @seemethere @zou3519
Nandense layer for missing values
Labels: module: sparse, module: nn, triaged, module: masked operators

### 🚀 The feature, motivation and pitch

This paper has an interesting Tensorflow implementation of a nan aware layer so that the neural network can handle missing values natively. Code provided in the paper, might be interesting to implement in Pytorch for inclusion in this library.

https://arxiv.org/pdf/2206.01640.pdf

### Alternatives

_No response_

### Additional context

_No response_

cc @nikitaved @pearu @cpuhrsch @amjames @bhosmer @albanD @mruberry @jbschlosser @walterddr @kshitij12345 @saketh-are
DISABLED test_variant_consistency_jit_linalg_lu_cuda_complex64 (__main__.TestJitCUDA)
Labels: module: cuda, triaged, module: flaky-tests, skipped, module: unknown

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_variant_consistency_jit_linalg_lu_cuda_complex64&suite=TestJitCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/8924896021).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 failures and 1 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_variant_consistency_jit_linalg_lu_cuda_complex64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @ngimel
more cudagraphs tests
Labels: triaged, oncall: pt2

After https://github.com/pytorch/pytorch/pull/87058 and https://github.com/pytorch/pytorch/pull/87060 and the issues that prompted those PRs, I can think of a bunch of edge-cases that we should add tests for within the cudagraph codepath:

1. Inputs are views of a larger storage

```python
input_parent = torch.randn(1000, requires_grad=True)
input1 = input_parent[0:100]
input2 = input_parent[300:400]
out = model(input1, input2)
out.sum().backward()
```

2. Same as (1), but model parameters share storage

```python
class Repro(torch.nn.Module):
    def __init__(self):
        super(Repro, self).__init__(device)
        self.weight1 = torch.nn.Parameter(
            torch.randn(2, 2, requires_grad=True, device=device)
        )
        self.weight2 = nn.Parameter(self.weight1.detach())
       # the weights wont remain tied across a `model.to(device)` or `model.cuda()` call, so this has to be carefully constructed with the weights already on the target device

    def forward(self, x):
        # assert(self.weight1.data_ptr() == self.weight2.data_ptr())
        x = torch.matmul(x, self.weight1)
        x = torch.matmul(x, self.weight2)
        return x
```

3. Inputs have actual overlap

```python
input_parent = torch.randn(1000, requires_grad=True)
input1 = input_parent[0:100]
input2 = input_parent[50:200]
out = model(input1, input2)
out.sum().backward()
```

cc: @eellison 

cc @ezyang @msaroufim @wconstab @ngimel @bdhirsh
Pipe conveys inconsistent value in GPU env
Labels: module: multiprocessing, triaged

### 🐛 Describe the bug

The Pipe and Queue of multiprocessing module conveys inconsistent value in GPU env while run correctly in non-heterogeneous env.
For the code below, the values on two sides of the Pipe are inconsistent. However, if the env is non-heterogeneous (do not .to('cuda:0')), the result is correct.
```python
import multiprocessing
import torch
import time

def genData(pipeIn):
    for i in range(2):
      t=torch.ones(3,).to('cuda:0')
      #t=torch.ones(3,)
      pipeIn.send(t)
    time.sleep(1)  


if __name__ == '__main__':
  pout, pin = multiprocessing.Pipe(duplex=False)
  temp = multiprocessing.Process(target=genData, args=(pin,))
  temp.start()
  for i in range(2):
    r = pout.recv()
    print(r)
    del r
```

### Versions

- CPython versions: 3.8.10
- Operating system and architecture:
- Windows 11 (Version: 21H2) on 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz 2.30 GHz
- GPU: NVIDIA GeForce RTX 3060 Laptop GPU
- Dependecies: Torch (1.11.0+cu113)

cc @VitalyFedyunin
Segmentation fault: 11 when running "import torch" on Mac OS X
Labels: triaged, module: macos

### 🐛 Describe the bug

Hi team, I'm getting `Segmentation fault: 11` when trying to import torch in my local machine:
```
Python 3.7.12 | packaged by conda-forge | (default, Oct 26 2021, 05:59:23) 
[Clang 11.1.0 ] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import torch
Segmentation fault: 11
```
I have looked through past issues and tried to look for similar errors, but haven't found anything related to seg fault 11. 
I installed `gdb` and tried to debug, but I'm not sure if it has some issues and the output looks correct:
`gdb python
r -c "import torch"`
```
Reading symbols from python...

warning: `/tmp/lto.o': can't open to read symbols: No such file or directory.
(No debugging symbols found in python)
(gdb) 
(gdb) r -c "import torch"
Starting program: /Users/Darren/opt/miniconda3/envs/computer-vision/bin/python -c "import torch"

[New Thread 0x1803 of process 21505]
[New Thread 0x1a03 of process 21505]
warning: unhandled dyld version (17)
  File "<string>", line 1
    "import
          ^
SyntaxError: EOL while scanning string literal
[Inferior 1 (process 21505) exited with code 01]

```
Also tried running [collect_env.py](https://github.com/pytorch/pytorch/blob/master/torch/utils/collect_env.py), but it gave the same "Segmentation fault: 11" error from the line `import torch`. 

I installed PyTorch with `pip3 install torch torchvision`, the versions are torch 1.12.1  and torchvision 0.13.1. I was trying to install for CPU only since I don't have a GPU. 

Any idea on what might be causing the seg fault? Thanks

### Versions

I had to manually set `TORCH_AVAILABLE` to false to bypass `import torch`, which would otherwise cause a seg fault 11 error. 

```
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A
OS: macOS 11.4 (x86_64)
GCC version: Could not collect
Clang version: 14.0.4
CMake version: version 3.22.1
Libc version: N/A
Python version: 3.7.12 | packaged by conda-forge | (default, Oct 26 2021, 05:59:23)  [Clang 11.1.0 ] (64-bit runtime)
Python platform: Darwin-20.5.0-x86_64-i386-64bit
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A
Versions of relevant libraries:
[pip3] numpy==1.21.6
[pip3] torch==1.12.1
[pip3] torchvision==0.13.1
[conda] numpy                     1.21.6           py37h345d48f_0    conda-forge
[conda] torch                     1.12.1                   pypi_0    pypi
[conda] torchvision               0.13.1                   pypi_0    pypi
```

cc @malfet @albanD
Saving and loading from physical storage
Labels: module: memory usage, module: serialization, triaged

### 🚀 The feature, motivation and pitch

Physical storage allows us to work with very large tensors.

Ideally, saving a tensor from physical storage into a file would not create a copy of the full tensor in memory. I believe that a call to `torch.save` will already do that.
However, when loading the tensor, it will be directly loaded on memory, not on physical storage. This is a problem if the tensor is too big.

A nice feature would be that a tensor that was saved on physical storage would be loaded on physical storage again, without creating a full copy in memory:
```python
x = torch.zeros(10).share_memory_()
torch.save(x, "x.pt")
x_loaded = torch.load("x.pt")
x.is_shared()  # the tensor is on physical storage again
```

cc @mruberry @suo

### Alternatives

TorchSnapshot offers an alternative where we can directly save a tensor from physical to physical storage, then load a tensor in place on another one in any memory location without creating a full copy in memory (hence solving this problem). I don't think PyTorch intends to do in-place tensor loading but still, I think that keeping the memory location (as we keep the device) would be a nice-to-have feature.

### Additional context

We have implemented in TorchRL a buffer API where big tensors that would not fit in RAM are stored on disk (say > 1Tb). Through the use of memmap arrays, we can quickly access any given set of rows of these tensors during sampling from the buffer. This is much faster than accessing shared tensors stored in a list for instance.
When checkpointing, we'd like to save directly those tensors from disk storage to disk storage, without loading the full tensor on RAM. We would also like to load tensors that were saved on physical storage on the same storage location, without loading the full tensor in memory.
Rewrite `narrow_copy_dense_cpu_out` using `copy_` and `narrow`
Labels: triaged, module: functionalization

### 🚀 The feature, motivation and pitch

Looks like the current implementation of `narrow_copy_dense_cpu_out` wasn't fully reviewed before being merged. Alban suggested a potential alternative implementation [here](https://github.com/pytorch/pytorch/pull/49502#issuecomment-759421583):

```cpp
Tensor& narrow_copy_dense_cpu_out( 
  const Tensor& self, int64_t dim, int64_t start, int64_t length, Tensor& output
) {
  // resize output
  auto output_sizes = self.sizes().vec();
  output_sizes[dim] = length;
  at::native::resize_(output, output_sizes);

  // write the content into output
  return output.copy_(at::narrow(self, dim, start, length));
}
```

I see two advantages:
- the code is much simpler
- it will use the same error checking logic as `narrow` (currently, the checks and error messages are slightly different).

Perf impact of this rewrite needs to be investigated first.

### Alternatives

_No response_

### Additional context

_No response_

cc @bdhirsh @ezyang @soumith
Error: unknown architecture `armv7-a;' and Error: selected processor does not support `command' in ARM mode
Labels: oncall: quantization, triaged, module: arm, topic: build

### 🐛 Describe the bug

I'm trying to build PyTorch on OprangePi PC (H3 Quad-core Cortex-A7) but for some reason I get 
```
Error: unknown architecture `armv7-a;'
```
is that semicolon in a wrong place ? The actual -march is:
```
$:> gcc -c -Q -march=native --help=target | grep march
  -march=                               armv7ve+simd
```
After which I get about a thousand similar errors like this: Error: selected processor does not support 'command' in ARM mode'
Is there a way to force/change -march or is it a bug in the auto-detecting code of `setup.py` / cmake(s) ?
```
/rstorage/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S: Assembler messages:
/rstorage/drone/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S:471: Error: unknown architecture `armv7-a;'
/rstorage/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S:471: Error: selected processor does not support `vpush {d8-d15}' in ARM mode
/rstorage/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S:471: Error: selected processor does not support `vld1.8 {d16[]},[r7]' in ARM mode
/rstorage/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S:471: Error: selected processor does not support `veor q10,q10,q10' in ARM mode
/rstorage/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S:471: Error: selected processor does not support `vld1.8 {d17[]},[r4]!' in ARM mode
/rstorage/pytorch_install/pytorch/aten/src/ATen/native/quantized/cpu/qnnpack/src/q8gemm_sparse/4x8c1x4-dq-packedA-aarch32-neon.S:471: Error: selected processor does not support `vld1.8 {d0},[r6]!' in ARM mode

```

### Versions

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (armv7l)
GCC version: (Ubuntu 11.2.0-19ubuntu1) 11.2.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.10.6 (main, Aug 10 2022, 11:40:04) [GCC 11.3.0] (32-bit runtime)
Python platform: Linux-5.15.72-sunxi-armv7l-with-glibc2.35
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

Versions of relevant libraries:
[pip3] numpy==1.21.5
[conda] Could not collect


cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @malfet
Drop deprecated behavior from NumPy-style `T`
Labels: triaged, module: numpy, module: deprecation

### 🚀 The feature, motivation and pitch

See `numpy_T` in core. The deprecation warning has been there for 12 months and for more than 2 releases, so it can be removed IIUC.

```cpp
  if (n != 2 && n != 0) {
    TORCH_WARN_ONCE(
        "The use of `x.T` on tensors of dimension other than 2 to reverse their shape is deprecated ",
        "and it will throw an error in a future release. Consider `x.mT` to transpose batches of matrices ",
        "or `x.permute(*torch.arange(x.ndim - 1, -1, -1))` to reverse the dimensions of a tensor."
    );
  }
```

See the BC policy:

https://github.com/pytorch/pytorch/wiki/PyTorch's-Python-Frontend-Backward-and-Forward-Compatibility-Policy

Maybe `T` can be made into an alias of `t`, but they have slightly different constraints:
- `T` checks for `n != 2 && n != 0`, `t` (in `check_t`) checks sparse dims and has a check for `<= 2`.
- `T` is implemented using `permute`, `t` is implemented using `transpose`.

### Alternatives

_No response_

### Additional context

_No response_

cc @mruberry @rgommers
DISABLED test_vmapvjpvjp_linalg_lu_cuda_float32 (__main__.TestOperatorsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: functorch

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_vmapvjpvjp_linalg_lu_cuda_float32&suite=TestOperatorsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/8873086538).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 failures and 1 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_vmapvjpvjp_linalg_lu_cuda_float32`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @zou3519 @Chillee @samdow @soumith
[FSDP] Investigate `torch.cuda.current_stream()` usage in post-backward
Labels: oncall: distributed, triaged, module: fsdp

In FSDP's post-backward hook, `torch.cuda.current_stream()` sometimes returns the default computation stream and sometimes returns the all-gather/unshard stream, even though the execution should not be in the all-gather/unshard stream.

There is a `self._streams["post_backward"].wait_stream(torch.cuda.current_stream())` call before the gradient reduction that I cannot explain; the call originates from the initial Fairscale PR introducing FSDP. Changing it to `wait_stream(self._streams["computation"])` breaks unit tests (computation correctness), while changing it to `wait_stream(self._streams["unshard"])` seems to work (but needs to be verified thoroughly).

This is a conceptual problem and does not block any progress.

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501
View-based advanced indexing (Integer array/LongTensor indexing) of nested_tensor
Labels: feature, triaged, module: advanced indexing

### 🚀 The feature, motivation and pitch

Integer array/LongTensor indexing is a type of advanced indexing and as such typically returns a copy of a tensor. This feature request is proposing that something along these lines or index_select are implemented for nested_tensor, and made to return a view.

This feature has been requested a few times for normal tensors e.g. here https://discuss.pytorch.org/t/index-select-same-storage-as-the-original-tensor/4368/4 and here https://discuss.pytorch.org/t/tensor-slice-views/24694/5 -- both times it was noted that this does not fit with the normal strided tensor layout. However, it does seem that this should be possible for nested_tensor. One area where it is relevant is in multi-task learning e.g. different classification heads with a different number of labels. In this context, mutliple heads could be being stored in a nested_tensor. We may recieve a batch with task_ids corresponding to inputs and want to do something along the lines of `inputs ⊕ weights[task_ids]`.  At a cursory glance, it appears such a view is possible with nested_tensor. In fact, it looks like this is what `_nested_view_from_buffer` in the C++ API allows.

### Alternatives

The current workaround would be to use a list comprehension on the index array and reconstruct a nested_tensor with copies of the data.

### Additional context

_No response_
Broadcasting add for nested_tensor
Labels: triaged, module: nestedtensor

### 🚀 The feature, motivation and pitch

It would be useful when multiple a cutoff based ordinal regression heads of the CORAL variety https://github.com/Raschka-research-group/coral-pytorch to be able to do broadcasting addition, like so:

```
>>> import torch
>>> import torch.nested
>>> torch.nested.as_nested_tensor([torch.tensor([3.4, 2.3, 4.5])]) + torch.nested.nested_tensor([torch.tensor([-2.3, 0.4, 5.3]), torch.tensor([-2.3, 0.4, 5.3])])
/home/frankier/edu/doc/bert_ordinal/nestedplay/.venv/lib/python3.10/site-packages/torch/nested/__init__.py:84: UserWarning: The PyTorch API of nested tensors is in prototype stage and will change in the near future. (Triggered internally at ../aten/src/ATen/NestedTensorImpl.cpp:175.)
  return torch._nested_tensor_from_tensor_list(tensor_list, dtype, None, device, None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: add does not support broadcasting when given a NestedTensor
```

### Alternatives

Copy stuff like so (current workaround):

```
>>> torch.nested.as_nested_tensor([torch.tensor([3.4, 2.3, 4.5]),torch.tensor([3.4, 2.3, 4.5])]) + torch.nested.nested_tensor([torch.tensor([-2.3, 0.4, 5.3]), torch.tensor([-2.3,
 0.4, 5.3])])
nested_tensor([
  tensor([1.1000, 2.7000, 9.8000]),
  tensor([1.1000, 2.7000, 9.8000])
])
```

### Additional context

_No response_

cc @cpuhrsch @jbschlosser @bhosmer @drisspg @mikaylagawarecki
DISABLED test_variant_consistency_jit_linalg_lu_factor_ex_cuda_complex64 (__main__.TestJitCUDA)
Labels: triaged, module: flaky-tests, skipped, module: unknown

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_variant_consistency_jit_linalg_lu_factor_ex_cuda_complex64&suite=TestJitCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/8859723172).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 failures and 1 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_variant_consistency_jit_linalg_lu_factor_ex_cuda_complex64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.
compile torch from source
Labels: needs reproduction, module: build, triaged

### 🐛 Describe the bug

Cuda version in my local machine or system env is 11.7 but 11.3 in my conda env. I set **_CUDA_HOME=/usr/lcoal/cuda_** when I compiled torch but failed ... And It finished with success when I downgraded cuda-version in local machine or upgraded cuda-version in my conda env. In other words, I have to keep cuda version in local machine consistent with that inside conda env, which is extremely inconvenient  for me... 
What can I do to solve it? THANKS

### Versions

torch 1.12.0

cc @malfet @seemethere
Distributed collective ops fail in `inference_mode` for CPU-only
Labels: oncall: distributed, triaged, module: c10d

### 🐛 Describe the bug

Calling collectives inside `@torch.inference_mode()` fails for gloo but works for nccl.

Repro, call using torchrun:

```
import torch.distributed as dist
import torch

@torch.inference_mode()
def test_inference():
    tensor_list = [torch.zeros(1) for _ in range(dist.get_world_size())]

    tensor = torch.tensor([dist.get_rank()], dtype=torch.float32)
    dist.all_gather(tensor_list, tensor)
    print(tensor_list)
    
def main():
    dist.init_process_group("gloo")
    print('rank', dist.get_rank())
    test_inference()

if __name__ == '__main__':
    main()
```


From discussion with @mrshenli  and @albanD:

> The error comes from the fact that a Tensor is written inplace without inference mode being enabled.
My first guess would be that gloo is using a worker thread but does not propagate the current TLS from the user thread to this worker thread. In particular, inference mode status is not propagated and thus this error.


> yep Gloo uses threads to send data, And yep, Gloo [does not propagate TLS](https://github.com/pytorch/pytorch/blob/86f914e9966e91b3d3e7c1504f5b1f00a9498d88/torch/csrc/distributed/c10d/ProcessGroupGloo.cpp#L772-L774)

> You can use the utilities from [https://github.com/.../aten/src/ATen/ThreadLocalState.h](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/ThreadLocalState.h) to capture the current state and restore it in the worker thread.




### Versions

Latest master

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu
Forward hooks for ScriptModules
Labels: oncall: jit

Is it possible to add support for registering forward hooks for ScriptModules? <br>
**Use case:** I am trying to get activations from an intermediate layer of a pretrained model that was JIT scripted. It would be nice to have the support for forward hooks on the scripted model, in order to avoid copying the state dict from the JIT model to nn.Sequential model and run forward pass through the Sequential model. 

Is there any alternative solution I can try?
Expanding the parameters of `torch.svd_lowrank`
Labels: triaged, module: linear algebra

### 🚀 The feature, motivation and pitch

Hi,

Currently, the `torch.svd_lowrank` function implements a very basic version of Halko, et al. (2009)'s algorithm. The `sklearn` version, `sklearn.utils.extmath.randomized_svd`  implements a number of parameters that facilitate noisy problems. In particular, the `n_oversamples` parameter increases the dimension of the random projections in the algorithm, which allows one to operate on noisier datasets without performing extra power iterations. 

While the current implementation of `torch.svd_lowrank` is probably sufficient for absolutely low rank problems with discontinuous and clean spectra, more oversamples are required for many _relatively_ low rank problems with continuous spectral decay. For instance, we are working with low rank approximation of matrices of size 100,000 x 40,000. We are taking anywhere from rank 80-200 approximations of these matrices. For the purposes of our algorithm, *accurate* recovery of the singular values, especially those near the parameter `k`, are important. We find that for our data, our `n_oversamples` is typically `10*k` in order to accurately recover the true singular values near the rank of the matrix.

Implementing this would not be hard: it amount to adding a kwarg and changing a few lines of the `svd_lowrank` calls to `get_approximate_basis`

### Alternatives

_No response_

### Additional context

_No response_

cc @jianyuh @nikitaved @pearu @mruberry @walterddr @IvanYashchuk @xwang233 @Lezcano
[MPS] Add support for aten::erfinv.out for MPS backend
Labels: good first issue, triaged, module: mps

### 🐛 Describe the bug

First time contributors are welcome! 🙂
Add support for [aten::erfinv.out](https://pytorch.org/docs/stable/generated/torch.erfinv.html) for MPS backend. Generic support for adding operations to MPS backend is captured here: https://github.com/pytorch/pytorch/wiki/MPS-Backend#adding-op-for-mps-backend

### Versions

N/A

cc @kulinseth @albanD @malfet @razarmehr @abhudev
TF32 conv_transpose2d with groups has bad precision compared to fp32
Labels: module: numerical-stability, module: cuda, triaged, module: tf32

### 🐛 Describe the bug

## Discussion

It's unclear to me if this is a bug or expected behavior, so I'm opening this issue to discuss. https://pytorch.org/docs/stable/notes/cuda.html#tf32-on-ampere suggests that TF32's precision isn't as good as fp32, though the numbers look very different to me in this particular case

## Repro

```py
import torch
import torch.nn.functional as F
from torch.testing import make_tensor

torch.manual_seed(0)

torch.backends.cudnn.allow_tf32 = True

x = make_tensor(1, 2 * 4, 5, 5, dtype=torch.float32, device='cuda')
w = make_tensor(2 * 4, 8, 3, 3, dtype=torch.float32, device='cuda')

result = F.conv_transpose2d(x, w, groups=2).double()
expected = F.conv_transpose2d(x.double(), w.double(), groups=2)

amax = result.sub(expected).div(expected).abs().argmax()
print("% difference: ", result.sub(expected).div(expected).abs().max())
print("values: ", result.view(-1)[amax], expected.view(-1)[amax])
```
Gives the following:
```
% difference:  tensor(0.2066, device='cuda:0', dtype=torch.float64)
values:  tensor(0.0278, device='cuda:0', dtype=torch.float64) tensor(0.0350, device='cuda:0', dtype=torch.float64)
```
There is a 20% relative difference!

Furthermore, setting `torch.backends.cudnn.allow_tf32 = False` makes the difference go back down to 7.6725e-05. Also, using `groups=1` also makes the difference go down to something in the 1e-05 range.

### Versions

nightly; using a A100 GPU

cc @ezyang @gchanan @ngimel @zasdfgbnm @ptrblck
We don't have an op for vulkan_prepack::conv2d_clamp_prepack but it isn't a special case.
Labels: module: convolution, oncall: mobile, module: vulkan

### 🐛 Describe the bug

To reproduce, go to goggle colab and run this simple snipet

```python
from torch import nn
import torch
from torch.utils.mobile_optimizer import optimize_for_mobile

print(torch.__version__)

with torch.no_grad():
    x = torch.zeros(1, 3, 640, 640)
    model = torch.nn.Conv2d(3, 3, kernel_size=1)
    script_model = torch.jit.trace(model, x)
    optimized_traced = optimize_for_mobile(script_model, backend='vulkan')
    optimized_traced._save_for_lite_interpreter("sample_data/t.ptl")
```

```
1.12.1+cu113
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
[<ipython-input-22-48d86b414602>](https://localhost:8080/#) in <module>
      9     model = torch.nn.Conv2d(3, 3, kernel_size=1)
     10     script_model = torch.jit.trace(model, x)
---> 11     optimized_traced = optimize_for_mobile(script_model, backend='vulkan')
     12     optimized_traced._save_for_lite_interpreter("sample_data/t.ptl")

[/usr/local/lib/python3.7/dist-packages/torch/utils/mobile_optimizer.py](https://localhost:8080/#) in optimize_for_mobile(script_module, optimization_blocklist, preserved_methods, backend)
     65             preserved_methods_str)
     66     elif backend == 'vulkan':
---> 67         optimized_cpp_module = torch._C._jit_pass_vulkan_optimize_for_mobile(script_module._c, preserved_methods_str)
     68     elif backend == 'metal':
     69         optimized_cpp_module = torch._C._jit_pass_metal_optimize_for_mobile(script_module._c, preserved_methods_str)

RuntimeError: 0 INTERNAL ASSERT FAILED at "../torch/csrc/jit/ir/alias_analysis.cpp":608, please report a bug to PyTorch. We don't have an op for vulkan_prepack::conv2d_clamp_prepack but it isn't a special case.  Argument types: Tensor, Tensor, int[], int[], int[], int, NoneType, NoneType,
```

### Versions

pytorch version 1.12.1+cu113
Poisson sampling on GPU fails for high rates
Labels: module: cuda, triaged, module: random

### 🐛 Describe the bug

For rates > 1e10, the Poisson sampling on the GPU delivers incorrect results

```python

import torch
torch.set_default_dtype(torch.float64)
a = torch.ones((100, 100))*1e10

b_cpu = torch.poisson(a.to("cpu"))
b_cuda = torch.poisson(a.to("cuda"))

print(b_cpu.mean())
print(b_cuda.mean())

```

### 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: 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.10.2
Libc version: glibc-2.17

Python version: 3.7.13 (default, Mar 29 2022, 02:18:16)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.4.0-125-generic-x86_64-with-debian-buster-sid
Is CUDA available: True
CUDA runtime version: Could not collect
GPU models and configuration: 
GPU 0: NVIDIA GeForce GTX 1050 Ti
GPU 1: NVIDIA GeForce RTX 2080 SUPER

Nvidia driver version: 515.65.01
cuDNN version: Probably one of the following:
/usr/lib/x86_64-linux-gnu/libcudnn.so.8.5.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_infer.so.8.5.0
/usr/lib/x86_64-linux-gnu/libcudnn_adv_train.so.8.5.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_infer.so.8.5.0
/usr/lib/x86_64-linux-gnu/libcudnn_cnn_train.so.8.5.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_infer.so.8.5.0
/usr/lib/x86_64-linux-gnu/libcudnn_ops_train.so.8.5.0
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.21.5
[pip3] numpydoc==1.4.0
[pip3] torch==1.12.1+cu116
[pip3] torchvision==0.13.1+cu116
[conda] blas                      1.0                         mkl  
[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.21.5           py37h6c91a56_3  
[conda] numpy-base                1.21.5           py37ha15fc14_3  
[conda] numpydoc                  1.4.0                    pypi_0    pypi
[conda] torch                     1.12.1+cu116             pypi_0    pypi
[conda] torchvision               0.13.1+cu116             pypi_0    pypi

cc @ngimel @pbelevich
DISABLED test_vmapjvpall_linalg_lu_cuda_float32 (__main__.TestOperatorsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: functorch

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_vmapjvpall_linalg_lu_cuda_float32&suite=TestOperatorsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/8836194077).

Over the past 3 hours, it has been determined flaky in 1 workflow(s) with 1 failures and 1 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_vmapjvpall_linalg_lu_cuda_float32`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @zou3519 @Chillee @samdow @soumith
DISABLED test_vmapjvpvjp_linalg_lu_cuda_float32 (__main__.TestOperatorsCUDA)
Labels: triaged, module: flaky-tests, skipped, module: functorch

Platforms: linux

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_vmapjvpvjp_linalg_lu_cuda_float32&suite=TestOperatorsCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/8828597209).

Over the past 3 hours, it has been determined flaky in 5 workflow(s) with 5 failures and 5 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_vmapjvpvjp_linalg_lu_cuda_float32`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @zou3519 @Chillee @samdow @soumith
Autograd doc does not mention torch.autograd.set_grad_enabled
Labels: module: docs, module: autograd, triaged, actionable

### 📚 The doc issue

[Autograd doc](https://pytorch.org/docs/stable/notes/autograd.html#locally-disable-grad-doc) does not mention `torch.autograd.set_grad_enabled`.

### Suggest a potential alternative/fix

Add reference to [`torch.autograd.set_grad_enabled`](https://pytorch.org/docs/stable/generated/torch.autograd.set_grad_enabled.html) used as function for disabling autograd in current thread.

cc @svekars @holly1238 @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
NVFuser `FusionRootMappingMultipleBroadcast_CUDA` raises exception on sm_80+ 
Labels: module: cuda, module: ci, triaged, module: nvfuser

### 🐛 Describe the bug

See here for example (only change that test is compiled with sm_86 and run on A10G )
https://github.com/pytorch/pytorch/actions/runs/3222501479/jobs/5272211415

```
[ RUN      ] NVFuserTest.FusionRootMappingMultipleBroadcast_CUDA
unknown file: Failure
C++ exception with description "Should not be mappable: iS0{i0} of T0_l[ iS0{i0} ] and iS1{i0} of T1_l[ iS1{i0}, bS2{1} ]
Exception raised from checkIdMapped at /home/nshulga/git/pytorch/pytorch/torch/csrc/jit/codegen/cuda/test/test_gpu.cpp:3084 (most recent call first):
frame #0: c10::Error::Error(c10::SourceLocation, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) + 0x6b (0x7f63622479bb in /home/nshulga/git/pytorch/pytorch/build/lib/libc10.so)
frame #1: c10::detail::torchCheckFail(char const*, char const*, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) + 0xbf (0x7f63622428bf in /home/nshulga/git/pytorch/pytorch/build/lib/libc10.so)
frame #2: <unknown function> + 0x621c5c (0x55d14faf4c5c in ./bin/test_jit)
frame #3: torch::jit::NVFuserTest_FusionRootMappingMultipleBroadcast_CUDA_Test::TestBody() + 0x2f3 (0x55d14faf5cc3 in ./bin/test_jit)
frame #4: void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) + 0x4a (0x55d14fc118aa in ./bin/test_jit)
frame #5: <unknown function> + 0x72b85f (0x55d14fbfe85f in ./bin/test_jit)
frame #6: <unknown function> + 0x72bb42 (0x55d14fbfeb42 in ./bin/test_jit)
frame #7: <unknown function> + 0x72c3b5 (0x55d14fbff3b5 in ./bin/test_jit)
frame #8: testing::internal::UnitTestImpl::RunAllTests() + 0xe2f (0x55d14fc0a6df in ./bin/test_jit)
frame #9: testing::UnitTest::Run() + 0x98 (0x55d14fc0aad8 in ./bin/test_jit)
frame #10: main + 0xfb (0x55d14f7043cb in ./bin/test_jit)
frame #11: __libc_start_main + 0xe7 (0x7f63612c0c87 in /lib/x86_64-linux-gnu/libc.so.6)
frame #12: _start + 0x2a (0x55d14f75e79a in ./bin/test_jit)
" thrown in the test body.
[  FAILED  ] NVFuserTest.FusionRootMappingMultipleBroadcast_CUDA (1 ms)
```

### Versions

CI

cc @ngimel @seemethere @pytorch/pytorch-dev-infra
NVFuser `FusionComputeAtMultiBCast_CUDA` and `FusionDetectSelfMappedDomains_CUDA` does not raise exception on sm_80+
Labels: module: cuda, module: ci, triaged, module: nvfuser

### 🐛 Describe the bug

See here for example (only change that test is compiled with sm_86 and run on A10G )
https://github.com/pytorch/pytorch/actions/runs/3222501479/jobs/5272211415
```
[ RUN      ] NVFuserTest.FusionDetectSelfMappedDomains_CUDA
/home/nshulga/git/pytorch/pytorch/torch/csrc/jit/codegen/cuda/test/test_gpu.cpp:3828: Failure
Expected: tv1->computeAt(tv4, 1) throws an exception.
  Actual: it doesn't.
[  FAILED  ] NVFuserTest.FusionDetectSelfMappedDomains_CUDA (0 ms)

```

### Versions

CI

cc @ngimel @seemethere @pytorch/pytorch-dev-infra
DISABLED test_attn_cuda (__main__.TestMin)
Labels: triaged, module: flaky-tests, skipped, module: functorch

Platforms: linux, win, windows

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_attn_cuda&suite=TestMin) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/8828175188).

Over the past 3 hours, it has been determined flaky in 4 workflow(s) with 4 failures and 4 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT BE ALARMED IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_attn_cuda`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


cc @zou3519 @Chillee @samdow @soumith
Performance tests mnist_hogwild-cpu_memory CPU memory increase by 30%
Labels: triaged, module: regression

### 🐛 Describe the bug

We are observing following performance regression 

mnist_hogwild-cpu_memory
1.12.1 cu116 (MB) : 307.691
1.13.0 cu116 (MB) : 395.91


CUDA 11.6, python 3.9 pytorch 1.12.1 vs 1.14 master
This confirms with the following test:
```
>> import torch
>>> print(f"torch: {torch.__version__}")
torch: 1.12.1
>>> import psutil
>>> psutil.Process().memory_info().rss / (1024 * 1024)
196.52734375
```
vs
```
>>> import torch
>>> psutil.Process().memory_info().rss / (1024 * 1024)
287.75390625
>>> print(f"torch: {torch.__version__}")
torch: 1.14.0.dev20221011
```





### Versions

1.13 and 1.14 master

cc @ezyang @gchanan @zou3519
Feature request: Deterministic test input generation
Labels: feature, module: tests, triaged

### 🚀 The feature, motivation and pitch

Today, PyTorch tests, especially OpInfo tests used in test_ops, generate random inputs. We then send the random inputs through tests and then compare them with some expected output with some pre-specified tolerance. This leads to some potential issues:

- test flakiness. It is often the case that a different set of random inputs will cause the test to fail because the new result is just beyond the bounds of the tolerance. From anecdotal experience this happens more often than a legitimate bug being discovered.
- inability to reproduce tests. There are also cases where it is difficult to reproduce a failure in CI (because the test inputs in CI produced a random tensor, but on a local machine the test inputs are a different random tensor).

Proposal: we should associate each OpInfo sample with a seed value that can be used to deterministically generate the same input (modulo floating point differences) across all (or most) platforms and devices. This will help test flakiness and test reproducibility, but may come at the cost of fewer bugs caught (because the seed will never change unless someone manually changes it).

### Alternatives

Instead of pre-associating each OpInfo sample with a seed, we could generate a new seed every time the test suite is run and print it out in the logs. This would make it so that our tests are reproducible but not help the flakiness problem

### Additional context

cc our testing tsars (@mruberry, @ngimel), and also @pytorch/pytorch-dev-infra (I'm curious how many flaky tests come up as a result of different random inputs being generated)

cc @mruberry