I think pytorch should add Windows support. Other deep learning frameworks, like tensorflow, theano and mxnet, all support Windows. I only use Windows in my work. So I want to know whether pytorch will support Windows in future.

the bug is described at pytorch/examples#148. I just wonder if this is a bug in PyTorch itself, as the example code looks clean to me. Also, I wonder if this is related to #1120.

File "", line 4, in import torch

File "C:\Users\hp i3\Anaconda3\lib\site-packages\torch_init_.py", line 76, in from torch._C import *

ImportError: DLL load failed: The specified module could not be found.

Hi,everyone! I met a strange illegal memory access error. It happens randomly without any regular pattern. The code is really simple. It is PointNet for point cloud segmentation. I don't think there is anything wrong in the code.

import torch
import torch.nn as nn
import torch.nn.functional as F
import os
class InstanceSeg(nn.Module):
    def __init__(self, num_points=1024):
        super(InstanceSeg, self).__init__()

        self.num_points = num_points

        self.conv1 = nn.Conv1d(9, 64, 1)
        self.conv2 = nn.Conv1d(64, 64, 1)
        self.conv3 = nn.Conv1d(64, 64, 1)
        self.conv4 = nn.Conv1d(64, 128, 1)
        self.conv5 = nn.Conv1d(128, 1024, 1)
        self.conv6 = nn.Conv1d(1088, 512, 1)
        self.conv7 = nn.Conv1d(512, 256, 1)
        self.conv8 = nn.Conv1d(256, 128, 1)
        self.conv9 = nn.Conv1d(128, 128, 1)
        self.conv10 = nn.Conv1d(128, 2, 1)
        self.max_pool = nn.MaxPool1d(num_points)

    def forward(self, x):
        batch_size = x.size()[0] # (x has shape (batch_size, 9, num_points))

        out = F.relu(self.conv1(x)) # (shape: (batch_size, 64, num_points))
        out = F.relu(self.conv2(out)) # (shape: (batch_size, 64, num_points))
        point_features = out

        out = F.relu(self.conv3(out)) # (shape: (batch_size, 64, num_points))
        out = F.relu(self.conv4(out)) # (shape: (batch_size, 128, num_points))
        out = F.relu(self.conv5(out)) # (shape: (batch_size, 1024, num_points))
        global_feature = self.max_pool(out) # (shape: (batch_size, 1024, 1))

        global_feature_repeated = global_feature.repeat(1, 1, self.num_points) # (shape: (batch_size, 1024, num_points))
        out = torch.cat([global_feature_repeated, point_features], 1) # (shape: (batch_size, 1024+64=1088, num_points))

        out = F.relu(self.conv6(out)) # (shape: (batch_size, 512, num_points))
        out = F.relu(self.conv7(out)) # (shape: (batch_size, 256, num_points))
        out = F.relu(self.conv8(out)) # (shape: (batch_size, 128, num_points))
        out = F.relu(self.conv9(out)) # (shape: (batch_size, 128, num_points))

        out = self.conv10(out) # (shape: (batch_size, 2, num_points))

        out = out.transpose(2,1).contiguous() # (shape: (batch_size, num_points, 2))
        out = F.log_softmax(out.view(-1, 2), dim=1) # (shape: (batch_size*num_points, 2))
        out = out.view(batch_size, self.num_points, 2) # (shape: (batch_size, num_points, 2))

        return out

Num = 0
network = InstanceSeg()
network.cuda()
while(1):

    input0 = torch.randn(32, 3, 1024).cuda()
    input1 = torch.randn(32, 3, 1024).cuda()
    input2 = torch.randn(32, 3, 1024).cuda()
    input = torch.cat((input0, input1, input2), 1)

    out = network(input)
    Num = Num+1
    print(Num)

After random number of steps, error raises. The error report is

Traceback (most recent call last):
  File "/home/wangye/Frustum-PointNet_Test/frustum_pointnet.py", line 58, in <module>
    input0 = torch.randn(32, 3, 1024).cuda()
RuntimeError: CUDA error: an illegal memory access was encountered

When I added "os.environ['CUDA_LAUNCH_BLOCKING'] = '1'" at the top of this script, the error report was changed to this

