Edward Z. Yang
Edward Z. Yang
Why don't you just put functorch keys after autocast? It directly solves (1); and I agree that in (2) it should be "as if" you ran autocast on a program...
But... isn't that the point? ``` import torch from torch.fx.experimental.proxy_tensor import make_fx import torch.nn.functional as F def f(x, w): return F.conv2d(x, w).sum() x = torch.randn(2, 3, 4, 4, device='cuda', requires_grad=True)...
Yes, I think I am fitting my intuition to what PyTorch master does today. What is muddying the waters is the autocast context manager, as compared to a hypothetical autocast...
See also #4047 which is a proposal to allow a custom setup to be an external executable, in which case the current setup stanza restrictions do not apply. CC @Ericson2314
I'm deferring to @Chillee for this.
There are two things I would suggest here: 1. If the first C-c attempts a graceful exit, the second C-c should hard exit. 2. I'm pretty sure the remaining hanging...
Try explicitly asking for 0.13, I see recent builds for that in https://download.pytorch.org/whl/nightly/torchaudio/
On the metaclass, you'd have to define `tp_methods` to have an instancecheck definition, then it should work
As an alternative, consider just making a google doc in our public folder and linking it in dev-discuss. Easier to keep up to date.
dynamic=True isn't going to work with inductor on current master, as we're still waiting on a batch of fixes from @Chillee . To preview if the dynamic shapes infra sans...