Jason Ansel
Jason Ansel
#123804 was a correctness fix -- though maybe we could allowlist away whatever property is triggering the extra compile time.
For 3 What I am talking about is if someone `pip install`'s PyTorch, then they don't get the submodules. It seems like there is a deployment issue.
@pytorchbot merge
@pytorchbot merge
> Hey thanks for the work ! Was wondering if there's plans to support GPUs as well ? Thanks ! Yes, I plan to add GPU support after finishing work...
Here is some example output: ```py # Source Nodes: [add, sum_1], Original ATen: [aten.add, aten.sum] # add => add # sum_1 => sum_1 halide_kernel_0 = async_compile.halide(HalideMeta(argtypes=[HalideInputSpec(ctype='float*', name='in_ptr0', shape=['64L']), HalideInputSpec(ctype='float*', name='in_ptr1',...
@pytorchbot merge
In TorchDynamo [eval_frame.c](https://github.com/pytorch/pytorch/blob/main/torch/csrc/dynamo/eval_frame.c) was implemented in C (as opposed to C++ like the rest of PyTorch), because CPython headers (internal/pycore_frame.h, internal/pycore_pystate.h, etc) did not work from C++. This was a...
Yeah correct, it should be pretty trivial to schedule -- but it is a corner case the scheduler doesn't handle. This is coming from a unit test, but you occasionally...
Looks like this can be fixed with `halide.i64(0x7fffffff+1)`, but it would be good to have a better error message here.