Traceback (most recent call last):
  File "/home/wangye/Frustum-PointNet_Test/frustum_pointnet.py", line 64, in <module>
    out = network(input)
  File "/home/wangye/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py", line 489, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/wangye/Frustum-PointNet_Test/frustum_pointnet.py", line 35, in forward
    out = F.relu(self.conv5(out)) # (shape: (batch_size, 1024, num_points))
  File "/home/wangye/anaconda3/lib/python3.6/site-packages/torch/nn/modules/module.py", line 489, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/wangye/anaconda3/lib/python3.6/site-packages/torch/nn/modules/conv.py", line 187, in forward
    self.padding, self.dilation, self.groups)
RuntimeError: cuDNN error: CUDNN_STATUS_EXECUTION_FAILED

I know some wrong indexing operations and some wrong usage method of loss function may lead to illegal memory access error. But in this script, there is no such kind of operation. I am quite sure this error is not because of out of memory since only about 2G GPU memory is used, and I have totally 12G GPU memory.

This is my environment information:

OS: Ubuntu 16.04 LTS 64-bit
Command: conda install pytorch torchvision cudatoolkit=9.0 -c pytorch
GPU: Titan XP
Driver Version: 410.93
Python Version: 3.6
cuda Version: cuda_9.0.176_384.81_linux
cudnn Version: cudnn-9.0-linux-x64-v7.4.2.24
pytorch Version: pytorch-1.0.1-py3.6_cuda9.0.176_cudnn7.4.2_2

I have been stuck here for long time. In fact, not only this project faces this error, many other projects face similar error in my computer. I don't think there is anything wrong in the code. It can run correctly for some steps. Maybe this error is because the environment. I am not sure. Does anyone have any idea about this situation? If more detailed information is needed, please let me know. Thanks for any suggestion.

CUDA Out of Memory error but CUDA memory is almost empty

I am currently training a lightweight model on very large amount of textual data (about 70GiB of text). For that I am using a machine on a cluster ('grele' of the grid5000 cluster network).

I am getting after 3h of training this very strange CUDA Out of Memory error message: RuntimeError: CUDA out of memory. Tried to allocate 12.50 MiB (GPU 0; 10.92 GiB total capacity; 8.57 MiB already allocated; 9.28 GiB free; 4.68 MiB cached). According to the message, I have the required space but it does not allocate the memory.

Any idea what might cause this ?

For information, my preprocessing relies on torch.multiprocessing.Queue and an iterator over the lines of my source data to preprocess the data on the fly.

Full stacktrace

Traceback (most recent call last):
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/site-packages/memory_profiler.py", line 1228, in <module>
    exec_with_profiler(script_filename, prof, args.backend, script_args)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/site-packages/memory_profiler.py", line 1129, in exec_with_profiler
    exec(compile(f.read(), filename, 'exec'), ns, ns)
  File "run.py", line 293, in <module>
    main(args, save_folder, load_file)
  File "run.py", line 272, in main
    trainer.all_epochs()
  File "/home/emarquer/papud-bull-nn/trainer/trainer.py", line 140, in all_epochs
    self.single_epoch()
  File "/home/emarquer/papud-bull-nn/trainer/trainer.py", line 147, in single_epoch
    tracker.add(*self.single_batch(data, target))
  File "/home/emarquer/papud-bull-nn/trainer/trainer.py", line 190, in single_batch
    result = self.model(data)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/site-packages/torch/nn/modules/module.py", line 489, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/emarquer/papud-bull-nn/model/model.py", line 54, in forward
    emb = self.emb(input)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/site-packages/torch/nn/modules/module.py", line 489, in __call__
    result = self.forward(*input, **kwargs)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/site-packages/torch/nn/modules/sparse.py", line 118, in forward
    self.norm_type, self.scale_grad_by_freq, self.sparse)
  File "/home/emarquer/miniconda3/envs/pytorch/lib/python3.6/site-packages/torch/nn/functional.py", line 1454, in embedding
    return torch.embedding(weight, input, padding_idx, scale_grad_by_freq, sparse)
RuntimeError: CUDA out of memory. Tried to allocate 12.50 MiB (GPU 0; 10.92 GiB total capacity; 8.57 MiB already allocated; 9.28 GiB free; 4.68 MiB cached)

