gopikrsmscs/torch-issues huggingface dataset:
MPS cumprod gradient is broken even when using cpu fallback on macos 13.2.1
Labels: triaged, module: mps

### 🐛 Describe the bug

While working on #104688 (which enables support for mps accelerated cumprod), I noticed that the gradient test of cumprod (`test_output_grad_match_cumprod_cpu_float32`) was failing only on the task [macos-12-py3-arm64-mps](https://github.com/pytorch/pytorch/actions/runs/5658964066/job/15332115951?pr=104688#logs). This task counter intuitively seems to use macos version 13.2.1 (see the Print Runner OS/HW Info section in the job). 

Originally I assumed this was my mistake or a bug with the mps cumprod op on 13.2.1 However I tried a version of the pr where I fell back to the cpu for cumprod instead of using the mps operation and noticed the issue was still there. However the problem could have still been in my code and I did not have a computer with mac os 13.2.1 to easily test on. So I created a [test pr](https://github.com/pytorch/pytorch/pull/106096) which changes none of the core pytorch code from main but runs the failing test `test_output_grad_match_cumprod_cpu_float32`with `PYTORCH_ENABLE_MPS_FALLBACK` enabled. 

You can see for yourself by looking at the results of the macos-12-py3-arm64-mps job on that pr that `test_output_grad_match_cumprod_cpu_float32` is failing with the exact same error despite none of the actually pytorch code changing. This confirms that the error is not in the code for #104688 but somewhere else in the gradient code for cumprod on mps. The gradient of cumprod uses [a bunch of different ops besides cumprod](https://github.com/pytorch/pytorch/blob/6f1042c0496731694635f559b9ae48a0d79d9099/aten/src/ATen/native/ReduceOps.cpp#L629) when not creating a graph so the problem could be in the mps versions of any of those.

If you have access to a mac with version 13.2.1 then reproing should be as easy as:
```
PYTORCH_ENABLE_MPS_FALLBACK=1 pytest test/test_mps.py -k test_output_grad_match_cumprod_cpu_float32 
```

Unfortunately I cannot fix this bug as I do not have access to the operating system it's breaking on except through the CI.

### Versions

In this particular case I don't think this makes sense because I repro'ed this error via the CI not on my computer. Since I cannot run `python collect_env.py` on the CI machine I cannot report much info.
```
machdep.cpu.brand_string: Apple M1
kern.osproductversion: 13.2.1
```

cc @kulinseth @albanD @malfet @DenisVieriu97 @razarmehr @abhudev
Fix test flakiness in test_sparse_triangular_solve
Labels: triaged, open source, Stale, topic: not user facing

Test test_sparse_triangular_solve_cuda_DTYPE sometimes fails with `nan` values in the output tensor. The tests only fail if run along together with the full test suite, but pass if run by itself. I think there are some flakiness in the memory management.

By running `empty_cache` before the test, the flakiness can be fully removed, and the test is fixed. It might slow down the test suites by a few seconds, but I think the time can be saved from reruns if it fails in the first few reruns.

internal ref: /4185082
Hack FSDP to work with CPU training
Labels: module: cpu, Stale, release notes: distributed (fsdp)

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #106099

Quick demo how FSDP on CPU can work. We need to improve the Stream
stub and add an Event stub that are noops for CPU, and fallback to collectives
that gloo does support.

To actually enable this, we may not want Gloo to fallback to allgather / reduce + scatter when using the unsupported collectives, and maybe handle this at the FSDP level instead. But that seems a little more brittle since future changes to FSDP can again use these unsupported colls directly, causing CPU training to break.

Differential Revision: [D47821700](https://our.internmc.facebook.com/intern/diff/D47821700/)

cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
DO NOT MERGE! Test if backwards cumprod is broken even when falling back on cpu on macos 13.2.1
Labels: triaged, open source, Stale, topic: not user facing, ciflow/mps

I do not have macos 13.2.1 so I am testing this here on the ci. If there is a better way please let me know. Please do not bother triaging this. Please also unassign this pr is possible (I don't think I have permissions to do it)
[do not review][Dynamo] Wait for lazy accumaultion of guards for input tensors
Labels: Stale, topic: not user facing, module: dynamo, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #106081


Looking for what CI shows up here, and how bad the problem is. Trying to check the complexity of solving - https://github.com/pytorch/pytorch/issues/106067


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @ipiszy
Potential lack of CI testing on older NVIDIA GPU
Labels: module: ci, triaged

## Issue description

Recently, we observe flaky issue with AWS G3 runner using Tesla M60 GPU https://github.com/pytorch/pytorch/issues/105721#event-9928505839.  The issue was mitigated by moving the job to the newer G5 runner using A10G.  Because the actual root cause is unclear, running on G5 could hide actual issues if it turns out to be something on PyTorch.  So this issue is here to track any future investigations on this area.

Here is an example failure where `nvidia-smi` hangs:

* [linux-bionic-cuda11.8-py3.9-gcc7 / test (multigpu, 1, 1, linux.16xlarge.nvidia.gpu)](https://hud.pytorch.org/pytorch/pytorch/commit/33b855e9069ddc98399c0dfd362f18df9503b66f)

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Tensors always get 0/1 specialization guards, even if they're not used
Labels: triaged, oncall: pt2, module: dynamic shapes, module: guards

### 🐛 Describe the bug

This recompiles but it shouldn't:

```
import torch

@torch.compile(backend="eager")
def f(x, y):
    return y + 2

f(torch.randn(0), torch.randn(2))
f(torch.randn(2), torch.randn(2))
```

`TORCHDYNAMO_PRINT_GUARDS=1 TORCH_LOGS=guards,dynamic,recompiles python n.py`

### Versions

main

cc @msaroufim @wconstab @bdhirsh @anijain2305
"Graph break: inline in skipfiles:" is a bad message
Labels: triaged, oncall: pt2, module: dynamo

### 🐛 Describe the bug

TORCH_LOGS=graph_breaks should produce user-understandable logs, but a log like `Graph break: inline in skipfiles: LazyGetItemMixin.__getitem__  | __getitem__ ` is completely impenetrable to any standard user. Need more info.

### Versions

main

cc @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @ipiszy @chenyang78 @aakhundov
Avoid incrementing refcount of `grad_fn` in `unpack_list`
Labels: module: autograd, triaged, module: mta

https://github.com/pytorch/pytorch/pull/105504 added an argument of `shared_ptr<Node>` which we ideally would `std::move` to avoid bumping refcount but it turned out impossible as we call the lambda multiple times.

rel:
- https://github.com/pytorch/pytorch/blob/c4b7311fc26a878ee594b6a65a66b38dfe22db86/tools/autograd/templates/Functions.h#L28-L45

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7 @mcarilli
[FSDP] Investigate sharded GPU gradient lifetime when CPU offloading
Labels: triaged, module: fsdp

I wonder if we are keeping a reference to the sharded GPU gradient even after the gradient offload to CPU has finished, resulting in unnecessary GPU memory usage. More broadly, we need to do some memory profiling for CPU offloading since there have been reports of it not saving GPU memory.

cc @zhaojuanmao @mrshenli @rohan-varma
DISABLED test_profiler_cuda_sync_events (__main__.TestProfiler)
Labels: module: rocm, triaged, skipped

Platforms: rocm

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/profiler%2Ftest_profiler.py%3A%3ATestProfiler%3A%3Atest_profiler_cuda_sync_events)).

Introduced by https://github.com/pytorch/pytorch/pull/105187

cc @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
DISABLED test_triton_template_with_epilogues_and_dynamic_shape (__main__.TestDoBench)
Labels: module: rocm, triaged, skipped

Platforms: rocm

This test was disabled because it is failing on master ([recent examples](http://torch-ci.com/failure/inductor%2Ftest_max_autotune.py%3A%3ATestDoBench%3A%3Atest_triton_template_with_epilogues_and_dynamic_shape)).

Looks like it was introduced by https://hud.pytorch.org/pytorch/pytorch/commit/98956c5320534cb66fd0dd69bc632122e16adba9

@jataylo to look into this further

cc @jeffdaily @sunway513 @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
[quant][fx] Fix node deletion bug during fx convert
Labels: triaged, open source, Stale, release notes: quantization, release notes: AO frontend

If a binary_op node `add_xx` is used by 2 nodes, and one of them is a `quantize_per_tensor_xx` node, it would be deleted during `convert`, `lower_to_native_backend` step, which would cause an error, because `torch.fx` is trying to delete a node which is used by another node.

It was found when I tried to quantize a EfficientNet model.
[FSDPxMTPG] Migrate TestFSDPTraversal
Labels: Stale, topic: not user facing

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #106003
* #106002
* #106001
* #106000
* #105999
* #105995
* #105991
* #105207
* #105206
* #105205
* #105180
* #105176

This test can be migrated to MTPG, saving ~4x test time.

Differential Revision: [D47784765](https://our.internmc.facebook.com/intern/diff/D47784765/)
[FSDPExecOrder] Migrate one test to MTPG
Labels: Stale, topic: not user facing

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #106003
* __->__ #106002
* #106001
* #106000
* #105999
* #105995
* #105991
* #105207
* #105206
* #105205
* #105180
* #105176

Only a single test can be migrated because the rest of the tests
capture warning.warnings which MTPG seems to have issues with. cc @kumpera

Differential Revision: [D47784763](https://our.internmc.facebook.com/intern/diff/D47784763/)
[FSDP test][ez] remove setUp()
Labels: Stale, topic: not user facing

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #106003
* #106002
* __->__ #106001
* #106000
* #105999
* #105995
* #105991
* #105207
* #105206
* #105205
* #105180
* #105176

Only calls the super method, so not needed

Differential Revision: [D47784764](https://our.internmc.facebook.com/intern/diff/D47784764/)
[ComposablexMTPG] Migrate some composable tests to MTPG
Labels: Stale, topic: not user facing

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #106003
* #106002
* #106001
* __->__ #106000
* #105999
* #105995
* #105991
* #105207
* #105206
* #105205
* #105180
* #105176

Per title

Differential Revision: [D47784762](https://our.internmc.facebook.com/intern/diff/D47784762/)
[FSDPxMTPG] Migrate one more test
Labels: Stale, topic: not user facing

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* #106003
* #106002
* #106001
* #106000
* __->__ #105999
* #105995
* #105991
* #105207
* #105206
* #105205
* #105180
* #105176

After Rodrigo's work to enable MTPG in backward pass, we can migrate
this test. the remaining tests are still on multiprocess due to things like
numerical issues when moving them to MTPG.

On 8 GPU A100 node, this test runtime is cut from ~92s to ~8s

Differential Revision: [D47784179](https://our.internmc.facebook.com/intern/diff/D47784179/)
Flatbuffer torchscipt files don't load in PyTorch Android Lite 1.13.1
Labels: oncall: jit

### 🐛 Describe the bug

When attempting to load a flatbuffer traced pytorch file, I get the following exception:

```
Caused by: com.facebook.jni.CppException: Flatbuffer input file but the build hasn't enabled flatbuffer
Exception raised from _load_mobile_from_bytes at /home/agunapal/pytorch/torch/csrc/jit/mobile/import.cpp:638 (most recent call first):
(no backtrace available)
    at org.pytorch.LiteNativePeer.initHybrid(Native Method)
    at org.pytorch.LiteNativePeer.<init>(LiteNativePeer.java:28)
    at org.pytorch.LiteModuleLoader.load(LiteModuleLoader.java:30)
    at ai.sensory.face.model.ImageProcessingModel.<init>(ImageProcessingModel.java:49)
    at ai.sensory.face.model.FaceLivenessModel.<init>(FaceLivenessModel.java:42)
    at ai.sensory.face.CaptureActivity.onCreate(CaptureActivity.java:195)
    at android.app.Activity.performCreate(Activity.java:7327)
    at android.app.Activity.performCreate(Activity.java:7318)
    at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1271)
    at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:3096)
    ... 11 more
```

### Versions

[1.13.1](https://mvnrepository.com/artifact/org.pytorch/pytorch_android_lite/1.13.1)

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
[aarch64][xplat/caffe2] Fix aarch64 build
Labels: fb-exported, Stale, topic: not user facing

Summary: Add missing dep to pull in sleef headers.

Test Plan:
```
$ buck2 build -c fbcode.arch=aarch64 fbsource//xplat/caffe2:cpukernel_avx2
```

Reviewed By: r1mikey, ajaymh

Differential Revision: D47772650
[DONOTMERGE][ROCm]Test MI210 CI Nodes
Labels: module: rocm, open source, ciflow/trunk, topic: not user facing, ciflow/periodic, keep-going, ciflow/slow

Fixes #ISSUE_NUMBER


cc @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Test
Labels: Stale, module: inductor, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #105966
* #105687



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @ColinPeppler @ngimel
Ensure PRs are rebased on top of a recent commit (CI check)
Labels: triaged, module: devx

**Goal**: Reduce breaks from land races

**Context**
Today our PR staleness checks only check to see that CI was run on the PR within the past X days, but it doesn't check how old the merge base was (despite many of us thinking that's what it does!)

Let's align reality with our expectations and make this actually happen. CI checks seem like a good option for this

**Exit criteria**
A CI Check that fails if it notices that the mergebase of the pr and trunk is more than X business days old (3 seems like a good value to use). 

If the check fails, we'd ideally post a comment on the PR sharing the commands the dev should run to rebase their PR.

Defining this to use business days in order to avoid requiring rebases right after the weekend


cc @kit1980 @huydhn @clee2000
ReplayRecordTests.test_fn_call_args and others fail on my local devserver
Labels: triaged, oncall: pt2, module: dynamo

### 🐛 Describe the bug

The failures look like this

```
__________________________________________________ ReplayRecordTests.test_fn_call_args ___________________________________________________
Traceback (most recent call last):
  File "/data/users/ezyang/c/pytorch/test/dynamo/test_replay_record.py", line 186, in test_fn_call_args
    self.check_replay(
  File "/data/users/ezyang/c/pytorch/test/dynamo/test_replay_record.py", line 50, in check_replay
    with self.assertLogs(logger="torch._dynamo", level=logging.ERROR) as log_orig:
  File "/home/ezyang/local/c/pytorch-env/lib/python3.10/unittest/_log.py", line 84, in __exit__
    self._raiseFailure(
  File "/home/ezyang/local/c/pytorch-env/lib/python3.10/unittest/case.py", line 163, in _raiseFailure
    raise self.test_case.failureException(msg)
AssertionError: no logs of level ERROR or higher triggered on torch._dynamo

To execute this test, run the following from the base repo dir:
     python test/dynamo/test_replay_record.py -k test_fn_call_args

This message can be suppressed by setting PYTORCH_PRINT_REPRO_ON_FAILURE=0
```

I have checked and confirmed that an exception is being raised, there just is no ERROR log. It's not obvious to me why I would necessarily expect the exception to show up in logs. Oddly, these seem to pass in CI

I'm running on Python 3.10.11. Please reach out if you need help reproducing.

### Versions

main

cc @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @ipiszy @chenyang78 @aakhundov
PT2 is not thread safe
Labels: triaged, oncall: pt2

### 🐛 Describe the bug

PT2 compilation stack is not thread safe. We do not test for this very carefully and I suspect https://github.com/pytorch/pytorch/pull/105942 may not be the last fix we need for this.

cc @msaroufim @wconstab @bdhirsh @anijain2305 @eellison who also suffered under fake tensor thread safety

### Versions

main
[FSDP] Support `OptimStateDictConfig.offload_to_cpu` for real
Labels: feature, triaged, actionable, module: fsdp

With https://github.com/pytorch/pytorch/pull/105848, I added the doc for `OptimStateDictConfig.offload_to_cpu` describing `offload_to_cpu: bool`; however, the bool does not actually work at the moment and only supports `True`. This issue is to track adding support for real.

https://github.com/pytorch/pytorch/blob/71d18f61059dbb617a8afc79b64598d2fbb89d63/torch/distributed/fsdp/api.py#L329-L339

cc @zhaojuanmao @mrshenli @rohan-varma @fegin @wz337
Flip default on `add_zero_attn` in `torch.nn.MultiheadAttention` to `True`
Labels: module: nn, triaged, oncall: transformer/mha

### 🚀 The feature, motivation and pitch

I'm working on implementing a modified version of Softmax to be used in Transformer models that could greatly improve the performance of these models across the board. Evan Miller outlines the change in the blog post linked below, and it is an extremely simple one. This is my first issue on the pytorch library and I am happy to begin working on it.

From what I know, this would involve:
1. Creating a new function within torch.nn.functional that resembles the torch.nn.functional.softmax code.
2. Add similar functionality to the next layers of code that inherit from torch.nn.functional. The quantized version comes to mind.
3. Add an nn.Module that while similar to nn.Softmax, uses the new torch.nn.functional.softmax_one code to be written for point 1.

Credit to Evan Miller for this enlightening discovery: https://www.evanmiller.org/attention-is-off-by-one.html

### Alternatives

A possible alternative could be me publishing my own nn.Module as a separate function.

### Additional context

This improvement is something that, while it would require retraining for Transformer models that want to use this new optimization, would not introduce any breaking changes to the torch library.

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @bhosmer @cpuhrsch @erichan1 @drisspg
DISABLED test_cross_entropy_large_tensor_reduction_sum_cuda (__main__.TestNNDeviceTypeCUDA)
Labels: module: nn, module: rocm, triaged, module: flaky-tests, skipped

Platforms: rocm

This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/failure/test_cross_entropy_large_tensor_reduction_sum_cuda) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/15304850679).

Over the past 72 hours, it has flakily failed in 6 workflow(s).

**Debugging instructions (after clicking on the recent samples link):**
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Grep for `test_cross_entropy_large_tensor_reduction_sum_cuda`


Test file path: `test_nn.py`

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki @jeffdaily @sunway513 @jithunnair-amd @pruthvistony @ROCmSupport @dllehr-amd @jataylo @hongxiayang
Dynamo silently ignores TorchDispatchMode
Labels: triaged, module: __torch_dispatch__, oncall: pt2, module: dynamo

### 🐛 Describe the bug

This test fails:

```
diff --git a/test/dynamo/test_misc.py b/test/dynamo/test_misc.py
index 4ac6b803ddb..43083783cc3 100644
--- a/test/dynamo/test_misc.py
+++ b/test/dynamo/test_misc.py
@@ -38,6 +38,7 @@ from torch._dynamo.testing import (
     unsupported,
 )
 
+from torch.utils._python_dispatch import TorchDispatchMode
 from torch._dynamo.utils import CompileProfiler, ifdynstaticdefault
 from torch.ao.quantization import MinMaxObserver
 from torch.ao.quantization.fake_quantize import FakeQuantize
@@ -6040,6 +6041,22 @@ def ___make_guard_fn():
         self.assertEqual(counter.frame_count, 1)
         self.assertEqual(counter.op_count, 3)
 
+    def test_mode_guard(self):
+        class RewriteAddToMul(TorchDispatchMode):
+            def __torch_dispatch__(self, func, types, args=(), kwargs=None):
+                if func is torch.ops.aten.add.Tensor:
+                    func = torch.ops.aten.mul.Tensor
+                return func(*args, **kwargs)
+
+        def fn(x):
+            return x + x
+
+        x = torch.tensor([3.0])
+        with RewriteAddToMul():
+            r = fn(x)
+            opt_r = torch.compile(fn)(x)
+        self.assertEqual(r, opt_r)
+
     def test_tracing_nested_py_tree(self):
         import torch.utils._pytree as pytree
 
```

Note that if you don't make torch.compile unconditionally bail out and have it handle torch dispatch mode, you need to add appropriate guards; this test doesn't exercise that the guards are correct.

### Versions

main

cc @Chillee @zou3519 @albanD @samdow @msaroufim @wconstab @bdhirsh @anijain2305 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @ipiszy @chenyang78 @aakhundov
enabling fused A16W8 mm through prologue fusion WIP
Labels: Stale, module: inductor, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #105926

Summary: note: for something like torch.mm(x, weight.to(torch.float16))*scale+bias even with scale, bias being multi-dimensional, this PR handles the prologue fusion and the epilogue fusion happens correctly without needing to do anything.

codegen: https://gist.github.com/HDCharles/d8a1ff7d52fcafcb7a0d880596b2c0c1
benchmarks: https://gist.github.com/HDCharles/3deb02e26e3d53f106c15216ff0e608a

Test Plan:

Reviewers:

Subscribers:

Tasks:

Tags:

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
Possible speed up of nn.MultiheadAttention
Labels: oncall: transformer/mha

### 🚀 The feature, motivation and pitch

Hello,
Implementing MHA using the `opt_einsum` package speeds up the MultiheadAttention by ~30%:
```python
from math import sqrt
from opt_einsum import contract as einsum

d = Q.shape[-1]
A = einsum('b n h c, b m h c -> b n m h', Q, K) / sqrt(d)
A = A.softmax(2)

y = einsum('b n m h, b m h c -> b n h c', A, V).reshape(B, N, -1)
```
On my machine (NVIDIA RTX A4000 Laptop GPU) it runs 30% faster and on a Tesla V100 it runs 65% faster when compared against calling the forward pass of `nn.MultiheadAttention` for both PyTorch 1.13 and 2.0.

I don't know if this implementation is feasible, but there's that.

### Alternatives

_No response_

### Additional context

The function used to measure speed:
```python
def timeit(func, N=1000):
    start = torch.cuda.Event(enable_timing=True)
    end = torch.cuda.Event(enable_timing=True)

    start.record()
    for _ in range(N):
        func()
    end.record()

    torch.cuda.synchronize()
    print(start.elapsed_time(end))
```

cc @jbschlosser @bhosmer @cpuhrsch @erichan1 @drisspg
torch.compile(cpu) does not handle float16 properly
Labels: triaged, oncall: pt2, module: cpu inductor

### 🐛 Describe the bug

```python
import torch
a = torch.randn(64, dtype=torch.float16)

@torch.compile
def f(a, dim=-1):
    na = torch.linalg.vector_norm(a, dim=dim)
    eps = 1e-8
    return na.clamp_min(eps)

f(a)
```

This does work with `bfloat16`. The issue here is that `bfloat16` works because there exists the magic helper function
https://github.com/pytorch/pytorch/blob/5f6c6ff4cf27e4924aee4e3c951efe83bf95c106/torch/_inductor/codegen/cpp.py#L2516
This function inserts the necessary `to_dtype`s for `bfloat16` to work. This hack should either be removed or generalised to other dtypes.

### Versions

master

cc @ezyang @msaroufim @wconstab @bdhirsh @anijain2305
Batching rule for aten::bincount.
Labels: triaged, module: functorch

### 🚀 The feature, motivation and pitch

I used `torch.bincount()` in a function that was passed to `torch.func.vmap()` and got this warning:


> UserWarning: There is a performance drop because we have not yet implemented the batching rule for aten::bincount. **Please file us an issue on GitHub** so that we can prioritize its implementation. (Triggered internally at ../aten/src/ATen/functorch/BatchedFallback.cpp:82.)

I'm filing an issue as requested : ) 

### Alternatives

_No response_

### Additional context

_No response_

cc @zou3519 @Chillee @samdow @kshitij12345 @janeyx99
Enable xpu backend in totchdynamo benchmarks
Labels: open source, Stale, module: dynamo, ciflow/inductor

Add xpu backend for torchdynamo benchmarks

cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @anijain2305 @ipiszy
torch.jit.frontend.NotSupported when compiling stable-diffusion
Labels: oncall: jit

### 🐛 Describe the bug

```
from diffusers import UNet2DConditionModel as model

unet = model.from_pretrained("CompViz/stable-diffusion-v1-4", subfolder="unet", torchscript=True)
# torchscript=True is from troch_tensorrt bert case

unet = torch.jit.script(unet)
```
then got torch.jit.frontend.NotSupportedError: keyword-arg expansion is not supported

I use torch.jit.script to adapt torch_tensorrt(as torchtrt).ts.compile. 

Using torch.jit.trace would face Aten dtype not support error, and using torchtrt.compile would face torchtrt.expanddim error

If this bug happens causing from the mismatch between torchtrt/torch.jit and diffusers.models, is there any way to compile diffusers' model without writing the unet instead of import, or writing the engine using nvidia/tensorRT python API without torchtrt to compile it? Thanks for any possible solution!

p.s. I have already remove all assert and branch using tensor result like `assert input_shape[0]==xxx manually` in diffusers.

### Versions

docker image: nvcr.io/nvidia/pytorch:22.11-py3
platform: DGX-A100 40GB(SXM)
python packages:
    pytorch 1.13.0a0+936e930
    torch_tensorrt 1.3.0a0
    diffusers 0.19.0.dev0
other CPU/memory/... env is unrelated, if need, i would list them here

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Add oneDNN Graph fusion pass in Inductor CPP backend
Labels: triaged, module: mkldnn, open source, release notes: jit, module: inductor, module: dynamo, ciflow/inductor

[RFC: Integrating oneDNN Graph Compiler into Inductor C++/OpenMP Backend for Enhanced Graph Fusion and Performance #105582](https://github.com/pytorch/pytorch/issues/105582)

- [ ] need to update python binding file after #97957

Handling the opaque op is referred to #90356 


cc @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh @jgong5 @mingfeima @sanchitintel @ashokei @jingxu10 @min-jean-cho @yanbing-j @Guobing-Chen @Xia-Weiwen @voznesenskym @penguinwu @EikanWang @zhuhaozhe @blzheng @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @anijain2305
Programmation error enabling unlegal memory access on gpu
Labels: module: error checking, triaged, module: mps

### 🐛 Describe the bug

Hi, in the following code I make a voluntary indexing logic error, as I wanted to index a tensor w.r.t multiple indexes at once. When I send all the tensors on cpu, an indexing error is raised which is fine. But, when I send it on my macOS mps device, I don't have any raised error and I can show that non legal memory is accessed instead. I understand the programmation error  I am voluntary making, but should an error be raised or is it normal?

The code is the following for the minimal reproducible error:
```
import torch as T

def access_non_legal_memory(batch_size=9):
    some_tensor = T.tensor([[0,0,1,1], [1,1,0,0]], device='mps')[None, :, :]
    non_legal_memory = some_tensor[T.arange(batch_size), T.unsqueeze(T.tensor([0,1,1,0,1,0,1,1,0], device='mps'), dim=0)]
    print(non_legal_memory)

if __name__=="__main__":
    access_non_legal_memory()
```

The output printed is:
tensor([[[0, 0, 1, 1],
         [0, 0, 0, 0],
         [0, 0, 0, 0],
         [0, 0, 0, 0],
         [1, 0, 1, 1],
         [0, 0, 0, 0],
         [0, 0, 0, 0],
         [0, 0, 0, 0],
         [0, 1, 2, 3]]], device='mps:0')

And as I said, on cpu an error is raised as it should.


### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.4 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.26.3
Libc version: N/A

Python version: 3.10.4 (main, Mar 31 2022, 03:37:37) [Clang 12.0.0 ] (64-bit runtime)
Python platform: macOS-13.4-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: True

CPU:
Apple M1 Max

Versions of relevant libraries:
[pip3] numpy==1.21.5
[pip3] pytorch-ignite==0.4.12
[pip3] torch==2.0.1
[pip3] torch-scatter==2.1.1
[pip3] torch-sparse==0.6.17
[pip3] torchvision==0.13.0
[conda] numpy                     1.22.3                   pypi_0    pypi
[conda] numpy-base                1.21.5          py310h742c864_3  
[conda] pytorch-ignite            0.4.12                   pypi_0    pypi
[conda] torch                     2.0.1                    pypi_0    pypi
[conda] torch-scatter             2.1.1                    pypi_0    pypi
[conda] torch-sparse              0.6.17                   pypi_0    pypi
[conda] torchvision               0.13.0                   pypi_0    pypi
(PTorchEnv) dominikrichard@REC-P-778273 Deep % 


cc @malfet @kulinseth @albanD @DenisVieriu97 @razarmehr @abhudev
Report model flop utilization (mfu) in benchmark
Labels: feature, triaged, oncall: pt2

### 🐛 Describe the bug

This should be easy to do by running flop counter on the eager model (or even on fake tensors in dynamo analysis) to compute the theoretical maximum throughput. This would help us control for eager model being extremely extremely bad; it gives us an absolute yardstick to measure against, rather than speedup against eager (which can be gamed by slowing eager down.)

### Versions

main

cc @msaroufim @wconstab @bdhirsh @anijain2305
[WIP][Experiment] Avoid real computation for dynamo export
Labels: open source, Stale, module: dynamo, ciflow/inductor

Stack from [ghstack](https://github.com/ezyang/ghstack) (oldest at bottom):
* __->__ #105858



cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng @anijain2305 @ipiszy
Bug when dealing with fallbacks on CPU
Labels: triaged, module: complex, module: dynamic shapes, module: inductor, module: cpu inductor

### 🐛 Describe the bug

To repro, patch in https://github.com/pytorch/pytorch/pull/105850, change the line
https://github.com/pytorch/pytorch/blob/3045e84e679a23ba3d5a5071b79593724098f389/test/test_linalg.py#L4313
for `torch.compile(torch.matmul)(x, y)`, and run
```bash
python test/test_linalg.py -vk test_matmul_small_brute_force_1d_Nd_cpu_complex64
```

It fails with the following traceback
```
  File "/home/lezcano/git/pytorch/pytorch/torch/fx/interpreter.py", line 138, in run
    self.env[node] = self.run_node(node)
  File "/home/lezcano/git/pytorch/pytorch/torch/_inductor/graph.py", line 658, in run_node
    result = fallback_handler(n.target, add_to_fallback_set=False)(
  File "/home/lezcano/git/pytorch/pytorch/torch/_inductor/lowering.py", line 1291, in handler
    TensorBox.create, ir.FallbackKernel.create(kernel, *args, **kwargs)
  File "/home/lezcano/git/pytorch/pytorch/torch/_inductor/ir.py", line 3430, in create
    return generate_output(example_output, [])
  File "/home/lezcano/git/pytorch/pytorch/torch/_inductor/ir.py", line 3427, in generate_output
    assert output is None, f"FallbackKernel output type {type(output)} is not supported"
torch._dynamo.exc.BackendCompilerFailed: backend='inductor' raised:
AssertionError: FallbackKernel output type <class 'torch.SymInt'> is not supported
```

It fails when creating a fallback for:
```
aten.sym_size                                                                                                                                                                                                        
(TensorBox(StorageBox(                                                                                                                                                                                               
  InputBuffer(name='arg3_1', layout=FixedLayout('cpu', torch.complex64, size=[0, s0, 0], stride=[s0, 1, 1]))                                                                                                         
)), 1)                                                                                                                                                                                                               
{}  
```

This is odd, as `sym_size` does have a lowering.

### Versions

master

cc @ezyang @anjali411 @dylanbespalko @mruberry @Lezcano @nikitaved @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov
Exporting the operator 'aten::grad' to ONNX opset version 18 is not supported.
Labels: module: onnx, module: autograd, triaged

### 🚀 The feature, motivation and pitch

I am attampting to conver a model from pytorch to ONNX, inside which there is a gradient calculation operation:
torch.autograd.grad(params...)
(I was using the backward hooks to get gradients, but torchscript does not support that)

And then when it calls
jitscriptModule = torch.jit.script(model)   # good, and torchscript pt model works well
torch.onnx.export(jitscriptModule, tensor, "converted.onnx") # bad, operator not supported occurs.

torch.onnx.errors.UnsupportedOperatorError: Exporting the operator 'aten::grad' to ONNX opset version 18 is not supported.

### Alternatives

Using pytorch 2.0.1

### Additional context

Will this feature be supported by future pytorch? 

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano @Varal7
Add UT for NEON implementation of vec_reduce_all 
Labels: module: cpu, triaged, open source, Stale, ciflow/trunk, release notes: sparse

All these changes are required to add a UT for the NEON implementation of `vec_reduce_all` that I introduced in #105590.
This enables reuse of the existing tests in aten/src/ATen/test/vec_test_all_types.cpp

As requested, I have made a separate PR for these changes so that this can land before #105590.



cc @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
[MPS] aten::erfinv bug fix: add storage offset buffers to handle slicing
Labels: triaged, open source, release notes: mps, ciflow/mps

A bug fix of a recently merged PR per comment: https://github.com/pytorch/pytorch/pull/101507#discussion_r1271393706

The follow test would fail without this bug fix:

```
import torch
def test_erfinv():
    for device in ['cpu', 'mps']:
        x = torch.tensor([0.1, 0.2, 0.3, 0.4, 0.5], device=device)
        y = x[2:].erfinv()

        x2 = torch.tensor([0.3, 0.4, 0.5], device=device)
        y2 = x2.erfinv()

        print(y)
        print(y2)

        torch.testing.assert_close(y, y2)
        print(f"{device} passes.")

test_erfinv()
```
inconsistent signature for dataloader in docs/source/data.rst
Labels: module: dataloader, triaged

### 📚 The doc issue

docs/source/data.rst indicates the signature of the dataloader with `prefetch_factor=2` but the class uses `None` as default. This is confusing and the signature should be updated. 

### Suggest a potential alternative/fix

Replace the current signature in the docs
```
DataLoader(dataset, batch_size=1, shuffle=False, sampler=None,
           batch_sampler=None, num_workers=0, collate_fn=None,
           pin_memory=False, drop_last=False, timeout=0,
           worker_init_fn=None, *, prefetch_factor=2,
           persistent_workers=False)
```
with the current signature in the code
```
DataLoader(dataset, batch_size=1, shuffle=None, sampler=None, batch_sampler=None, num_workers=0, collate_fn=None, pin_memory=False, drop_last=False, timeout=0, worker_init_fn=None, multiprocessing_context=None, generator=None, *, prefetch_factor=None, persistent_workers=False, pin_memory_device='')
```

cc @SsnL @VitalyFedyunin @ejguan @dzhulgakov
Enable the RUF013 rule in ruff
Labels: open source, release notes: fx, module: inductor, module: dynamo, ciflow/inductor, suppress-bc-linter

As suggested by @Skylion007 in https://github.com/pytorch/pytorch/pull/105791#issuecomment-1646644405

This rule enforces `Optional[...]` as the type for parameters having a default value of None.

Apply all RUF013 patches from ruff. Apply all other ruff patches in the affected files - otherwise lintrunner fails the build.

Fixes parts of #105230


cc @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @Xia-Weiwen @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @ngimel @yf225 @chenyang78 @kadeng @muchulee8 @aakhundov @anijain2305
[BUG] Fix grad_ready_order_indices' error type in DDP
Labels: triaged, open source, Stale, release notes: distributed (c10d)

The type of grad_ready_order_indices_ should be std::vector<size_t> instead of std::vector<int>.
In https://github.com/pytorch/pytorch/blob/afd955f3de4050e9617245fbd40769859b10515b/torch/csrc/distributed/c10d/reducer.hpp#L527, the type of grad_ready_order_indices_ is std::vector<int>.
In https://github.com/pytorch/pytorch/blob/afd955f3de4050e9617245fbd40769859b10515b/torch/csrc/distributed/c10d/reducer.cpp#L649, the index is directly inserted into grad_ready_order_indices_, and the type of index is size_t.
A type mismatch occurred during this process, and an overflow may occur.
torch.sparse.mm() with reduce operator for GPU support and COO matrices
Labels: module: sparse, feature, triaged, module: reductions

### 🚀 The feature, motivation and pitch

I am working on a ML program and need to use sparse matrix multiplication with "reduce" operator. 

Here is an example:
```
a = torch.sparse_coo_tensor(torch.tensor([[0, 0, 1, 1, 2, 2], [0, 1, 0, 1, 0, 1]]), [1., 2., 3., 4., 5., 6.], size=[3, 2])
b = torch.tensor([[7, 9], [8, 10]], dtype=torch.float, requires_grad=True)
# a and b are the input. a is a sparse-COO matrix, and b is a typical dense matrix with grad
a_csr = a.to_sparse_csr()
c = torch.sparse.mm(a_csr, b, "max")
print(c) # c is what I want
```
Currently the above codes is the only way for my work, but it runs quite slow for not supporting GPU, and is redundant for converting COO to CSR.

What I hope to be possible: 
1. enable GPU support to the reduce operator, and
2. enable COO matrix with the reduce operator.

Thanks a lot for your help!


### Alternatives

_No response_

### Additional context

According to the docs [here](https://pytorch.org/docs/stable/generated/torch.sparse.mm.html#torch.sparse.mm), currently `reduce` is implemented only for CSR storage format on CPU device.

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer
Mode to warm up PT2 with a regular eager mode execution
Labels: triaged, oncall: pt2

### 🐛 Describe the bug

When we originally were designing the warmup policy of PT2, we had a lot of discussion about whether or not we should do background compilation vs wait for compilation on the very first round. We never ended up doing background compilation because it is a bit of work for a Python compilation stack (GIL contention means that you'd have to do it out of process... out of process is complicated...) Another problem was that PT2 could potentially apply memory saving optimizations, that might end up being mandatory: your model would OOM if not run under PT2. (In practice, this is rarely the case today, and even when it is true people have a preference for keeping their eager mode runnable.)

I think a more limited form of warmup would be useful for PT2, and possibly even should be the default setting. Instead of immediately attempting to compile, we instead only do a Dynamo level analysis and then bail to the regular CPython interpreter. Only when the frame is deemed sufficiently hot do we actually perform compilation.

This "wait and see" strategy has several benefits:

1. We can record how long a frame takes in eager mode. If the walltime of the frame is very low, there is not much benefit to compiling it, and we can choose to skip it (even if, in principle, we could compile it.) If we do end up compiling it, we can compare how long eager took with compile without user intervention, and automatically report how much speed up PT2 gave. This is a great benefit in a production setting, since we can monitor the benefit of PT2 and observe the effect of optimizations in aggregate.
2. If a frame is dynamic (sizes/ints vary from run to run), we can avoid compiling an overly specialized frame; by waiting, we are more likely to predict which sizes truly are dynamic and properly compile them. We can also partially solve the problem described in https://github.com/pytorch/pytorch/issues/105634#issuecomment-1645624378 by using the *largest* observed size for tuning (in this case, the user may need to assist in saying when warmup should end.)
3. If a frame will eventually be skipped, we can detect if this would happen, by generating "ghost" guards which we check if they match. If we see that we never manage a cache hit, we can give up before we've actually spent time doing expensive inductor lowering compilation. (This is also incomplete, as we won't generate guards from AOTAutograd/Inductor, but my guess is these are not the bulk of the recompilation reasons.)

(1) by itself is compelling enough that I would add this as an option. But I am really tantalized by the prospect of automatic telemetry about how much speedup PT2 is giving.

cc @msaroufim @wconstab @bdhirsh @anijain2305 @kumpera whose questions inspired me to think more carefully about this

### Versions

main
https://pytorch.org/docs/stable/backends.html does not describe torch.backends.cpu
Labels: module: docs, module: cpu, triaged, actionable

### 📚 The doc issue

I was looking for the possible return values from torch.backends.cpu.get_cpu_capability() but the backends doc page did not list cpu, let alone get_cpu_capabilities

### Suggest a potential alternative/fix

_No response_

cc @svekars @carljparker @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Revisit checkpoint naming mismatch with torch name (and ONNX initializer name as a consequence)
Labels: module: onnx, triaged

Addresses https://github.com/pytorch/pytorch/blob/main/torch/onnx/_internal/fx/serialization.py#L138-L152 within `save_model_with_external_data` utility.

The hugging face model, for example, may have a checkpoint with keys `transformer.h.0.attn.bias` while the fx model has name `h.0.attn.bias`

Track why this discrepancy happens and fix it, if applicable
`torch.unique()` messes around with order even if `sorted=False`
Labels: module: docs, triaged, actionable, module: sorting and selection

### 🐛 Describe the bug

Hi, 

When I use `torch.unique` without specifying `dim` (in which case it is known that PyTorch will sort the output, cf. [here](https://pytorch.org/docs/stable/generated/torch.unique.html)) and when specifying `sorted=False`, I find that PyTorch still messes around with the order. 

**Code for reproducing:**
```python
import torch 

unique_classes, counts = torch.unique(
    input=torch.tensor([0, 0, 2, 1, 1, 1]).long(), 
    sorted=False, 
    return_counts=True
)
print(unique_classes, counts)
```
yields the output 
```python
(tensor([1, 2, 0]), tensor([3, 1, 2]))
```

**Expected behavior:**:
Since the element `0` appears before `1` or `2` in the input tensor, I would expect `unique_classes` to be 
```python
tensor([0, 2, 1])
```
instead of 
```python
tensor([1, 2, 0])
```

Best, 
Imahn

### Versions

conda 23.3.1
PyTorch 2.0.1 (GPU version)

cc @svekars @carljparker @ezyang @gchanan @zou3519
Pypi is missing dependencies
Labels: oncall: binaries

### 🐛 Describe the bug

Asking Pypi.org for a list of dependencies for torch does not provide a complete list of dependencies. See the list from pypi's json:
```
~$ curl -s 'https://pypi.org/pypi/torch/json' | jq '.info.requires_dist|.[]'
"filelock"
"typing-extensions"
"sympy"
"networkx"
"jinja2"
"opt-einsum (>=3.3) ; extra == 'opt-einsum'"
```
And now compare it with the actual list of dependencies in the wheel file's metadata:
```
~$ grep -i requires-dist torch-2.0.1-cp39-cp39-manylinux1_x86_64/torch-2.0.1.dist-info/METADATA
Requires-Dist: filelock
Requires-Dist: typing-extensions
Requires-Dist: sympy
Requires-Dist: networkx
Requires-Dist: jinja2
Requires-Dist: nvidia-cuda-nvrtc-cu11 (==11.7.99) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cuda-runtime-cu11 (==11.7.99) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cuda-cupti-cu11 (==11.7.101) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cudnn-cu11 (==8.5.0.96) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cublas-cu11 (==11.10.3.66) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cufft-cu11 (==10.9.0.58) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-curand-cu11 (==10.2.10.91) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cusolver-cu11 (==11.4.0.1) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-cusparse-cu11 (==11.7.4.91) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-nccl-cu11 (==2.14.3) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: nvidia-nvtx-cu11 (==11.7.91) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: triton (==2.0.0) ; platform_system == "Linux" and platform_machine == "x86_64"
Requires-Dist: opt-einsum (>=3.3) ; extra == 'opt-einsum'
```
I don't know why all the nvidida-* packages, as well as triton, are missing from the requires_dist field in the JSON of this package. Should they be there? This is a serious problem for people who are trying to build a consistent private python package mirror on an isolated network. We need to be able to programmatically determine all the dependencies for a package so that when we mirror the package, we also mirror it's requirements. If we cannot do this accurately, installing this package will fail on machines that cannot access pypi.org and rely on the mirror I'm building. 

### Versions

This is not relevant to this bug, as it does not rely on any specific python environment.

cc @seemethere @malfet