New description from @ezyang:

Work is in progress at https://github.com/Roger-luo/pytorch-complex

Organizational principles

• Complex tensor support is important to PyTorch, and we will accept patches to core which add small amounts of code to make adding complex support.
• Adding complex involves writing a lot of new kernels and code: we'd like this code to initially live out of repo, so it is easier for people to iterate quickly on them without having to go through the PyTorch main code review process. We will NOT commit to reviewing large new kernels in the short term, but eventually we would like all the kernels to come back to PyTorch.
• The external library will be buildable separately from PyTorch, so you will be able to maintain it as a separate repository without having to merge with PyTorch (and deal with loads of merge conflicts).
  • PyTorch may occasionally make breaking changes in C++ API; if you bring these to our attention we will do our utmost to help solve these problems.
• The hooks needed for this will NOT ship with PyTorch 1.0, but they will ship with a released version of PyTorch in the not too distant future.

How will I work on complex kernels?

Here is what the workflow will look like in the steady state.

PyTorch will natively contain APIs for referring to the complex dtype, but they won't do anything by default. PyTorch defines torch.complex64 and torch.complex128 referring to complex tensors. However, if you try to construct a tensor this way, by default, PyTorch will error:

>>> torch.zeros({2,2}, dtype=torch.complex64)
RuntimeError: complex64 not supported by PyTorch

@ezyang provided a patch which adds these dtypes to PyTorch. https://github.com/pytorch/pytorch/pull/11173

In the mid-term, we will merge support for basic functionality (like allocating a tensor of zeros) to be supported by PyTorch natively. A reasonable proxy for what support is “basic” is PyTorch's native support for CPU half tensors (which are extremely impoverished).

PyTorch publishes an interface for registering an implementation of complex tensors. The implementation inherits from the TypeDefault class (https://github.com/pytorch/pytorch/pull/11013) and will override methods on this class to define implementations of functions for which we have complex implementations. It will look something like this:

struct CPUComplexFloatType final : public TypeDefault {
  virtual Tensor add(const Tensor & self, const Tensor & other, Scalar alpha=1) const override {
    // Your implementation of add for complex tensors
  }
  // ...
}

This class will override exactly the types which are supported for complex; all other implementations are provided by TypeDefault and will error by default.

There will be a canonical listing of methods supported on Type (the overall interface) as an autogenerated file that is checked into the PyTorch source repository; we'll communicate API changes by diffs to this file. In general, the methods are in one-to-one correspondence with their corresponding names in the PyTorch frontend.

In general, when you use an operation which you haven't implemented yet,

WARNING: We intend to refactor Type away into a new system that also supports open registration of new operations (this obviously doesn't work if you have a single superclass that defines all the methods you might possibly want to support). Thus, try not to get too tied to the particular implementation strategy of writing Type as a subclass.

To publish new, complex only operations, you will use the C++ extension API. The C++ extension API is documented at https://pytorch.org/tutorials/advanced/cpp_extension.html Essentially, you can write a C++ function like:

at::Tensor imag(at::Tensor z) {
  ...
}

And then the C++ extension API will generate a Python binding so that you invoke this function from Python.

Some operations will be “easy” to integrate into PyTorch as it exists today. For example, for implementation of binary operations, it probably makes more sense to extend add_kernel in BinaryOpsKernel.cpp so that it dispatches over complex types (and then you get it for free, because std::complex implements addition). As long as these patches are small and self-contained, we promise to merge them on a timely basis.

It should ALWAYS be possible to unblock, by just writing an override on Type instead of using existing infrastructure, and doing liberal copy pasting. But let's avoid it when it's easy!

Autograd. As long as you're working on operations which already have derivative formulas defined for them, you will “automatically” get autograd support, as long as you implement complex support for all the constituent functions which are invoked in the backwards implementation from derivatives.yaml.

In some cases, we may need to adjust autograd formulas so that they work for complex numbers; e.g., the gradient of 'abs' isn't 'grad . self.sign()'. In these cases, all we need to do is upstream fix of changing the autograd formula of 'abs' to 'abs_backward', which is a function that can be overridden.

For general complex valued back propagation, there are some references:

1. Akira’s “Complex Valued Neural Networks”.
2. https://giggleliu.github.io/2018/02/01/complex_bp.html

Generally, we won't need to modify the autograd since in most cases we only calculate the derivatives of a real-valued function (the loss).

Work plan

Many of the necessary pieces are in place today, but they are not put together in an end-to-end way. Here is what needs to be done.

• [X] Codemod TH to not ifdef real https://github.com/pytorch/pytorch/pull/11163
• [X] Built-in support for torch.complex64 and torch.complex128 dtypes. https://github.com/pytorch/pytorch/pull/11173
• [X] An interface for registering CPUComplexType, etc., so that this implementation is invoked when you request a complex tensor with dtype=torch.complex64 or do an operation on complex tensors.
• [X] Land https://github.com/pytorch/pytorch/pull/11013
• [X] An end-to-end example, including working build system, of a separately compileable C++ program that links against libtorch and uses the aforementioned interface to implement complex tensor allocation.

Short term integration plan. These operations are “easy” to implement, and so we should mainline them in PyTorch as soon as possible.

• [X] Basic tensor factories: torch.empty, torch.zeros, torch.ones
• [ ] CPU binary operations: add, sub, mul, div #11641
• [ ] FFT
• [ ] ???

Kernel implementation:

TODO: Generate a list based on https://github.com/Roger-luo/TH/blob/master/ChangeLog.md

Other complex related tasks:

• [ ] Figure out the type promotion rules for complex tensors, and implement it in promoteTypes #11641

Historical issue content

Original comment from @PhilippPelz

I was wondering if there is interest in incorporating complex tensors into pytorch. For CPU support there is ztorch and I have written z-cutorch ( https://github.com/PhilippPelz/z-cutorch ) a while ago. It is a fork off cutorch before the refactoring for CudaHalfTensor (don't have the hardware yet). If it's not too much work, I would like to slowly integrate it with pytorch. I am using matplotlib for plotting via fb.ptyhon and it turns out a huge pain every time I reinstall my system (compiling all the dependencies), plus it seems pytorch will work under Windows soon, which one of my experiment PCs runs on. I would also need complex gradients, so I would sooner or later touch autograd as well. While tf supports complex tensors per se, it seems many ops don't support it yet (https://github.com/tensorflow/tensorflow/issues/2255), plus it seems a bit heavyweight for my purposes.

Maybe someone could say a few words how and where to start with this, if it's a welcome idea.

Stack from ghstack:

• -> #76006
• #76937

Enable NVFuser in OSS. Tests are passing, and we've also run tests in torchvision and torchaudio

Differential Revision: D35736977

If you have a question or would like help and support, please ask at our forums.

If you are submitting a feature request, please preface the title with [feature request]. If you are submitting a bug report, please fill in the following details.

Issue description

Recently, I figured out PyCharm cannot make auto-complete for torch.zeros.

PyCharm says

Cannot find reference 'zeros' in '__init__.py'

I dig it for a while I found broken Type Hints.

From these changes, https://github.com/pytorch/pytorch/commit/30ec06c140b0428d591e2f5007bc8046d1bdf7c4 https://github.com/pytorch/pytorch/wiki/Breaking-Changes-from-Variable-and-Tensor-merge

Especially, https://github.com/pytorch/pytorch/commit/30ec06c140b0428d591e2f5007bc8046d1bdf7c4#diff-14258fce7c17ccb97b488e64373b0803R308 @colesbury This line cannot make Type Hints for lots of IDEs.

Originally, torch.zeros was in torch/_C/__init__.py But, it moved to torch/_C/_VariableFunctions

Code example

https://gist.github.com/kimdwkimdw/50c18b5cf72c69c2d01bb4146c8a2b5c This is Proof of Concept for this bug.

If you look at main.py

import T_B as torch

torch.p2()  # IDE can detect `p2`
torch.p1    # IDE cannot detect `p1`

System Info

Please copy and paste the output from our environment collection script (or fill out the checklist below manually).

You can get the script and run it with:

wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py

• PyTorch or Caffe2:

• How you installed PyTorch (conda, pip, source): Any case for conda, pip, source.

• Build command you used (if compiling from source):

• OS: Any

• PyTorch version: 0.4.0

• Python version: 3.6.5

• CUDA/cuDNN version: .

• GPU models and configuration: .

• GCC version (if compiling from source): .

• CMake version: .

• Versions of any other relevant libraries:.

Edit: If you see this error, please go to https://pytorch.org/get-started/locally/ and download a wheel built with cuda 11.x

**Hi

I recently purchased RTX 3080 and got this error

GeForce RTX 3080 with CUDA capability sm_86 is not compatible with the current PyTorch installation. The current PyTorch install supports CUDA capabilities sm_37 sm_50 sm_60 sm_61 sm_70 sm_75 compute_37.

and my cuda version is following:

• torch.cuda_version
• Out[3]: '10.2'

Should I install the latest cudatoolkit 11.0? but It seems Pytorch only provides cudatoolkit 10.2 like below screenshot.

Is there any solution for this issue? How do I get sm_86 binary capability?

thanks in advance**

cc @malfet @seemethere @walterddr @ngimel

Tests for Vec256 classes #15676

Testing Current list:

• [x] Blends
• [x] Memory: UnAlignedLoadStore
• [x] Arithmetics: Plus,Minu,Multiplication,Division
• [x] Bitwise: BitAnd, BitOr, BitXor
• [x] Comparison: Equal, NotEqual, Greater, Less, GreaterEqual, LessEqual
• [x] MinMax: Minimum, Maximum, ClampMin, ClampMax, Clamp
• [x] SignManipulation: Absolute, Negate
• [x] Interleave: Interleave, DeInterleave
• [x] Rounding: Round, Ceil, Floor, Trunc
• [x] Mask: ZeroMask
• [x] SqrtAndReciprocal: Sqrt, RSqrt, Reciprocal
• [x] Trigonometric: Sin, Cos, Tan
• [x] Hyperbolic: Tanh, Sinh, Cosh
• [x] InverseTrigonometric: Asin, ACos, ATan, ATan2
• [x] Logarithm: Log, Log2, Log10, Log1p
• [x] Exponents: Exp, Expm1
• [x] ErrorFunctions: Erf, Erfc, Erfinv
• [x] Pow: Pow
• [x] LGamma: LGamma
• [x] Quantization: quantize, dequantize, requantize_from_int
• [x] Quantization: widening_subtract, relu, relu6 Missing:
• [ ] Constructors, initializations
• [ ] Conversion , Cast
• [ ] Additional: imag, conj, angle (note: imag and conj only checked for float complex)

Notes on tests and testing framework

• some math functions are tested within domain range
• mostly testing framework randomly tests against std implementation within the domain or within the implementation domain for some math functions.
• some functions are tested against the local version. ~~For example, std::round and vector version of round differs. so it was tested against the local version~~
• round was tested against pytorch at::native::round_impl. ~~for double type on Vsx vec_round failed for (even)+0 .5 values~~ . it was solved by using vec_rint
• ~~complex types are not tested~~ After enabling complex testing due to precision and domain some of the complex functions failed for vsx and x86 avx as well. I will either test it against local implementation or check within the accepted domain
• ~~quantizations are not tested~~ Added tests for quantizing, dequantize, requantize_from_int, relu, relu6, widening_subtract functions
• the testing framework should be improved further
• ~~For now -DBUILD_MOBILE_TEST=ONwill be used for Vec256Test too~~ Vec256 Test cases will be built for each CPU_CAPABILITY

Fixes: #15676

Summary: Heavily referenced how Hardswish was implemented.

This is a great intro task to get a taste of how a torch method is implemented in shader and tested.

Test Plan: Compared in metal shader metal version and cpu version result in tests.

https://pxl.cl/251kT

Reviewed By: SS-JIA

Differential Revision: D36732187

🐛 Describe the bug

Hi there! In certain cases it seems that torch does not detect when the src and dest of a tensor copy refer to the same memory location, and therefore performs an incorrect copy.

For example, in the following snippet:

import torch
torch.use_deterministic_algorithms(True)

frame_dim = 140
num_steps = 10
num_envs = 512


def go():
    torch.manual_seed(0)
    src = torch.randn(num_envs, num_steps, frame_dim).cuda()
    buffer = src.clone()

    # The problematic line - shift frames [0, 8] into [1, 9]
    buffer[:, 1 : num_steps] = buffer[:, 0 : (num_steps - 1)]

    print("Sum:", buffer.cpu().sum().item(), src.cpu().sum().item())


for i in range(10):
    go()

Even though the same operations are run every loop, the result of the shift is different every time (the left column is not consistent across multiple runs of the script either, while the right column is):

Sum: -413.53521728515625 -993.8636474609375
Sum: -132.9031982421875 -993.8636474609375
Sum: -186.0804443359375 -993.8636474609375
Sum: -177.52325439453125 -993.8636474609375
Sum: -24.764511108398438 -993.8636474609375
Sum: -245.3650665283203 -993.8636474609375
Sum: -408.0976867675781 -993.8636474609375
Sum: -464.16082763671875 -993.8636474609375
Sum: -417.3087463378906 -993.8636474609375

If I replace the problematic line with buffer[:, 1 : num_steps] = buffer[:, 0 : (num_steps - 1)].clone(), everything works as expected.

Moreover, if I make the buffer have a simpler shape by dropping the leading num_envs dimension, then torch successfully detects the problem and raises the error:

RuntimeError: unsupported operation: some elements of the input tensor and the written-to tensor refer to a single memory location. Please clone() the tensor before performing the operation.

Versions

Collecting environment information...
PyTorch version: 1.13.1
Is debug build: False
CUDA used to build PyTorch: 11.6
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.1 LTS (x86_64)
GCC version: (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0
Clang version: Could not collect
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.8.13 (default, Mar 28 2022, 11:38:47)  [GCC 7.5.0] (64-bit runtime)
Python platform: Linux-5.15.0-56-generic-x86_64-with-glibc2.17
Is CUDA available: True
CUDA runtime version: 11.6.124
CUDA_MODULE_LOADING set to: LAZY
GPU models and configuration: GPU 0: NVIDIA GeForce RTX 3090
Nvidia driver version: 515.43.04
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] pytorch-lightning==1.8.1
[pip3] torch==1.13.1
[pip3] torchaudio==0.13.1
[pip3] torchmetrics==0.9.2
[pip3] torchvision==0.14.1
[conda] blas                      1.0                         mkl  
[conda] cudatoolkit               11.3.1               h2bc3f7f_2  
[conda] mkl                       2021.4.0           h06a4308_640  
[conda] mkl-service               2.4.0            py38h7f8727e_0  
[conda] mkl_fft                   1.3.1            py38hd3c417c_0  
[conda] mkl_random                1.2.2            py38h51133e4_0  
[conda] numpy                     1.23.1           py38h6c91a56_0  
[conda] numpy-base                1.23.1           py38ha15fc14_0  
[conda] pytorch                   1.13.1          py3.8_cuda11.6_cudnn8.3.2_0    pytorch
[conda] pytorch-cuda              11.6                 h867d48c_0    pytorch
[conda] pytorch-lightning         1.8.1                    pypi_0    pypi
[conda] pytorch-mutex             1.0                        cuda    pytorch
[conda] torchaudio                0.13.1               py38_cu116    pytorch
[conda] torchmetrics              0.9.2                    pypi_0    pypi
[conda] torchvision               0.14.1               py38_cu116    pytorch

Stack from ghstack (oldest at bottom):

• -> #91893

This makes it easier for us to run only the skipped benchmarks and see if that actually started passing.

Signed-off-by: Edward Z. Yang [email protected]

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire

Stack from ghstack (oldest at bottom):

• -> #91892
• #91796

Signed-off-by: Edward Z. Yang [email protected]

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @desertfire

Stack from ghstack (oldest at bottom):

• -> #91891

Signed-off-by: Edward Z. Yang [email protected]

cc @mlazos @soumith @voznesenskym @yanboliang @penguinwu @anijain2305 @EikanWang @jgong5 @Guobing-Chen @chunyuan-w @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @desertfire

Stack from ghstack (oldest at bottom):

• -> #91890

Skylion007 has been diligently improving the state of our C++ code to follow best practices and make it possible to run lint on it (at the moment the code is so messy it cannot be linted), and I would like to give him review permissions to facilitate this work.

Signed-off-by: Edward Z. Yang [email protected]