Question: def inverse(self): return Inverse.apply(self) <ins> def gesv(self, a): return Gesv.apply(self, a) </ins> def multinomial(self, num_samples=1, with_replacement=False): return Multinomial(num_samples, with_replacement)(self)

There seems to be regression in the dynamo export of the MONAI VNet model as regards . Export script: The versions I'm using is torch 2.5.0.dev20240625+cu121 Previous torch versions such as were able to export this model successfully. Perhaps dynamo was generating FX graph without the expm1 node previously? cc: PyTorch version: 2.5.0.dev20240625+cu121 Is debug build: False CUDA used to build PyTorch: 12.1 ROCM used to build PyTorch: N/A OS: Ubuntu 22.04.4 LTS (x8664) GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 Clang version: Could not collect CMake version: version 3.29.0 Libc version: glibc-2.35 Python version: 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] (64-bit runtime) Python platform: Linux-6.5.0-35-generic-x8664-with-glibc2.35 Is CUDA available: True CUDA runtime version: 12.4.131 CUDAMODULELOADING set to: LAZY GPU models and configuration: GPU 0: NVIDIA RTX A5000 Nvidia driver version: 535.171.04 cuDNN version: Probably one of the following: /usr/lib/x8664-linux- /usr/lib/x8664-linux- /usr/lib/x8664-linux- /usr/lib/x8664-linux- /usr/lib/x8664-linux- /usr/lib/x8664-linux- /usr/lib/x8664-linux- /usr/lib/x8664-linux- HIP runtime version: N/A MIOpen runtime version: N/A Is XNNPACK available: True CPU: Architecture: x8664 CPU op-mode(s): 32-bit, 64-bit Address sizes: 46 bits physical, 48 bits virtual Byte Order: Little Endian CPU(s): 20 On-line CPU(s) list: 0-19 Vendor ID: GenuineIntel Model name: Intel(R) Core(TM) i9-9820X CPU @ 3.

30GHz CPU family: 6 Model: 85 Thread(s) per core: 2 Core(s) per socket: 10 Socket(s): 1 Stepping: 4 CPU max MHz: 4200.0000 CPU min MHz: 1200.0000 BogoMIPS: 6599.98 Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constanttsc art archperfmon pebs bts repgood nopl xtopology nonstoptsc cpuid aperfmperf pni pclmulqdq dtes64 monitor dscpl vmx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca sse41 sse42 x2apic movbe popcnt tscdeadlinetimer aes xsave avx f16c rdrand lahflm abm 3dnowprefetch cpuidfault epb catl3 cdpl3 invpcidsingle pti ssbd mba ibrs ibpb stibp tprshadow flexpriority ept vpid eptad fsgsbase tscadjust bmi1 hle avx2 smep bmi2 erms invpcid rtm cqm mpx rdta avx512f avx512dq rdseed adx smap clflushopt clwb intelpt avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqmllc cqmoccupllc cqmmbmtotal cqmmbmlocal dtherm ida arat pln pts hwp hwpactwindow hwpepp hwppkgreq vnmi mdclear flushl1d archcapabilities Virtualization: VT-x L1d cache: 320 KiB (10 instances) L1i cache: 320 KiB (10 instances) L2 cache: 10 MiB (10 instances) L3 cache: 16.5 MiB (1 instance) NUMA node(s): 1 NUMA node0 CPU(s): 0-19 Vulnerability Gather data sampling: Mitigation;

Microcode Vulnerability Itlb multihit: KVM: Mitigation: VMX disabled Vulnerability L1tf: Mitigation; PTE Inversion; VMX conditional cache flushes, SMT vulnerable Vulnerability Mds: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Mitigation; Clear CPU buffers; SMT vulnerable Vulnerability Retbleed: Mitigation; IBRS Vulnerability Spec rstack overflow: Not affected Vulnerability Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and _user pointer sanitization Vulnerability Spectre v2: Mitigation; IBRS; IBPB conditional; STIBP conditional; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Mitigation; Clear CPU buffers; SMT vulnerable Versions of relevant libraries: [pip3] numpy==1.24.4 [pip3] onnx==1.16.0 [pip3] onnxscript==0.1.0.dev20240625 [pip3] optree==0.11.0 [pip3] pytorch-quantization==2.1.2 [pip3] pytorch-triton==3.0.0+ [pip3] torch==2.5.0.dev20240625+cu121 [pip3] torch-tensorrt==2.3.0a0 [pip3] torchaudio==2.4.0.dev20240625+cu121 [pip3] torchdata==0.7.1a0 [pip3] torchtext==0.17.0a0 [pip3] torchvision==0.20.0.dev20240625+cu121 [conda] Could not collect
I am not very sure, but this looks like the kind of ops that should get decomp'ed. do you know? could you help take a look as part of the op support work you are doing? Thanks!
Yes, it looks like there is a graph-changed in dynamo, which dynamo now decomposes elu for some reasons. Using can preserve elu and then successfully export though.

Yes can run but we would need to be resolved first since the weights are still not exported properly.
I can take a look at this.
should fix this.

Here, I can't export trivial net with sort() using dynamoexport(). Legacy () works fine, dynamoexport errors out : Unsupported FX nodes: {'callfunction': ['']}. Pytorch nightly 06/03 cc
a missing op, could you take this?
Not sure if related:
Hmmm. Ideally, ONNX should add a sort op. It doesn't have one. I wonder what the legacy exporter converts it to.
should fix this issue.

Are there any plans to implement something like tensorflow's and ? exists but it doesn't have the backward step implemented.
One workaround for the moment would be to write as , which should support backprop since . Adding support for should be trivial, the gradient for it can be found in
I'll add backward support for , which should be equivalent to . I'll try to do it later today.
How difficult would it be to add in batched versions (where only the final two dimensions are square) of GESV and inverse? Are there any plans for this?
If we have batched version of , then adapting the autograd part is very simple. There is an open issue already that discuss implementing batched gesv
Actually, there is an open PR for that, so it might be coming soon
I'll rebase the batched version of gesv. It'll come in soon
May I ask why gesv only support . As I saw from , it support that A is a MxN matrix, and B is a NxK matrix, then solve a matrix X (NxK). If I want to use a non-square matrix A in gesv, would you mind to let me know how to implement in PyTorch?
this doesn't exactly answer your question but you can add zero-rows to the A matrix until it becomes square.
thanks a lot, I find the solution, can solve the problem.
Any plan to add gradient calculation for gels?
I am also wondering if will have differentiation support. My current workaround is to use instead
I actually implemented overdetermined case following tensorflow implementation. For backward pass I only did basic grad test. On Monday, March 18, 2019, Johnson Zhong <:
Thanks, seems to work fine!


Question: Tensor forward(const Tensor& input) { this->_check_input_dim(input); <del> return F::detail::instance_norm( </del> <ins> return torch::nn::functional::detail::instance_norm( </ins> input, this->running_mean, this->running_var, this->weight, this->bias, this->is_training() || !this->options.track_running_stats(), this->options.momentum(), this->options.eps()); }

As part of pull request , F is redefined globally in nn/modules/batchnorm.h F is then used once in batchnorm.h and again in instancenorm.h not a bug, but a problem for anyone using F in some other way. it's solvable, but I don't see this pattern anywhere else in libtorch, was wondering if this use is an anomaly, and if we could use thanks cc
Thanks a lot for reporting! Yes this is an anomaly, and will be fixed by


Question: , dependencies() {} }; <del> struct FunctionTask { BackwardTask* base; std::shared_ptr<Function> fn; GradBuffer grad; FunctionTask(BackwardTask* base, std::shared_ptr<Function> fn, GradBuffer grad) : base(base) , fn(fn) , grad(std::move(grad)) {} }; </del> auto ReadyQueue::push_front(FunctionTask item) -> void { { std::lock_guard<std::mutex> lock(mutex);

Version include <stringin some cpp files: define order in The pre-defined struct is not passed by clang in macOS, so we should reorder them.
Simple fix


Question: self.assertFalse(found_data[data_point_idx]) found_data[data_point_idx] += 1 break <del> self.assertEqual(target, self.labels.narrow(0, data_point_idx, 1)) </del> <ins> self.assertEqual(target, self.labels[data_point_idx]) </ins> found_labels[data_point_idx] += 1 self.assertEqual(sum(found_data.values()), (i + 1) * batch_size) self.assertEqual(sum(found_labels.values()), (i + 1) * batch_size)

TensorDataset adds casts 1D target tensor to 2D which is not acceptable by NLL loss layer.
Fixed in .


Question: self.assertRaises(AssertionError, nn.Embedding, num_embeddings=10, embedding_dim=20, padding_idx=25) self.assertRaises(AssertionError, nn.Embedding, num_embeddings=10, embedding_dim=20, padding_idx=-25) <ins> # test backward when input contains padding_idx padding_idx = 0 embedding = nn.Embedding(5, 2, padding_idx=padding_idx) for n in (1, 2): for other_indices in ([], [1, 3], [2]): indices = torch.LongTensor(other_indices + [padding_idx] * n) pre = embedding.weight[padding_idx].clone() embedding(indices).sum().backward() after = (embedding.weight + embedding.weight.grad)[padding_idx] embedding.zero_grad() self.assertEqual(after, pre) </ins> def test_embedding_max_norm(self): embedding = nn.Embedding(22, 5, max_norm=1.0) input = Variable(torch.LongTensor([2, 8, 8, 6]))

I have a straightforward use case. Given a token (or word), lookup the embedding of the word, pass that through a linear layer and perform L2 regression. If the token corresponds to the of the embedding layer, throws an error saying OS: macOS High Sierra PyTorch version: 0.3.1 How you installed PyTorch (conda, pip, source): Tried both conda and pip Python version: 3.6.4 CUDA/cuDNN version: CPU GPU models and configuration: NA GCC version (if compiling from source): NA A script to reproduce the bug:
I got the same trouble, and it throw this error after some epochs of training. Does anyone have some solutions?


Question: super(TestCase, self).assertEqual(len(x), len(y), message) for x_, y_ in zip(x, y): self.assertEqual(x_, y_, prec, message) <ins> elif isinstance(x, bool) and isinstance(y, bool): super(TestCase, self).assertEqual(x, y, message) </ins> elif isinstance(x, Number) and isinstance(y, Number): if abs(x) == float('inf') or abs(y) == float('inf'): if allow_inf:

PyTorch version: 0.3.0 Python version: 3.5 GPU models and configuration: 8x NVIDIA Titan I found that requiresgrad setting in module is ignored when module is wrapped with nn.DataParallel. For example, This code should be executed because very small part of network activation (only fc layer) is stored for backward computation, but it results to run-time error: Internally, I found a crack in function which is in . In replicate function, it copies all parameter in module (# of replica times) with . In broadcasting code, it just defines new with default constructor parameter, which is always set to True. I think there can be some choices to fix this issue. is intended behavior for DataParallel, so we should use volatile (or ) to implement transfer learning in DataParallel model should be fixed to handle requires_grad when copying parameters. should be synchronizing in I think any of solution doesn't need lots of effort to fix it.


Question: Attributes: weight_ih_l[k] : the learnable input-hidden weights of the k-th layer (W_ir|W_ii|W_in), of shape <del> (input_size x 3*hidden_size) </del> <ins> `(input_size x 3*hidden_size)` </ins> weight_hh_l[k] : the learnable hidden-hidden weights of the k-th layer (W_hr|W_hi|W_hn), of shape <del> (hidden_size x 3*hidden_size) bias_ih_l[k] : the learnable input-hidden bias of the k-th layer (b_ir|b_ii|b_in), of shape (3*hidden_size) bias_hh_l[k] : the learnable hidden-hidden bias of the k-th layer (W_hr|W_hi|W_hn), of shape (3*hidden_size) </del> <ins> `(hidden_size x 3*hidden_size)` bias_ih_l[k] : the learnable input-hidden bias of the k-th layer (b_ir|b_ii|b_in), of shape `(3*hidden_size)` bias_hh_l[k] : the learnable hidden-hidden bias of the k-th layer (W_hr|W_hi|W_hn), of shape `(3*hidden_size)` </ins> Examples:: >>> rnn = nn.GRU(10, 20, 2)

From : Happened because of some change in the environment as it is also affecting historical builds. cc
This issue seems to come from within libuv, a dependency of TensorPipe. First guess: there's two conflicting versions of libuv (e.g., a preinstalled one and the one shipped as a submodule of TensorPipe), and we build the one shipped by TensorPipe but somehow it ends up including the headers of the other one? In particular, the constant it's complaining about was in , which became part of libuv 1.41.0, which is the version that TensorPipe bundles. But it seems those jobs are installing version 1.40.0 via conda: So the question is why are the conda headers picked up and prioritized? I feel this will require some CMake digging, and it's possible that the fix will have to land in libuv's upstream CMake files. Ugh.
BTW, if you want to validate this theory you can try setting this flag to : Which will cause TensorPipe to use the preinstalled libuv instead of building its own one. But please don't land this "workaround", as it will only lead to users coming to complain that they couldn't build PyTorch because their system has a libuv version that is too old for what TensorPipe needs.
this is definitely what is happening: libuv-1.40 is installed from conda, which does not have in the header: But I'm still confused why it started to happen just now [Edit] Can it be update that happened 4 hours ago?
Finally found a PR that caused a regression: (and testing were clearly regressed in CI: )


Question: bidirectional=bidirectional, batch_first=batch_first) <del> outputs_cpu = forward_backward( False, rnn, input_val, hx_val, rnn.all_weights) rnn_gpu = module(input_size, hidden_size, num_layers, bias=bias, dropout=dropout, bidirectional=bidirectional, batch_first=batch_first) </del> <ins> outputs_gpu = forward_backward( True, rnn_gpu, input_val, hx_val, rnn.all_weights) </ins> <del> outputs_gpu = forward_backward( True, rnn_gpu, input_val, hx_val, rnn.all_weights) compare_cpu_gpu(outputs_cpu, outputs_gpu) </del> <ins> compare_cpu_gpu(outputs_cpu, outputs_gpu) </ins> for nonlinearity in ('tanh', 'relu'): hx_val = torch.randn(num_layers, batch, hidden_size)

cuDNN backend for RNN stabilizes at large mem usage. The following code stabilizes for me at 14+GiB reported by nvidia-smi. The same RNN without cuDNN uses <2.5GiB.
Oops... any idea what's going on with the garbage collector in this case?
are you running this on a P100 GPU?
Yes, I observe similar behavior on Titan X Pascal
hmmm, do cudnn RNNs have weird memory-oversubscribing properties? If it wasn't for CuDNN RNN, then it's not unreasonable. we use a custom CUDA allocator that will oversubscribe if needed, but will free the memory blocks it's holding onto if it hits OOM / failed allocations.
Tried the same RNN in torch and am getting ~2.6GiB on nvidia-smi.
With cuDNN I'm getting a constant usage of 2241MB on my machine using PyTorch (M40).
are you using cudnnv5, or v6?
v5
no, cudnn does not do memory oversubscribing, and already tried the same network in lua torch with cudnn, where it gets expected memory usage. Also, he is getting OOMs on slightly bigger networks, where apparently caching allocator should have tried to free previous blocks. Interesting that can not repro this.
Just to make sure did you set when you ran? I left it as False in the repro.
I can repro in the docker image built from the current version on P100, and I go OOM after 8 batches with the same image on 1080, which generally should not happen - if there is enough memory to go through 1 batch, memory usage should not increase afterwards.
No, I just copied your script and ran it. Weird thing is that it goes OOM after 18 batches once I enable . Without it memory remains stable.
A lot of cudaMalloc allocations go not through THCudaMalloc, and never get freed:
So not going through THCudaMalloc is actually expected for storages allocated with THCStorage_(newWithSize), but what's not expected is to every time cudaMalloc bytes of rnn workspace, instead of reusing earlier allocations. (~784 MB allocations are for workspace, ~156MB allocations happen somewhere in criterion).
My guess is that the bug is at the Python level.

Either: Something is holding on to a Tensor longer than it should Something is creating a circular reference which prevents quick clean-up
The issue is that in creates cyclic references. It's made worse by the fact that it holds on to more memory than it should (like the workspace). You can see this by adding a as the first line in your for loop. With the explicit call to the GC every iteration, the memory usage doesn't explode.
how can these cyclic references be fixed?
Not sure yet, but I will fix it tomorrow with


Question: // torch.SparseTensor() if (num_args == 0) { self->cdata = THSTensor_(new)(LIBRARY_STATE_NOARGS); <del> return (PyObject*)self.release(); } PyObject *first_arg = PyTuple_GET_ITEM(args, 0); </del> <ins> } else { PyObject *first_arg = PyTuple_GET_ITEM(args, 0); </ins> <del> // torch.SparseTensor(size) if (num_args == 1 && THPUtils_checkLong(first_arg)) { long size = THPUtils_unpackLong(first_arg); self->cdata = THSTensor_(newWithSize1d)(LIBRARY_STATE size); } // torch.SparseTensor(torch.Size sizes) else if (num_args == 1 && THPSize_Check(first_arg)) { THLongStoragePtr sizes(THPUtils_unpackSize(first_arg)); self->cdata = THSTensor_(newWithSize)(LIBRARY_STATE sizes.get()); } // torch.SparseTensor(torch.LongTensor indices, torch.LongTensor values) else if (num_args == 2 && THPIndexTensor_Check(first_arg)) { PyObject *second_arg = PyTuple_GET_ITEM(args, 1); if (!THPTensor_(Check)(second_arg)) goto invalid_arguments; </del> <ins> // torch.SparseTensor(size) if (num_args == 1 && THPUtils_checkLong(first_arg)) { long size = THPUtils_unpackLong(first_arg); self->cdata = THSTensor_(newWithSize1d)(LIBRARY_STATE size); } // torch.SparseTensor(torch.Size sizes) else if (num_args == 1 && THPSize_Check(first_arg)) { THLongStoragePtr sizes(THPUtils_unpackSize(first_arg)); self->cdata = THSTensor_(newWithSize)(LIBRARY_STATE sizes.get()); } // torch.SparseTensor(torch.LongTensor indices, torch.LongTensor values) else if (num_args == 2 && THPIndexTensor_Check(first_arg)) { PyObject *second_arg = PyTuple_GET_ITEM(args, 1); if (!THPTensor_(Check)(second_arg)) goto invalid_arguments; </ins> <del> THIndexTensor *indices = ((THPIndexTensor*)first_arg)->cdata; THTensor *values = ((THPTensor*)second_arg)->cdata; </del> <ins> THIndexTensor *indices = ((THPIndexTensor*)first_arg)->cdata; THTensor *values = ((THPTensor*)second_arg)->cdata; </ins> #ifdef THC_GENERIC_FILE <del> THCAssertSameGPU(THSTensor_(checkGPU)(LIBRARY_STATE 0, 2, indices, values)); </del> <ins> THCAssertSameGPU(THSTensor_(checkGPU)(LIBRARY_STATE 0, 2, indices, values)); </ins> #endif <del> self->cdata = THSTensor_(newWithTensor)(LIBRARY_STATE indices, values); } // torch.SparseTensor(torch.LongTensor indices, //                    torch.Tensor values, //                    torch.Size sizes) else if (num_args > 2 && THPIndexTensor_Check(first_arg)) { PyObject *second_arg = PyTuple_GET_ITEM(args, 1); PyObject *third_arg = PyTuple_GET_ITEM(args, 2); if (!THPTensor_(Check)(second_arg)) goto invalid_arguments; if (!THPSize_Check(third_arg)) goto invalid_arguments; </del> <ins> self->cdata = THSTensor_(newWithTensor)(LIBRARY_STATE indices, values); } // torch.SparseTensor(torch.LongTensor indices, //                    torch.Tensor values, //                    torch.Size sizes) else if (num_args > 2 && THPIndexTensor_Check(first_arg)) { PyObject *second_arg = PyTuple_GET_ITEM(args, 1); PyObject *third_arg = PyTuple_GET_ITEM(args, 2); if (!THPTensor_(Check)(second_arg)) goto invalid_arguments; if (!THPSize_Check(third_arg)) goto invalid_arguments; </ins> <del> THIndexTensor *indices = ((THPIndexTensor*)first_arg)->cdata; THTensor *values = ((THPTensor*)second_arg)->cdata; THLongStoragePtr sizes(THPUtils_unpackSize(third_arg)); </del> <ins> THIndexTensor *indices = ((THPIndexTensor*)first_arg)->cdata; THTensor *values = ((THPTensor*)second_arg)->cdata; THLongStoragePtr sizes(THPUtils_unpackSize(third_arg)); </ins> #ifdef THC_GENERIC_FILE <del> THCAssertSameGPU(THSTensor_(checkGPU)(LIBRARY_STATE 0, 2, indices, values)); </del> <ins> THCAssertSameGPU(THSTensor_(checkGPU)(LIBRARY_STATE 0, 2, indices, values)); </ins> #endif <del> self->cdata = THSTensor_(newWithTensorAndSize)( LIBRARY_STATE indices, values, sizes); } // torch.SparseTensor(int ...) else if (THPUtils_tryUnpackLongVarArgs(args, 0, sizes)) { self->cdata = THSTensor_(newWithSize)(LIBRARY_STATE sizes.get()); </del> <ins> self->cdata = THSTensor_(newWithTensorAndSize)( LIBRARY_STATE indices, values, sizes); } // torch.SparseTensor(int ...) else if (THPUtils_tryUnpackLongVarArgs(args, 0, sizes)) { self->cdata = THSTensor_(newWithSize)(LIBRARY_STATE sizes.get()); } else goto invalid_arguments; // All other cases </ins> } <del> else goto invalid_arguments; // All other cases THSPTensor_(initStorage)(self->cdata); </del> <ins> THSTensor_(initStorage)(self->cdata); </ins> return (PyObject*)self.release(); invalid_arguments:

This causes to not work properly on newly created empty sparse tensors. In the example below, both should print 1 instead.


Question: flat_weight = first_data.new().set_(first_data.storage(), 0, torch.Size([self._param_buf_size])) else: flat_weight = None <ins> self.check_forward_args(input, hx, batch_sizes) </ins> func = self._backend.RNN( self.mode, self.input_size,

I run RNN sucessfully with the code. and I run embedding example. Then, got RuntimeError. I set to use nothing seems wrong. And the error info seems not the dim problem? The error is so strange.
What exactly do you mean by "embedding example"? Could you provide a code snippet that causes the RuntimeError?
To better reproduce the error, I use the official code example of The origin runs well: Due to use , I have to make batch first. And then , it raises error.
Thank you for the example! The say that setting means that the first dim of input is the batch, ie, input has size . however is unchanged, so the following should work: I do agree the error message could be better, though


Question: return platform <ins> def get_python_platform(): import platform return platform.platform() def get_libc_version(): import platform if get_platform() != 'linux': return 'N/A' return '-'.join(platform.libc_ver()) </ins> def get_pip_packages(run_lambda): """Returns `pip list` output. Note: will also find conda-installed pytorch and numpy packages."""

TensorPipe uses some advanced features of the Linux kernel. It does so on a "best effort" basis (i.e., use them if available, fall back on something else if not). This logic is unfortunately hard to test because it would require specific kernel versions on our CI machines. So it occasionally happens that we find out about issues when users report them. To help investigate these reports we've found it useful to know the kernel version and the glibc version used by the user (both when building and when running, if they're different). It would be great if these could be to the report produced by collect_env.
CC


Question: { /* Get normalized cumulative distribution from prob distribution */ double sum = 0; <ins> double val; </ins> for (j=0; j<n_categories; j++) { <del> sum += THStorage_(get)(  </del> <ins> val = THStorage_(get)(  </ins> prob_dist->storage,  prob_dist->storageOffset+i*prob_dist->stride[0]+j*prob_dist->stride[1]  ); <ins> THArgCheckWithCleanup((val >= 0), THCleanup(THDoubleTensor_free(cum_dist); if (start_dim == 1) THTensor_(resize1d)(prob_dist, n_categories);), 2, "invalid multinomial distribution (encountering probability entry < 0)"); sum += val; </ins> THDoubleStorage_set( cum_dist->storage,  cum_dist->storageOffset+j*cum_dist->stride[0],

Looking at the values returned from tn.multinomial(1) and counting them, it seems like it returns the values of the multinomial distribution taken from t, i.e. that it has ignored the signs of the values. However, it seem like always returns a tensor filled with zeros.
looking into this


Question: dict( module_name='AdaptiveMaxPool1d', constructor_args=(3,), <del> input=torch.rand(1, 3, 5), </del> <ins> input=_rand_tensor_non_equal(1, 3, 5), </ins> ), dict( module_name='AdaptiveMaxPool2d', constructor_args=(3,), <del> input=torch.rand(1, 3, 5, 6), </del> <ins> input=_rand_tensor_non_equal(1, 3, 5, 6), </ins> desc='single', ), dict( module_name='AdaptiveMaxPool2d', constructor_args=((3, 4),), <del> input=torch.rand(1, 3, 5, 6), </del> <ins> input=_rand_tensor_non_equal(1, 3, 5, 6), </ins> desc='tuple', ), dict( module_name='AdaptiveMaxPool3d', constructor_args=(3,), <del> input=torch.rand(2, 3, 5, 6, 7), </del> <ins> input=_rand_tensor_non_equal(2, 3, 5, 6, 7), </ins> desc='single', ), dict( module_name='AdaptiveMaxPool3d', constructor_args=((3, 4, 5),), <del> input=torch.rand(2, 3, 5, 6, 7), </del> <ins> input=_rand_tensor_non_equal(2, 3, 5, 6, 7), </ins> desc='tuple', ), dict( module_name='AdaptiveMaxPool3d', constructor_args=(3,), <del> input=torch.rand(2, 3, 12, 9, 3), </del> <ins> input=_rand_tensor_non_equal(2, 3, 12, 9, 3), </ins> desc='single_nonatomic', ), dict( module_name='AdaptiveMaxPool3d', constructor_args=((3, 4, 5),), <del> input=torch.rand(2, 3, 6, 4, 10), </del> <ins> input=_rand_tensor_non_equal(2, 3, 6, 4, 10), </ins> desc='tuple_nonatomic', ), dict(

Intermittent test failures occurring on AdaptiveMaxPool3d. and I have seen this in the past where Max pooling has exactly the same values in the same window, then it's differently resolved on CPU/GPU. For example [0 2.5 2.5 3] can give a max index of or on CUDA depending on the runtime. So generating input values that are within epsilon of each other is important (especially at half precision). fix that one.
Will do. Thanks for identifying the issue.


Question: 'symmetric_pd', NO_ARGS, [skipIfNoLapack]), ('logdet', lambda: make_nonzero_det(random_fullrank_matrix_distinct_singular_value(S), 1, 0), NO_ARGS, 'distinct_singular_values', NO_ARGS, [skipIfNoLapack]), <del> ('slogdet', lambda: make_nonzero_det(torch.randn(1, 1), 1), NO_ARGS, '1x1_pos_det', NO_ARGS, [skipIfNoLapack], [1]), </del> <ins> ('slogdet', lambda: make_nonzero_det(torch.randn(1, 1), 1), NO_ARGS, '1x1_pos_det', NO_ARGS, [skipIfNoLapack], itemgetter(1)), </ins> ('slogdet', lambda: make_nonzero_det(torch.randn(1, 1), -1), NO_ARGS, <del> '1x1_neg_det', NO_ARGS, [skipIfNoLapack], [1]), ('slogdet', lambda: make_nonzero_det(torch.randn(S, S), 1), NO_ARGS, 'pos_det', NO_ARGS, [skipIfNoLapack], [1]), ('slogdet', lambda: make_nonzero_det(torch.randn(S, S), -1), NO_ARGS, 'neg_det', NO_ARGS, [skipIfNoLapack], [1]), </del> <ins> '1x1_neg_det', NO_ARGS, [skipIfNoLapack], itemgetter(1)), ('slogdet', lambda: make_nonzero_det(torch.randn(S, S), 1), NO_ARGS, 'pos_det', NO_ARGS, [skipIfNoLapack], itemgetter(1)), ('slogdet', lambda: make_nonzero_det(torch.randn(S, S), -1), NO_ARGS, 'neg_det', NO_ARGS, [skipIfNoLapack], itemgetter(1)), </ins> ('slogdet', lambda: make_nonzero_det(random_symmetric_matrix(S)), NO_ARGS, <del> 'symmetric', NO_ARGS, [skipIfNoLapack], [1]), ('slogdet', lambda: random_symmetric_pd_matrix(S), NO_ARGS, 'symmetric_pd', NO_ARGS, [skipIfNoLapack], [1]), </del> <ins> 'symmetric', NO_ARGS, [skipIfNoLapack], itemgetter(1)), ('slogdet', lambda: random_symmetric_pd_matrix(S), NO_ARGS, 'symmetric_pd', NO_ARGS, [skipIfNoLapack], itemgetter(1)), </ins> ('slogdet', lambda: random_fullrank_matrix_distinct_singular_value(S), NO_ARGS, <del> 'distinct_singular_values', NO_ARGS, [skipIfNoLapack], [1]), </del> <ins> 'distinct_singular_values', NO_ARGS, [skipIfNoLapack], itemgetter(1)), </ins> ('svd', lambda: random_fullrank_matrix_distinct_singular_value(S), NO_ARGS, '', NO_ARGS, [skipIfNoLapack]), <del> ('svd', lambda: random_fullrank_matrix_distinct_singular_value(M), NO_ARGS, 'large', NO_ARGS, [skipIfNoLapack]), </del> <ins> ('svd', lambda: random_fullrank_matrix_distinct_singular_value(S)[:(S - 2)], NO_ARGS, 'wide', NO_ARGS, [skipIfNoLapack]), ('svd', lambda: random_fullrank_matrix_distinct_singular_value(S)[:, :(S - 2)], NO_ARGS, 'tall', NO_ARGS, [skipIfNoLapack]), ('svd', lambda: random_fullrank_matrix_distinct_singular_value(S)[:(S - 2)], (False,), 'wide_all', NO_ARGS, [skipIfNoLapack], lambda usv: (usv[0], usv[1], usv[2][:, :(S - 2)])), ('svd', lambda: random_fullrank_matrix_distinct_singular_value(S)[:, :(S - 2)], (False,), 'tall_all', NO_ARGS, [skipIfNoLapack], lambda usv: (usv[0][:, :(S - 2)], usv[1], usv[2])), ('svd', lambda: random_fullrank_matrix_distinct_singular_value(M), NO_ARGS, 'large', NO_ARGS, [skipIfNoLapack]), </ins> ('gesv', (S, S), ((S, S),), '', NO_ARGS, [skipIfNoLapack]), ('fill_', (S, S, S), (1,), 'number'), ('fill_', (), (1,), 'number_scalar'),

I am having problem in running the backward propagation with svd. In particular, it seems working when the first dimension of the matrix x (below) is greater than the second. But I get the following error if the first is smaller than the second. PyTorch version: 2018.04.20 Is debug build: No CUDA used to build PyTorch: 8.0.61 OS: Ubuntu 16.04.4 LTS GCC version: (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 CMake version: Could not collect Python version: 3.5 Is CUDA available: No CUDA runtime version: No CUDA GPU models and configuration: No CUDA Nvidia driver version: No CUDA cuDNN version: No CUDA Versions of relevant libraries: [pip3] numpy (1.13.3) [pip3] torch (2018.4.20) [pip3] torchvision (0.2.0) [conda] pytorch 0.3.1 py35cuda8.0.61cudnn7.0.52 pytorch [conda] pytorch-nightly 2018.04.20 py35cuda8.0.61cudnn7.1.21 pytorch [conda] torchvision 0.2.0 py35heaa392f_1 pytorch
Repro'ed on 0.4 branch. works btw.
What does "Repro'ed" means? Should I install from that branch? I need to compute the kernel of a matrix, therefore I need the last columns of the matrix V (which is why I have to pass ).
It's a shorthand for "reproduced", which means that the bug still hasn't been fixed. Sorry, we'll try to get to it soon.


Question: modules = self.__dict__['_modules'] if name in modules: return modules[name] <del> return object.__getattribute__(self, name) </del> <ins> return object.__getattr__(self, name) </ins> def __setattr__(self, name, value): <ins> def remove_from(*dicts): for d in dicts: if name in d: del d[name] </ins> params = self.__dict__.get('_parameters') if isinstance(value, Parameter): if params is None: raise AttributeError( "cannot assign parameters before Module.__init__() call") <ins> remove_from(self.__dict__, self._buffers, self._modules) </ins> self.register_parameter(name, value) elif params is not None and name in params: if value is not None:

They do one pair of these calls for each slicing operation.
Does this actually have a performance impact? These calls tend to be very quick
Yes, it's a major reason why small unrolled LSTMs (which involve in addition to two GEMMs: a chunk into four gates, for 4 pairs of calls, five unary pointwise ops, for 5 more, and five binary pointwise ops, for another 5) are much slower than they are in Theano and TensorFlow.
Also, there are excessive cudaGetDevice calls for each pointwise operation (9 cudaGetDevice) even without chunking, as in the following repro code: As for small unrolled LSTMs it does show up.
This should no longer be an issue, now that is implemented as a native ATen function. I think we're still using the Python version for tensors, but this will be resolved soon when we stop using tensors altogether.


Question: grad.zero_() def updateParameters(self, learningRate): <del> params, gradParams = self.parameters() if params: for p, gp in zip(params, gradParams): p.add_(-learningRate, gp) </del> <ins> if self.parameters() is not None: params, gradParams = self.parameters() if params: for p, gp in zip(params, gradParams): p.add_(-learningRate, gp) </ins> def training(self): self.train = True

I implemented a model using because I have to do particular things and I'm starting from a PyTorch implementation. I think this method may be broken. If I run this code: I get this error: This happens whenever the Sequential model has layers without parameters. Removing ReLUs and LogSoftMax solves the problem. I think this happens because returns for s which don't have parameters and raises the error. I tried this both on Python2.7 and Python 3.5 and it's the same.
Solved by


Question: CMAKE_PREFIX_PATH="$(dirname $(which conda))/../"  pip install -v . <ins> RUN git clone https://github.com/pytorch/vision.git && cd vision && pip install -v . </ins> WORKDIR /workspace RUN chmod -R a+w /workspace

Torchvision is considered a basic requirement of the tutorials. Perhaps it makes sense to include it in the docker build.
It's easy to install it by command ;)
It's easy to install torch itself using a similar command? :). I was thinking a docker image should have torchvision included.
Runtime docker file already has torchvision.


Question: #define THSTensorPtr  TH_CONCAT_3(THS,Real,TensorPtr) #define THSPTensorPtr  TH_CONCAT_3(THSP,Real,TensorPtr) <del> template<class T> class THPPointer { public: THPPointer(): ptr(nullptr) {}; THPPointer(T *ptr): ptr(ptr) {}; THPPointer(THPPointer &&p) { free(); ptr = p.ptr; p.ptr = nullptr; }; ~THPPointer() { free(); }; T * get() { return ptr; } T * release() { T *tmp = ptr; ptr = NULL; return tmp; } operator T*() { return ptr; } THPPointer& operator =(T *new_ptr) { free(); ptr = new_ptr; return *this; } THPPointer& operator =(THPPointer &&p) { free(); ptr = p.ptr; p.ptr = nullptr; return *this; } T * operator ->() { return ptr; } operator bool() { return ptr != nullptr; } private: void free(); T *ptr = nullptr; }; typedef THPPointer<PyObject> THPObjectPtr; </del> typedef THPPointer<THPGenerator> THPGeneratorPtr; template <typename T>

Go to Look at the html. It contains the following: ! This problem manifests in google search. Searching for 1.8.1 docs brings up the "1.8.0 docs": ! We can probably fix this by doing a quick sed on the website but we should develop a solution for future releases. I think this has happened before in the past and am not sure what causes it. cc


Question: output_var_.requires_grad = self->cdata.requires_grad; auto dummy_prev_fn = std::make_shared<Variable>( std::unique_ptr<Tensor>(output_var_.data->clone_shallow()), false, false); <del> self->cdata.previous_functions[i] = std::make_pair<>(dummy_prev_fn, 0); </del> <ins> // Replace all references to the variable auto& previous_functions = self->cdata.previous_functions; for (int inp = 0; inp < self->num_inputs; inp++) { if (previous_functions[inp].first.get() == &output_var_) { previous_functions[inp] = std::make_pair<>(dummy_prev_fn, 0); } } </ins> } else { // output_var_.requires_grad throw std::runtime_error("a leaf Variable that requires grad has been used in an in-place operation."); }

import torch as th from torch.autograd import Variable x = Variable(th.Tensor([1 , 2 , 3]) , requiresgrad = False) y = Variable(th.Tensor([100]) , requiresgrad = True) x = x.cuda(0) y = y.cuda(0) x[0] = y print(x.requiresgrad) If ((0) (0)) is executed then the output is False, True otherwise. I think the result that x.requiresgrad = True is more natural.
I further checked some in-place operator in GPU mode(say, x = Variable(...).cuda(0) ), and find out that after the operation is done, the requiresgrad of the Variable doesn't change. For example: import torch as th from torch.autograd import Variable x = Variable(torch.Tensor([1]) , requiresgrad = False) y = Variable(torch.Tensor([2]) , requiresgrad = True) x = x.cuda(0) y = y.cuda(0) x.add(y) print(x.requires_grad) the output is False
It doesn't have to do with Variable holding a CUDA tensor, but rather with the fact that it's no longer a leaf. I've sent a fix in .
Thanks for the report!


Question: #include <vector> #include <stack> #include <tuple> <del> #include "THCP.h" </del> <ins> #include "torch/csrc/cuda/THCP.h" </ins> <del> #include "override_macros.h" </del> <ins> #include "torch/csrc/cuda/override_macros.h" </ins> #include "torch/csrc/copy_utils.h" #include "DynamicTypes.h" <del> #define THC_GENERIC_FILE "torch/csrc/generic/Tensor.cpp" #include <THC/THCGenerateAllTypes.h> </del> <ins> //generic_include THC torch/csrc/generic/Tensor.cpp </ins> <del> #include "undef_macros.h" #include "restore_macros.h" </del> <ins> #include "torch/csrc/cuda/undef_macros.h" #include "torch/csrc/cuda/restore_macros.h" </ins>

Trying to run on github actions via AWS instance gives me: I will of course set up now, but it shouldn't crash like that. May be it should use as a fallback? pt-2.0 cc
Is this a multitenant setup? Also curious which distro are you running, I was under the impression that most linux distros set home by default
this is AWS image. one default user. I think it's user, but it wants you to run as root, which is weird. I have manually now set to overcome this.
We should update triton to use pathlib or something


Question: THArgCheck(THCTensor_(nDimension)(state, src) <= MAX_CUTORCH_DIMS, 2, CUTORCH_DIM_WARNING); THArgCheck(THCudaLongTensor_nDimension(state, index) <= MAX_CUTORCH_DIMS, 2, CUTORCH_DIM_WARNING); <del> int srcDims = THCTensor_(nDimension)(state, src); THArgCheck(srcDims > 0, 2, "Source tensor is empty"); </del> <ins> if (numIndices == 0) { return; } </ins> if (accumulate) { // wrap indices so to replace negative indices

odd difference between cuda Tensor and Variable: encountered in torch.distributions.Categorical, built yesterday from master
related to hmm, here's the issue is for variables, so probably not (immediately) related
different code path but similar issue
This is a regression from the latest 0.3 binaries, which don't have this error.


Question: `U, S, V = torch.svd(A)` returns the singular value decomposition of a real matrix `A` of size `(n x m)` such that :math:`A = USV^T`. <del> `U` is of shape :math:`(n times min(n, m))`. </del> <ins> `U` is of shape :math:`(n times n)`. </ins> <del> `S` is a diagonal matrix of shape :math:`(min(n, m) times min(n, m))`, represented as a vector of size :math:`min(n, m)` containing the diagonal entries. </del> <ins> `S` is a diagonal matrix of shape :math:`(n times m)`, represented as a vector of size :math:`min(n, m)` containing the diagonal entries. </ins> <del> `V` is of shape :math:`(m times min(n, m))`. </del> <ins> `V` is of shape :math:`(m times m)`. </ins> <del> :attr:`some` represents the number of singular values to be computed. If `some=True`, it computes some and `some=False` computes all. </del> <ins> If :attr:`some` is ``True`` (default), the returned `U` and `V` matrices will contain only :math:`min(n, m)` orthonormal columns. </ins> .. note:: Irrespective of the original strides, the returned matrix `U` will be transposed, i.e. with strides `(1, n)` instead of `(n, 1)`.

The documentation of the parameter to is one of the strangest I've seen... what does (the default) do???
Ha it is somewhat weird indeed. When , the returned U and V matrices are square orthonormal matrices. I will send out a PR to clarify this.


Question: return self.clone(); } <del> std::vector<int64_t> to_arg_sizes(TensorList tensors, int64_t dim) { </del> <ins> static std::vector<int64_t> to_arg_sizes(TensorList tensors, int64_t dim) { </ins> std::vector<int64_t> arg_sizes(tensors.size()); for (size_t i = 0; i < tensors.size(); ++i) { arg_sizes[i] = tensors[i].size(dim);

See Docker run fails with , which is due to the fact that is specified in docker container: Which results in: CI cc
Check that adding to manywheels image results in a failure:
Tentatively marking hi-pri since nightly testing are failing
This is resolved, here is the successful run:


Question: self._test_broadcast_helper(group, group_id, rank) @unittest.skipIf(BACKEND != 'gloo', "Only Gloo backend supports CUDA allReduce") <ins> @skip_if_no_cuda_distributed </ins> def test_broadcast_cuda(self): group, group_id, rank = self._init_global_test() self._test_broadcast_helper(group, group_id, rank, True)

is causing a crash when we try to build pytorch. Crash looks like this: (all times in US/West) Our 7AM, 8AM builds and earlier were all fine but 9AM, 10AM, 11AM builds all crashed with that same traceback. The new import was in which I think went in between 8AM and 9AM today See command below: See here if needed for : <!-- A clear and concise description of what you expected to happen. --Please copy and paste the output from our (or fill out the checklist below manually). You can get the script and run it with: PyTorch Version (e.g., 1.0): building from master OS (e.g., Linux): linux How you installed PyTorch (, , source): source Build command you used (if compiling from source): see above under 'reproduce' Python version: 3.6
maybe easier to read for build command used:
please try in the CircleCi environment?
in our build script seems to have fixed this. Thanks !


Question: self.assertEqual(res1, res2, 0) self.assertEqual(res1, res3, 0) <ins> def _test_overdetermined(a, b, expectedNorm): m = a.size()[0] n = a.size()[1] assert(m > n) def check_norm(a, b, expected_norm, gels_result): # Checks |ax - b| and the residual info from the result n = a.size()[1] # The first n rows is the least square solution. # Rows n to m-1 contain residual information. x = gels_result[:n] resid_info = gels_result[n:] resid_norm = (torch.mm(a, x) - b).norm() self.assertEqual(resid_norm, expectedNorm, 1e-8) self.assertEqual(resid_info.norm(), resid_norm, 1e-8) a_copy = a.clone() b_copy = b.clone() res1 = torch.gels(b, a)[0] self.assertEqual(a, a_copy, 0) self.assertEqual(b, b_copy, 0) check_norm(a, b, expectedNorm, res1) ta = torch.Tensor() tb = torch.Tensor() res2 = torch.gels(b, a, out=(tb, ta))[0] self.assertEqual(a, a_copy, 0) self.assertEqual(b, b_copy, 0) check_norm(a, b, expectedNorm, res2) res3 = torch.gels(b, a, out=(b, a))[0] check_norm(a_copy, b_copy, expectedNorm, res3) self.assertEqual(res1, tb, 0) self.assertEqual(res1, b, 0) self.assertEqual(res1, res2, 0) self.assertEqual(res1, res3, 0) </ins> # basic test expectedNorm = 0 a = torch.Tensor(((1.44, -9.96, -7.55, 8.34),

b = (600,1) A = (600,2) X, = (b,A) X.size() #torch.Size([2, 1]) Y, = (b.cuda(),A.cuda()) Y.size() #torch.Size([600, 1])
that is interesting. says that the first rows returned ( here) include the solution of the least-squares problem. I've verified that the first 2 rows of X and Y are the same so you can probably use that for now while we figure out what the rest of the output is.


Question: static struct PyGetSetDef conv_forward_properties[] = { THP_FUNCTION_DEFAULT_PROPERTIES, {(char*)"stride", (getter)getTupleAttr<ConvForward, std::vector<int>, ConvParams, <del> &ConvParams::stride, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::stride, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"padding", (getter)getTupleAttr<ConvForward, std::vector<int>, ConvParams, <del> &ConvParams::padding, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::padding, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"dilation", (getter)getTupleAttr<ConvForward, std::vector<int>, ConvParams, <del> &ConvParams::dilation, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::dilation, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"transposed", (getter)getValueAttr<ConvForward, bool, ConvParams, &ConvParams::transposed, long, PyBool_FromLong>, NULL, NULL, NULL}, {(char*)"output_padding", (getter)getTupleAttr<ConvForward, std::vector<int>, ConvParams, <del> &ConvParams::output_padding, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::output_padding, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"groups", (getter)getValueAttr<ConvForward, int, ConvParams, <del> &ConvParams::groups, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::groups, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {NULL} }; static struct PyGetSetDef conv_backward_properties[] = { THP_FUNCTION_DEFAULT_PROPERTIES, {(char*)"stride", (getter)getTupleAttr<ConvBackward, std::vector<int>, ConvParams, <del> &ConvParams::stride, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::stride, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"padding", (getter)getTupleAttr<ConvBackward, std::vector<int>, ConvParams, <del> &ConvParams::padding, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::padding, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"dilation", (getter)getTupleAttr<ConvBackward, std::vector<int>, ConvParams, <del> &ConvParams::dilation, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::dilation, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"transposed", (getter)getValueAttr<ConvBackward, bool, ConvParams, &ConvParams::transposed, long, PyBool_FromLong>, NULL, NULL, NULL}, {(char*)"output_padding", (getter)getTupleAttr<ConvBackward, std::vector<int>, ConvParams, <del> &ConvParams::output_padding, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::output_padding, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"groups", (getter)getValueAttr<ConvBackward, int, ConvParams, <del> &ConvParams::groups, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::groups, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {NULL} }; static struct PyGetSetDef conv_backward_backward_properties[] = { THP_FUNCTION_DEFAULT_PROPERTIES, {(char*)"stride", (getter)getTupleAttr<ConvBackwardBackward, std::vector<int>, ConvParams, <del> &ConvParams::stride, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::stride, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"padding", (getter)getTupleAttr<ConvBackwardBackward, std::vector<int>, ConvParams, <del> &ConvParams::padding, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::padding, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"dilation", (getter)getTupleAttr<ConvBackwardBackward, std::vector<int>, ConvParams, <del> &ConvParams::dilation, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::dilation, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"transposed", (getter)getValueAttr<ConvBackwardBackward, bool, ConvParams, &ConvParams::transposed, long, PyBool_FromLong>, NULL, NULL, NULL}, {(char*)"output_padding", (getter)getTupleAttr<ConvBackwardBackward, std::vector<int>, ConvParams, <del> &ConvParams::output_padding, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::output_padding, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {(char*)"groups", (getter)getValueAttr<ConvBackwardBackward, int, ConvParams, <del> &ConvParams::groups, int64_t, PyInt_FromLong>, NULL, NULL, NULL}, </del> <ins> &ConvParams::groups, int64_t, PortablePyInt_FromLong>, NULL, NULL, NULL}, </ins> {NULL} };

One representative error: The cause of the problem is : It seems that on clang, changing the type parameter here is sufficient to cause template instantiation to fail. Maybe the easiest way to fix this is to write a more portable version of PyIntFromLong (and friends) which always returns .


Question: id_map = {old_id: p for old_id, p in zip(chain(*(g['params'] for g in saved_groups)), chain(*(g['params'] for g in groups)))} <del> state = defaultdict( dict, {id_map.get(k, k): v for k, v in state_dict['state'].items()}) </del> <ins> def cast(param, value): """Make a deep copy of value, casting all tensors to device of param.""" if torch.is_tensor(value): # Floating-point types are a bit special here. They are the only ones # that are assumed to always match the type of params. if any(tp in type(param.data).__name__ for tp in {'Half', 'Float', 'Double'}): value = value.type_as(param.data) value = value.cuda(param.get_device()) if param.is_cuda else value.cpu() return value elif isinstance(value, dict): return {k: cast(param, v) for k, v in value.items()} elif isinstance(value, Iterable): return type(value)(cast(param, v) for v in value) else: return value # Copy state assigned to params (and cast tensors to appropriate types). # State that is not assigned to params is copied as is (needed for # backward compatibility). state = defaultdict(dict) for k, v in state_dict['state'].items(): if k in id_map: param = id_map[k] state[param] = cast(param, v) else: state[k] = v </ins> # Update parameter groups, setting their 'params' value def update_group(group, new_group):

Hi, I encountered this bug: The code skeleton is like: It seems the loaded are , and I've tried a workaround to move to , but it still has the same bug.
Could you provide a full script to reproduce the problem?
maybe you can try like this, () (beta1).add_(1 - beta1, ())
Sorry, I missed the reply email. I am afraid that I am unable to provide a reproducer now. It is a work I am doing for the OpenNMT-py , trying to use for doing lr update. And I encoutered this problem when testing the case. So I factored out the code skeleton about this problem above. I've tried several methods, including tricks like what suggests, but it still happens. Per my analysis, it is because the previous training was done on gpu, so when saving the , the stored states(tensors) are of version. During resuming, when we load the saved optimizer, loads this version to cpu(the model() can be moved to gpu easily, but seems lacking this ability?) , so this problem emerges.
Try moving optimizer state to the GPU memory manually after loading it from the checkpoint. I agree that having an method for this operation would be nice.
thanks. My work was suspended due to other problems, when resumed, I will try your method.
I'm afraid solution won't work. It will make the error go away, but your optimizer will no longer be training the model. You should recreate optimizers after casting modules to a different type or device, and you can use to restore the state from a previous copy. This currently doesn't work, but we should fix it (by copying from the data from the state dict, instead of using the tensors directly - this allows for cross-device or cross-type updates).
, yep, your method is what I currently use, it works. But I will wait for upstream to fix this problem though. Thanks for your great works!
Ah, my bad. I forgot to update the line where the optimizer is recreated. But otherwise, the following should do the job, right?
ah, right. That should work
Except that you should use instead of
I had a similar problem. When I save the optimizer state from a GPU other than GPU 0 and then load the state it still loads everything to GPU 0.

Specifying in didn't work either. 's solution solves this though.
Hi guys, I have a very similar problem as the one in this thread, here's my code: And then once I resume, I got KeyErrors on my optimizer: Do you guys know how to fix this issue? BTW, I have 8 GPUs used, I'm guessing if this issue was because of that?
were you able to solve your issue with multiple-GPUs?
Thanks for asking. Yeah, I'm able to, turns out the issue is because I used an early version of PyTorch, after I updated the version, it works like a charm!
Just a comment, this problem is caused by makes all state tensor are moved into GPU0 so by moving the state of an optimizer to specific GPU will fix this problem.
Hi how do you know the specific GPU location of different tensors in advance?
Would a feature where all () calls always makes use of an automatically generated CPU version be feasible ? And then at resume the () would make use of the "current" device being used (or any better strategy). At the moment it seems we need a lot of boilerplater code to ensure saving and loading are consistents across devices for models/optimizer/scheduler/etc.
I have met similar problem, I recreated Adam optimizer without () after reloading model, () and DataParallel(model) according to solution.
thanks, it work!
Hi, as you say that: every time moving model to other device, we should build optimizer, but, if we move the model to other device and move back, should we build the optimizer again? here is an example code: does optimizer run as expected? also, if doing , should we rebuild optimizer ?
Is there a problem if you switch the order to something like this? Meaning moving the model to 'cuda' but only loading it's state dict from checkpoint after loading the optimizer's state dict first?
The problem can be concluded that the optimizer's state will be loaded to the device as same as the model. You must load the model to GPU at first, and then load the optimizer's state. So that both the model and the optimizer's state are loaded in GPU.

Instead of moving optimizer to cuda after loading it in cpu, you could load the checkpoint directly in cuda:
I've independently rediscovered that this works :) Should read until the end of the thread next time
I find my codes still have the problem. I tried my best to range the modules as the examples shown in the above. can anyone give me some hints? I also tried this
For me, doesn't solve the issue, but the one by works. Any idea why? I create the optimizer, load the state (with map location to CUDA), pass to the train loop, where the mode is pushed to device (though I assume it's not needed if the loaded model is pushed to cuda by maplocation). Specifically, I would get stuck at call, throwing the device mismatch error.
Still it doesn't work for me. Could you please help me?


Question: pytorch-linux-trusty-py3.6-gcc5.4-test pytorch-linux-trusty-py3.6-gcc7.2-build pytorch-linux-trusty-py3.6-gcc7.2-test <ins> pytorch-linux-trusty-py3.6-gcc7-build pytorch-linux-trusty-py3.6-gcc7-test </ins> pytorch-linux-trusty-pynightly-build pytorch-linux-trusty-pynightly-test pytorch-win-ws2016-cuda9-cudnn7-py3-build

We're not testing against CUDA 9.2 and we should. C.f. We should test against GCC 7 (because this is how Anaconda is building the packages), AND we should use test with this in OS X, because CUDA 9.2 now supports the default xcode shipped on OS X.
Building PyTorch with CUDA 9.2 for 7.0 compute compatibility devices produces quite worrisome warnings: warning : Instruction 'vote' without '.sync' may produce unpredictable results on sm70 and later architectures warning : Instruction 'vote' without '.sync' is deprecated since PTX ISA version 6.0 and will be discontinued in a future PTX ISA version warning : Instruction 'shfl' without '.sync' is deprecated since PTX ISA version 6.0 and will be discontinued in a future PTX ISA version warning : Instruction 'shfl' without '.sync' may produce unpredictable results on sm70 and later architectures
CUDA 9.2 CI on macOS is done in


Question: .. automethod:: rsqrt .. automethod:: rsqrt_ .. automethod:: scatter_ <ins> .. automethod:: scatter_add_ </ins> .. automethod:: select .. automethod:: set_ .. automethod:: share_memory_

is not available in the docs page, but the doc string has been in . This was mentioned earlier in

Oh, bilinear, I missed that last time I looked at it. I'll add a docstring.

returns nothing. Might be useful to have some linter in the build process to find Python functions missing

Pytorch 0.4.0 gives a segmentation fault with dilated 2D convolutions over a specific size. import torch import as nn model = nn.Conv2d(inchannels=64, outchannels=64, kernelsize=5, dilation=2) model(([1, 64, 1166, 1166])) # This runs model(([1, 64, 1167, 1167])) # This crashes PyTorch version: 0.4.0 Is debug build: No CUDA used to build PyTorch: 9.1.85 OS: CentOS Linux 7 (Core) GCC version: (GCC) 4.8.5 (Red Hat 4.8.5-28) CMake version: version 2.8.12.2 Python version: 3.6 Is CUDA available: Yes CUDA runtime version: 8.0.61 GPU models and configuration: GPU 0: GeForce GTX 1080 Ti GPU 1: TITAN X (Pascal) GPU 2: Quadro K2200 Nvidia driver version: 390.59 cuDNN version: Probably one of the following: /usr/local/cuda- /usr/local/cuda- /usr/local/cuda-7.5/lib64/libcudnnstatic.a /usr/local/cuda- /usr/local/cuda-8.0/lib64/libcudnn_static.a
do you think this is the same as the segfault you showed me a week ago on convolution?
ah yes. int overflow. I only fixed conv3d because I didn’t want to hurt perf. I’ll fix all of them.

This should be an easy one.. The function is implemented, just no sign of it in the docs.


Question: if config.triton.autotune_at_compile_time: self.kernel_autotune_calls.writeline(line) if zero_fill: <del> # TODO: remove this function to use the default WrapperCodegen behavior after service platform has zero_() symbol # default behavior is f"workspace.zero_(){self.ending}" self.writeline( f"AOTI_TORCH_ERROR_CODE_CHECK(aoti_torch_zero_(workspace.get())){self.ending}" ) </del> <ins> if isinstance(nbytes, sympy.Expr): self.writeline(f"workspace.zero_(){self.ending}") else: # TODO: remove this function to use the default WrapperCodegen behavior after service platform has zero_() symbol # default behavior is f"workspace.zero_(){self.ending}" self.writeline( f"AOTI_TORCH_ERROR_CODE_CHECK(aoti_torch_zero_(workspace.get())){self.ending}" ) </ins> if config.triton.autotune_at_compile_time: self.kernel_autotune_calls.writeline(f"workspace.zero_(){self.ending}")

Repro: Error: cc
Un-assign myself to let work on it.
, I can't reproduce the issue. The is no longer in the codebase. I gave a try of , which worked well. Could you double check if you can reproduce the issue?
Yes, I can still reproduce with your cmdline. Can you retry after deleting your local cache?


Question: INCLUDE(CheckCXXSourceCompiles) <ins> # disable some verbose warnings IF (MSVC) set(CMAKE_CXX_FLAGS "/wd4267 /wd4251 /wd4522 /wd4522 /wd4838 /wd4305 /wd4244 /wd4190 /wd4101 /wd4996 /wd4275 ${CMAKE_CXX_FLAGS}") ENDIF(MSVC) </ins> # windef.h will define max/min macros if NOMINMAX is not defined IF(MSVC) add_definitions(/DNOMINMAX)

That's pretty big! In contrast, an OS X build log is only 1.3M. Is there a reason they have to be this big? CC
My guess is that it's because of warnings. I remember having to get through thousands of them when looking for the error that failed the build.
Yes, the major part of them are warnings. And some of them is not fixable. We can hide them using some flags on the compilers.
And this build configuration actually contains both the CPU and GPU build, which may also be a possible reason.
The reduced log size after PR is about 1.2M.


Question: END_HANDLE_TH_ERRORS } <ins> PyObject * THCPModule_getDeviceCapability_wrap(PyObject *self, PyObject *arg) { HANDLE_TH_ERRORS THPUtils_assert(THPUtils_checkLong(arg), "invalid argument to getDeviceCapability"); long device = THPUtils_unpackLong(arg); cudaDeviceProp prop; THCudaCheck(cudaGetDeviceProperties(&prop, device)); return Py_BuildValue("(ii)", prop.major, prop.minor); END_HANDLE_TH_ERRORS } </ins> PyObject * THCPModule_getCurrentStream_wrap(PyObject *self) { HANDLE_TH_ERRORS

There's quite a few user-reports of installing the CUDA 7.5 binary of pytorch and then running on GTX 1080 / 1070, and there will be reports of installing 7.5 / 8.0 binaries and running on V100. Raising a user-warning in such situations and letting them know will fix the problem.
The version of CUDA used to compile the binary should be available thanks to this PR:
I think is a more robust way of getting the CUDA used to compile PyTorch, as currently if there are multiple CUDA installed in the machine, the heuristics used in might not match those used by CMake FindCUDA. I think that we should modify the to return the cuda version used during compilation. I have the impression that it will not require changing much because doesn't require cuda to execute. What do you think?


Question: Other Operations ~~~~~~~~~~~~~~~~~~~~~~ <ins> .. autofunction:: bincount </ins> .. autofunction:: cross .. autofunction:: diag .. autofunction:: diagflat

is not available in the docs page, but the doc string has been in . This was mentioned earlier in

Oh, bilinear, I missed that last time I looked at it. I'll add a docstring.

returns nothing. Might be useful to have some linter in the build process to find Python functions missing

Pytorch 0.4.0 gives a segmentation fault with dilated 2D convolutions over a specific size. import torch import as nn model = nn.Conv2d(inchannels=64, outchannels=64, kernelsize=5, dilation=2) model(([1, 64, 1166, 1166])) # This runs model(([1, 64, 1167, 1167])) # This crashes PyTorch version: 0.4.0 Is debug build: No CUDA used to build PyTorch: 9.1.85 OS: CentOS Linux 7 (Core) GCC version: (GCC) 4.8.5 (Red Hat 4.8.5-28) CMake version: version 2.8.12.2 Python version: 3.6 Is CUDA available: Yes CUDA runtime version: 8.0.61 GPU models and configuration: GPU 0: GeForce GTX 1080 Ti GPU 1: TITAN X (Pascal) GPU 2: Quadro K2200 Nvidia driver version: 390.59 cuDNN version: Probably one of the following: /usr/local/cuda- /usr/local/cuda- /usr/local/cuda-7.5/lib64/libcudnnstatic.a /usr/local/cuda- /usr/local/cuda-8.0/lib64/libcudnn_static.a
do you think this is the same as the segfault you showed me a week ago on convolution?
ah yes. int overflow. I only fixed conv3d because I didn’t want to hurt perf. I’ll fix all of them.

This should be an easy one.. The function is implemented, just no sign of it in the docs.


Question: ENDFUNCTION() ################################################################################ <ins> if(${CMAKE_VERSION} VERSION_LESS "2.8.12") set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11") else(${CMAKE_VERSION} VERSION_LESS "2.8.12") if(${CMAKE_VERSION} VERSION_LESS "3.1") add_compile_options(-std=c++11) # CMake 2.8.12 to 3.1 endif(${CMAKE_VERSION} VERSION_LESS "3.1") endif(${CMAKE_VERSION} VERSION_LESS "2.8.12") </ins> IF(NOT Torch_FOUND) FIND_PACKAGE(Torch REQUIRED)

Currently, CMake 3.0 or higher is required for THPP. This is annoying for building from source on Ubuntu 14.04 systems, as default CMake is 2.8, and updating it requires either compiling from source or adding some random repos:
it should work fine if you change it to 2.8. I'm testing this out in a sec, and will push it into master
Nope, it does not for me.


Question: import torch from functools import reduce from ._utils import _range <ins> from sys import float_info __MIN_LOG_SCALE = math.ceil(math.log(float_info.min * float_info.epsilon, 10)) </ins> class __PrinterOptions(object):

on print(torch.DoubleTensor(1)) I got ZeroDivisionError: float division by zero but torch.DoubleTensor(0)) or torch.DoubleTensor(2)) work just fine. I work in Jupyter notebook pytorch 0.1.12
Note that returns undefined memory. Could you find the specific content of the tensor that gave this error, by printing ? I'm not sure if this bug has been fixed in the latest release already.
the error is pretty interesting. I restarted Jupyter notebook. # many freaking signatures: print(torch.FloatTensor(1)) print(torch.IntTensor(1)) print(torch.DoubleTensor(1)) # no error right after initial run. #print(torch.DoubleTensor(0)) print(torch.DoubleTensor(2)) print(torch.ByteTensor(1)) print(torch.CharTensor(1)) print(torch.ShortTensor(1)) print(torch.LongTensor(1)) steps to reproduce the error: 1). run, no errors 2) repeat, no error 3) uncomment ..DoubleTensor(0), run, got an error (see below): 4) comment ..DouleTensor(0), run still have this error 2.+24 [torch.FloatTensor of size 1] 7.+08 [torch.IntTensor of size 1] ZeroDivisionError Traceback (most recent call last) <ipython-input-5-3629c250c505in <module() 2 print(torch.FloatTensor(1)) 3 print(torch.IntTensor(1)) ----4 print(torch.DoubleTensor(1)) # ZeroDivisionError: float division by zero 5 #print(torch.DoubleTensor(0)) 6 print(torch.DoubleTensor(2)) C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in str(self) 126 # characters to replace unicode characters with.

127 if sys.versioninfo (3,): --128 return (self) 129 else: 130 if hasattr(, 'encoding'): C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in str(self) 284 return '[{} with no dimension]n'.format(torch.typename(self)) 285 elif self.ndimension() == 1: --286 strt = vectorstr(self) 287 elif self.ndimension() == 2: 288 strt = matrixstr(self) C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in vectorstr(self) 270 if () < PRINTOPTS.threshold: 271 return (strt + --272 'n'.join(ident + (val / scale) for val in self) + 273 'n') 274 else: C:UsersleogAppDataLocalcondacondaenvspy35libsite-packagestorch in <genexpr(.0) 270 if () < PRINT_OPTS.threshold: 271 return (strt + --272 'n'.join(ident + (val / scale) for val in self) + 273 'n') 274 else: ZeroDivisionError: float division by zero
Ok, I got a repro. Here is the failing case: Fails with the error you mentioned. This seems to be an edge case though, as both and works. The issue is in , where becomes zero because is a too large negative number. Maybe we should clip to be positive?


Question: std::vector<bool> *is_variable_input; char has_freed_buffers; <ins> // See a comment in THPFucntion_asFunction for details about this field. std::weak_ptr<torch::autograd::PyFunction> cdata_ptr; </ins> torch::autograd::PyFunction cdata; };

there is a bug. the code is from The code for installing cuda10.2 should be corrected to The code for installing cuda10.2 should be corrected to cc
Thank you for reporting the typo

This is how I implement the decoder of a sequence to sequence model I'm not sure about the new autograd mechanics but this worked in the previous version. If I didn't make the unrolling codes a function it will work. It will also work with CPU. I compiled from source with Python 2.7, CUDA 8.0 and Cudnn 6
Thanks for the minimal reproduction! It broke OpenNMT and a big internal model but we weren't looking forward to isolating what parts of those had the issue.
That's great, I'll take a look today. Thanks!
I've pushed a fix to .
How does the inference work in this case? I mean, once you train it how do you test it in the test phase?


Question: IF "%CMAKE_GENERATOR%"=="Ninja" ( IF "%CC%"== "" set CC=cl.exe IF "%CXX%"== "" set CXX=cl.exe <del> set MAKE_COMMAND=cmake --build . --target install --config Release -- -j%NUMBER_OF_PROCESSORS% || exit /b 1 </del> <ins> set MAKE_COMMAND=cmake --build . --target install --config %BUILD_TYPE% -- -j%NUMBER_OF_PROCESSORS% || exit /b 1 </ins> ) ELSE ( <del> set MAKE_COMMAND=msbuild INSTALL.vcxproj /p:Configuration=Release </del> <ins> set MAKE_COMMAND=msbuild INSTALL.vcxproj /p:Configuration=%BUILD_TYPE% </ins> ) )

The current master triggers the following error messages from Visual Studio 2015 (Debug build): 2------ Build started: Project: ATen, Configuration: Debug x64 ------ 2cl : Command line error D8016: '/Ox' and '/RTC1' command-line options are incompatible ... 14LINK : fatal error LNK1104: cannot open file '....srcATenDebug' It appears that they are triggered by *.c files in the ATen project, like "srcTHvectorAVX.c"
Why do you need Debug build?
Isn't ATen meant to support both Debug and Release builds? FYI I'm involved with the project at which does support both build configurations, and we would like to be able to link our project with ATen.
Well, you can remove the flags in as a workground.
We should patch this file to ignore this flag when building the library in debug mode. It shouldn't be too hard
I catched similar errors , when I Tryed to build Debug Version I try to build Release and catched next errors e:pytorchatensrcatencpuvec256vec256int.h(184): note: see reference to function template instantiation 'at::vec256::anonymous-namespace'::Vec256<int16t::blend<1(at::vec256::anonymous-namespace'::Vec256<int16t)' being compiled 28e:pytorchatensrcatencpuvec256vec256int.h(147): error C3861: 'mm256extract_epi16': identifier not found What I should do?
There're two issues in your description. The first question is easy. You'll also have to specify the flag to 1. The second question is about your compiler. I guess you are using VS2015 or earlier versions of VS2017. Make sure the version in the output is 19.11 after your enter in CMD.
Yes I am using VS2015. My Compiler is 19.0.2. Must I use VS 2017 in any case?
Sorry, but the answer is yes. The AVX2 functions was in VS2017 and they are used in PyTorch. So VS2017 19.11 is a must.
No problem:) Thank you.


Question: libs = ['TH', 'THS', 'THNN'] if WITH_CUDA: libs += ['THC', 'THCS', 'THCUNN'] <del> if WITH_NCCL and not SYSTEM_NCCL: </del> <ins> if WITH_NCCL and not WITH_SYSTEM_NCCL: </ins> libs += ['nccl'] libs += ['THPP', 'libshm', 'ATen', 'nanopb'] if WITH_DISTRIBUTED:

Currently, you can have a libnccl on your system, and pytorch setup favors that instead of compiling one itself from source. The code that takes care of this is: However, this breaks gloo build because gloo gets a path to NCCL via:
I got the error during the installation: Is it related to this problem?
that's a dupe of
no, that's a consequence of , now you have to do before compiling. I think you don't want to do recursive submodule update, because that will pull in gtest and another copy of nccl.
Alternatively we can pass new flags to gloo to prevent it from using its own NCCL
Thanks works for me.
You can prevent it from using its own nccl, but its cmake still has to be able to find some nccl.
I think should be sufficient. I'm testing.
fixes it when we dont have an external NCCL and pytorch compiles it's own NCCL?
I don't see how NCCLEXTERNAL fixes anything, looks like in gloo NCCLEXTERNAL is used just to set dependency if gloo is compiling its own nccl (which we don't want in any case).
The only thing I tested when I was that the vendored nccl was not being built (even if its submodule was checked out); I tested this by adding an to one of the headers. I'll test with the other configurations.
Actually, there are a few bugs here. First, even though GLOOFLAGS looks like it's setting NCCLROOTDIR: it actually isn't because the gloo invocation is which expands to but only is passed to cmake. Suppose you fix this. nccl is still not going to be picked up, because INSTALLDIR is PyTorch's local install dir, but if you disabled nccl builds, there will never actually be a nccl here. So cmake is just going to do it's standard search to find a nccl somewhere. Inversely, if you ever built nccl, and then turn it off, we will keep picking up that locally built version until you delete it. So we shouldn't do that. Suppose you fix this.

Then I think gloo will (continue to) correctly pick up system nccl and be built with it, and the final thing to fix is that build of PyTorch csrc doesn't know how to search for nccl headers somewhere. This is probably related to . I wonder, maybe we shouldn't do any autodetection at all, and force the user to pass us the include and library paths of nccl if they want to build with system.
FYI, I committed a change to gloo to stop bundling NCCL itself. It will now happily pick up whatever NCCL you give it through NCCLROOTDIR or by trying to find it in the standard systems paths. See facebookincubator/gloo You do have to set to make Gloo try and find it and compile in support.
So to fix this, you should be able to not specify anything aside from if you want to use system NCCL, and add if you have some custom location (either a PyTorch bundled version or a custom install altogether).


Question: static void setattr(jit::Node* n, jit::Symbol name, const at::IntList& v)  { n->is_(name, v); } static void setattr(jit::Node* n, jit::Symbol name, bool v)                { n->i_(name, v); } static void setattr(jit::Node* n, jit::Symbol name, double v)              { n->f_(name, v); } <del> template<unsigned long N> </del> <ins> template<std::size_t N> </ins> static void setattr(jit::Node* n, jit::Symbol name, std::array<bool, N> v) { n->is_(name, std::vector<int64_t>(v.begin(), v.end())); } VariableType::VariableType(Context* context, Type* baseType)

Hello, I'm trying to build pytorch (I tried both v3_buildfix and master branch) on a raspberry pi 3 but i'm getting that error: Note: I'm building without CUDA and DISTRIBUTED support. OS: Ubuntu 16.04 (Mate) gcc: arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.5) 5.4.0 cmake: v3.5.1
Can you try building with and let me know if that fixes it?
Thanks, it compiles now ;)


Question: last_epoch (int): The index of last epoch. Default: -1. Example: <del> >>> # Assuming optimizer uses lr = 0.5 for all groups </del> <ins> >>> # Assuming optimizer uses lr = 0.05 for all groups </ins> >>> # lr = 0.05     if epoch < 30 >>> # lr = 0.005    if 30 <= epoch < 80 >>> # lr = 0.0005   if epoch >= 80

Hi, In the is written: "lr values are [0.05, 0.005, ...]." If I understand it correctly, it should be [0.5, 0.05, 0.005, ...].
That is correct. Please feel free to send a PR to fix it! (otherwise, I can)
If you don't mind to change it yourself, I'm not contributor yet and don't want to start just for one comment. I guess is the same case.


Question: "test_mm_plus_mm2_cuda_dynamic_shapes": test_torchinductor.TestFailure( ("cuda_wrapper",), is_skip=True ), <del> "test_consecutive_split_cumprod_cuda_dynamic_shapes": test_torchinductor.TestFailure( ("cuda_wrapper",), is_skip=True ), </del> }

Repro: Error: cc
Un-assign myself to let work on it.
, I can't reproduce the issue. The is no longer in the codebase. I gave a try of , which worked well. Could you double check if you can reproduce the issue?
Yes, I can still reproduce with your cmdline. Can you retry after deleting your local cache?


Question: <del> from collections import defaultdict </del> <ins> from collections import defaultdict, Iterable </ins> import torch from copy import deepcopy

Hi, I encountered this bug: The code skeleton is like: It seems the loaded are , and I've tried a workaround to move to , but it still has the same bug.
Could you provide a full script to reproduce the problem?
maybe you can try like this, () (beta1).add_(1 - beta1, ())
Sorry, I missed the reply email. I am afraid that I am unable to provide a reproducer now. It is a work I am doing for the OpenNMT-py , trying to use for doing lr update. And I encoutered this problem when testing the case. So I factored out the code skeleton about this problem above. I've tried several methods, including tricks like what suggests, but it still happens. Per my analysis, it is because the previous training was done on gpu, so when saving the , the stored states(tensors) are of version. During resuming, when we load the saved optimizer, loads this version to cpu(the model() can be moved to gpu easily, but seems lacking this ability?) , so this problem emerges.
Try moving optimizer state to the GPU memory manually after loading it from the checkpoint. I agree that having an method for this operation would be nice.
thanks. My work was suspended due to other problems, when resumed, I will try your method.
I'm afraid solution won't work. It will make the error go away, but your optimizer will no longer be training the model. You should recreate optimizers after casting modules to a different type or device, and you can use to restore the state from a previous copy. This currently doesn't work, but we should fix it (by copying from the data from the state dict, instead of using the tensors directly - this allows for cross-device or cross-type updates).
, yep, your method is what I currently use, it works. But I will wait for upstream to fix this problem though. Thanks for your great works!
Ah, my bad. I forgot to update the line where the optimizer is recreated. But otherwise, the following should do the job, right?
ah, right. That should work
Except that you should use instead of
I had a similar problem. When I save the optimizer state from a GPU other than GPU 0 and then load the state it still loads everything to GPU 0.

Specifying in didn't work either. 's solution solves this though.
Hi guys, I have a very similar problem as the one in this thread, here's my code: And then once I resume, I got KeyErrors on my optimizer: Do you guys know how to fix this issue? BTW, I have 8 GPUs used, I'm guessing if this issue was because of that?
were you able to solve your issue with multiple-GPUs?
Thanks for asking. Yeah, I'm able to, turns out the issue is because I used an early version of PyTorch, after I updated the version, it works like a charm!
Just a comment, this problem is caused by makes all state tensor are moved into GPU0 so by moving the state of an optimizer to specific GPU will fix this problem.
Hi how do you know the specific GPU location of different tensors in advance?
Would a feature where all () calls always makes use of an automatically generated CPU version be feasible ? And then at resume the () would make use of the "current" device being used (or any better strategy). At the moment it seems we need a lot of boilerplater code to ensure saving and loading are consistents across devices for models/optimizer/scheduler/etc.
I have met similar problem, I recreated Adam optimizer without () after reloading model, () and DataParallel(model) according to solution.
thanks, it work!
Hi, as you say that: every time moving model to other device, we should build optimizer, but, if we move the model to other device and move back, should we build the optimizer again? here is an example code: does optimizer run as expected? also, if doing , should we rebuild optimizer ?
Is there a problem if you switch the order to something like this? Meaning moving the model to 'cuda' but only loading it's state dict from checkpoint after loading the optimizer's state dict first?
The problem can be concluded that the optimizer's state will be loaded to the device as same as the model. You must load the model to GPU at first, and then load the optimizer's state. So that both the model and the optimizer's state are loaded in GPU.

Instead of moving optimizer to cuda after loading it in cpu, you could load the checkpoint directly in cuda:
I've independently rediscovered that this works :) Should read until the end of the thread next time
I find my codes still have the problem. I tried my best to range the modules as the examples shown in the above. can anyone give me some hints? I also tried this
For me, doesn't solve the issue, but the one by works. Any idea why? I create the optimizer, load the state (with map location to CUDA), pass to the train loop, where the mode is pushed to device (though I assume it's not needed if the loaded model is pushed to cuda by maplocation). Specifically, I would get stuck at call, throwing the device mismatch error.
Still it doesn't work for me. Could you please help me?


Question: throw std::runtime_error(ss.str()); } <ins> static void checkIndexTensorTypes(TensorList indices) { for (auto& tensor : indices) { if (tensor.defined()) { auto& type = tensor.type(); auto scalarType = type.scalarType(); if (scalarType != kLong && scalarType != kByte) { throw std::runtime_error("tensors used as indices must be long or byte tensors"); } } } } </ins> static std::vector<Tensor> expandByteTensors(const Tensor & self, TensorList indices) { // Expands byte tensors (masks) into the equivalent indexing by LongTensors std::vector<Tensor> result;

In PyTorch master 0.4 , variables cannot be indexed. This used to work in PyTorch 0.2 :
This is breaking some of Pyro's inference algorithms on PyTorch master:


Question: <ins> From PyTorch: Copyright (c) 2016-     Facebook, Inc            (Adam Paszke) Copyright (c) 2014-     Facebook, Inc            (Soumith Chintala) Copyright (c) 2011-2014 Idiap Research Institute (Ronan Collobert) Copyright (c) 2012-2014 Deepmind Technologies    (Koray Kavukcuoglu) Copyright (c) 2011-2012 NEC Laboratories America (Koray Kavukcuoglu) Copyright (c) 2011-2013 NYU                      (Clement Farabet) Copyright (c) 2006-2010 NEC Laboratories America (Ronan Collobert, Leon Bottou, Iain Melvin, Jason Weston) Copyright (c) 2006      Idiap Research Institute (Samy Bengio) Copyright (c) 2001-2004 Idiap Research Institute (Ronan Collobert, Samy Bengio, Johnny Mariethoz) From Caffe2: Copyright (c) 2016-present, Facebook Inc. All rights reserved. All contributions by Facebook: Copyright (c) 2016 Facebook Inc. All contributions by Google: Copyright (c) 2015 Google Inc. All rights reserved. All contributions by Yangqing Jia: Copyright (c) 2015 Yangqing Jia All rights reserved. All contributions from Caffe: Copyright(c) 2013, 2014, 2015, the respective contributors All rights reserved. All other contributions: Copyright(c) 2015, 2016 the respective contributors All rights reserved. Caffe2 uses a copyright model similar to Caffe: each contributor holds copyright over their contributions to Caffe2. The project versioning records all such contribution and copyright details. If a contributor wants to further mark their specific copyright on a particular contribution, they should indicate their copyright solely in the commit message of the change when it is committed. </ins> All rights reserved. Redistribution and use in source and binary forms, with or without

The three-clause BSD license in file LICENSE says in clause 1 "Redistributions of source code must retain the above copyright notice..." However, there is no longer a copyright notice in the file; it appears to have been removed in commit (see ).
cc


Question: # Target only our CI GPU machine's CUDA arch to speed up the build export TORCH_CUDA_ARCH_LIST=5.2 <ins> if [[ "$BUILD_ENVIRONMENT" == *trusty-py3.6-gcc5.4* ]]; then export DEBUG=1 fi </ins> WERROR=1 python setup.py install # Add the test binaries so that they won't be git clean'ed away

Turning on DEBUG=1 turns off inlining. However, if you declare a function as , it won't get object code generated for it, which means there will be undefined symbol errors. You might not notice this with a release build, since everything gets inlined away. We can catch errors like this by doing CI with DEBUG=1. Probably just pick one platform and run that only.


Question: } } <del> variable_list flatten(const TensorList& tensors) { </del> <ins> static variable_list flatten(const TensorList& tensors) { </ins> return cast_tensor_list(tensors); } <del> variable_list flatten(const Tensor& x, const TensorList& y) { </del> <ins> static variable_list flatten(const Tensor& x, const TensorList& y) { </ins> std::vector<Variable> r; r.reserve(1 + y.size()); r.emplace_back(x);

See Docker run fails with , which is due to the fact that is specified in docker container: Which results in: CI cc
Check that adding to manywheels image results in a failure:
Tentatively marking hi-pri since nightly testing are failing
This is resolved, here is the successful run:


Question: if (info != 0) THError("MAGMA orgqr : Argument %d : illegal value.", -info); <ins> THCTensor_(free)(state, a); </ins> THCTensor_(free)(state, work); magma_free_pinned(tau_data);

It seems like the function leaks memory. I'm using 0.2.0_4 on anaconda python 3.6 CUDA 8.0 using the standard conda installation. So the memory footprint increases up to 1.9G though each takes about 100M. compared to where it takes up more memory but doesn't leak memory and the memory foot print fluctuates between 414M and 432M and back to 414M. Aside from that, is there a reason for using Magma instead of cuBLAS?
Thanks for catching this! Looks like we're leaking : I think at the time we the Magma bindings cuBLAS didn't provide a QR solver. I'm not sure there's any reason to prefer it now.


Question: return value.reshape(required_shape).sum(-1) <del> def log_sum_exp(tensor, keepdim=True): </del> <ins> def _log_sum_exp(tensor, keepdim=True): </ins> r""" Numerically stable implementation for the `LogSumExp` operation. The summing is done along the last dimension.

Leaving this issue here for higher visibility. Originally reported by here: Also mentioned by Piggybacking off of this issue, has strange behavior (reported here: )
I have fixed this locally. Could I send a PR?
Yes, go ahead!


Question: l = torch.randn(15) source = TensorDataset(t, l) for i in range(15): <del> self.assertEqual(t[i:i + 1], source[i][0]) self.assertEqual(l[i:i + 1], source[i][1]) </del> <ins> self.assertEqual(t[i], source[i][0]) self.assertEqual(l[i], source[i][1]) </ins> class ErrorDataset(Dataset):

TensorDataset adds casts 1D target tensor to 2D which is not acceptable by NLL loss layer.
Fixed in .


Question: #include <cstdint> <del> namespace F = torch::nn::functional; </del> namespace torch { namespace nn {

As part of pull request , F is redefined globally in nn/modules/batchnorm.h F is then used once in batchnorm.h and again in instancenorm.h not a bug, but a problem for anyone using F in some other way. it's solvable, but I don't see this pattern anywhere else in libtorch, was wondering if this use is an anomaly, and if we could use thanks cc
Thanks a lot for reporting! Yes this is an anomaly, and will be fixed by


Question: * Inception (warning: this model is highly sensitive to changes in operator implementation) * ResNet <del> * SqueezeNet </del> * SuperResolution * VGG * `word_language_model <https://github.com/pytorch/examples/tree/master/word_language_model>`_

Squeezenet is not exportable via onnx since it uses in which is not supported by ONNX. Please update documentation accordingly.


Question: return res def emit_record_trace(env, declaration): <ins> # Note [clang-802.0.42 tuple overload bug] # ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # Originally, my plan for emit_$ecord_trace was to keep it as # simple as possible, if at the expense of some somewhat ugly # overloads.  So this meant we had a 'recordTrace' function # with overloads like this: # #   recordTrace(..., const Variable& out) #   recordTrace(..., const std::tuple<Variable, Variable>& out) # # Unfortunately, this triggers a bug in clang-802.0.42 # (widely used in macOS Sierra 10.12.6) wherein a Variable is # implicitly convertible into a std::tuple<Variable, Variable>; # a minimal repro can be seen below here: # #   #include <tuple> #   struct T {}; #   void f(const std::tuple<T, T>&) {} #   void g(T& x) { f(x); } # # To work around this bug, the code generator is a bit more # complicated, and is taught how to handle this situation. </ins> local = {} <ins> arguments = declaration['arguments'] tensor_args = [arg for arg in arguments if arg['simple_type'] in {'Tensor', 'TensorList'}] if len(tensor_args) == 1 and tensor_args[0]['simple_type'] == 'TensorList': # Special case for TensorList.  This only works when there # is a single argument local['trace_inputs'] = "cast_tensor_list({})".format(declaration['arguments'][0]['name']) else: local['trace_inputs'] = CodeTemplate("{ ${tensor_args} }").substitute(env) </ins> local['record_attributes'] = [] for arg in declaration['arguments']: if arg['simple_type'] in {'Tensor', 'TensorList'}:

when executing:
I'm seeing this as well as of last night. Its preceded by many warnings about : But the first error is the one about . I went back, and I get a good install as late as commit


Question: v = self.ValueTensor([5]).cuda(0) self.assertRaises(RuntimeError, lambda: self.SparseTensor(i, v, torch.Size([3]))) <ins> def _test_new_device(self, size, device): with torch.cuda.device(device): x = torch.cuda.sparse.DoubleTensor(*size) self.assertEqual(x.get_device(), device) x1 = x.new() x2 = x.new(2, 3) self.assertEqual(x1.get_device(), device) self.assertEqual(x2.get_device(), device) </ins> @cuda_only <del> @unittest.skipIf(torch.cuda.device_count() < 2, "only one GPU detected") def test_new_device(self): with torch.cuda.device(1): x = torch.cuda.sparse.DoubleTensor(30, 2) self.assertEqual(x.get_device(), 1) </del> <ins> def test_new_device_single_gpu(self): self._test_new_device((), 0) self._test_new_device((30, 20), 0) self._test_new_device((30, 20, 10), 0) </ins> <del> y = x.new(2, 3) self.assertEqual(y.get_device(), 1) </del> <ins> @cuda_only @unittest.skipIf(torch.cuda.device_count() < 2, "only one GPU detected") def test_new_device_multi_gpu(self): self._test_new_device((), 1) self._test_new_device((30, 20), 1) self._test_new_device((30, 20, 10), 1) </ins> class TestUncoalescedSparse(TestSparse):

This causes to not work properly on newly created empty sparse tensors. In the example below, both should print 1 instead.


Question: if bias is not None: self.bias.data.uniform_(-0.1, 0.1) <del> def forward(self, input): # See the autograd section for explanation of what happens here. return Linear()(input, self.weight, self.bias) </del> <ins> def forward(self, input): # See the autograd section for explanation of what happens here. return Linear()(input, self.weight, self.bias) </ins> Writing custom C extensions

Broken download links for libtorch v1.8.0 with CUDA 10.2 for Linux (pre-cxx11 and cxx11 ABI) and Windows (Release and Debug versions) on the PyTorch website. Steps to reproduce the behavior: on any of the following links leads to an "Access Denied" error: The chosen libtorch version is downloaded. PyTorch Version: .1.8.0 OS: Linux and Windows CUDA version: 10.2
The correct links are listed below. cc
Thanks!
Same issue also happens for CUDA 11.1 when trying to download windows precompiled binaries Changing to in the links suggested by still leads to Access Denied page
Okay I wrote a simple script to test if all of our libtorch packages are actually downloadable, sharing results here: <details<summarypkgs </summaryCommand I used to generate these (from the root of ): </detailsOutput being: I did find that this issue is correct in that the installation instructions were incorrect for CUDA 10.2 and I created a PR to resolve this:


Question: } private: <del> friend class VariableVersion; </del> <ins> friend struct VariableVersion; </ins> int expected_version; std::shared_ptr<VersionBlock> version_block;  // may be null };

when executing:
I'm seeing this as well as of last night. Its preceded by many warnings about : But the first error is the one about . I went back, and I get a good install as late as commit


Question: - [NVIDIA CUDA](https://developer.nvidia.com/cuda-downloads) 7.5 or above - [NVIDIA CuDNN](https://developer.nvidia.com/cudnn) v5.x <ins> If you want to disable CUDA support, export environment variable `NO_CUDA=1`. </ins> #### Install optional dependencies On Linux

Caffe and TensorFlow supports both CPUONLY and CUDA mode. The meaning of CPUONLY mode is to enable users to run pytorch on architectures except for AMD64 and PPC64EL (Seems that CUDA is only available on AMD64 and PPC64EL). For example, the CPU_ONLY version of is available for (not only) amd64, armel, i386, ppc64el and s390x, while the CUDA version only supports amd64 and ppc64el.
I think we don't plan to invest too much time in supporting many different architectures. The vast majority of the users is on x86 and this will remain our main focus. If someone is willing to spend their time supporting other archs, we'll happily accept PRs, but we have a lot of other priorities. We also support CPU only and CUDA mode. You can use or build pytorch without any GPU. We also have CPU-only binaries (see the website). You can force building without CUDA with env variable, as I pointed out in another PR (it's broken because of THPP at the moment, but I'll fix it soon). The only limitation for supporting different archs that I see is what our backends are limited to, and the fact that you need a C++11 compiler to build the extension. Apart from this, I don't think we depend on x86 anywhere. Can you please elaborate on what kind of guidance would you like to see? More detailed instructions on how to build pytorch somewhere in the docs?
As reported in [1], Pytorch's backend library (libTH) is now healthy in portability. I suggest that the environment variable should be referred in . [1]

I'm trying to implement distributed adversarial training in PyTorch. Thus, in my program pipeline I need to forward the output of one DDP model to another one. When I run the code in distributed setting, the following error is throwed: frame : c10::Error::Error(c10::SourceLocation, std::string const&) + 0x45 (0x7fa248f906d5 in /export/home/haoran/anaconda3/envs/torch1.2/lib/python3.6/site-) frame : c10d::Reducer::prepareforbackward(std::vector<torch::autograd::Variable, std::allocator<torch::autograd::Variableconst&) + 0x666 (0x7fa26f9d0896 in /export/home/haoran/anaconda3/envs/torch1.2/lib/python3.6/site-) frame : <unknown function+ 0x6df3b8 (0x7fa26f9c43b8 in /export/home/haoran/anaconda3/envs/torch1.2/lib/python3.6/site-) frame : <unknown function+ 0x1fc7f0 (0x7fa26f4e17f0 in /export/home/haoran/anaconda3/envs/torch1.2/lib/python3.6/site-) frame : main + 0x16d (0x400c1d in /export/home/haoran/anaconda3/envs/torch1.2/bin/python) frame : _libcstartmain + 0xf5 (0x7fa285e06c05 in ) frame : /export/home/haoran/anaconda3/envs/torch1.2/bin/python() [0x4009e9] Running the following code with DistributedDataParallel <!-- If you have a code sample, error messages, stack traces, please provide it here as well --The code could run successfully without throwing error. Please copy and paste the output from our (or fill out the checklist below manually).

You can get the script and run it with: PyTorch version: 1.2.0.dev20190701 Is debug build: No CUDA used to build PyTorch: 9.0.176 OS: CentOS Linux 7 (Core) GCC version: (GCC) 5.4.0 CMake version: version 3.6.2 Python version: 3.6 Is CUDA available: Yes CUDA runtime version: 9.0.176 GPU models and configuration: GPU 0: Tesla P40 GPU 1: Tesla P40 GPU 2: Tesla P40 GPU 3: Tesla P40 Nvidia driver version: 390.25 cuDNN version: Could not collect Versions of relevant libraries: [pip] numpy==1.16.4 [pip] torch==1.2.0.dev20190701 [conda] blas 1.0 mkl defaults [conda] mkl 2019.4 243 defaults [conda] mklfft 1.0.12 py36ha843d7b0 defaults [conda] mklrandom 1.0.2 py36hd81dba30 defaults [conda] pytorch-nightly 1.2.0.dev20190701 py3.6cuda9.0.176cudnn7.5.1_0 pytorch <!-- Add any other context about the problem here. --
Please, try one of the suggested options: (1) passing the keyword argument findunusedparameters=True to ; (2) making sure all forward function outputs participate in calculating loss. If you already have done the above two steps, then the distributed data parallel module wasn't able to locate the output tensors in the return value of your module's forward function. Please include the loss function and the structure of the return value of forward of your module when reporting this issue (e.g. list, dict, iterable). If the issue will still exist, please, reopen this issue.
I double checked your repro to figure out if this is a real issue or not and found that even setting won't help you here. It's a simple example of course, but you're not using the variable in your loss computation. The model's forward function returns it which is an indication for DDP that it will receive a gradient.

Then when it doesn't, and you try to run the next iteration, it raises an error, because the previous iteration didn't finish. I recommend you return only the tensor you plan to use in the loss computation.
Is there any way to see which parameters on earth are unused? It is useless to simply give this RuntimeError or set findunusedparameters to True.
I had the same problem with just one GPUI have modified the code according to what you said
I met the same problem and I found this topic. It works for me. (though it's been a long time for you)


Question: BASE_DIR=$(pwd) cd torch/lib INSTALL_DIR="$(pwd)/tmp_install" <del> BASIC_C_FLAGS=" -DTH_INDEX_BASE=0 -I$INSTALL_DIR/include -I$INSTALL_DIR/include/TH -I$INSTALL_DIR/include/THC " </del> <ins> BASIC_C_FLAGS=" -DTH_INDEX_BASE=0 -DTH_GENERIC_USE_HALF=1 -DCUDA_HAS_FP16=1 -I$INSTALL_DIR/include -I$INSTALL_DIR/include/TH -I$INSTALL_DIR/include/THC " </ins> LDFLAGS="-L$INSTALL_DIR/lib " if [[ $(uname) == 'Darwin' ]]; then LDFLAGS="$LDFLAGS -Wl,-rpath,@loader_path"

Hi, I try to run the following example from here, but run into some issues: ld: warning: ignoring file , file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x8664): ld: warning: ignoring file , file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x8664): ld: warning: ignoring file , file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x03 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): full error log: i installed pytorch: im running pytorch on: osx 10.11.6 i installed libtorch following these steps: here the cmake output:
should i use: wget -c but the problem is that libtorch-macos- does not contain any libraries in ./lib folder. how to create it? instead of: wget -c when i use libtorch-macos-, i get this error:
I've got the same image not found example in this same spot, by following the minimal example of the docs. Running macOS Mojave here.
we need to build libtorch manually because it doesnt come with all libs...
Getting the same issue as with macOS High Sierra 10.13.5. When I look in I see but not as it requires.
cc: looks like a missing copying of in our OSX libtorch builds.
Seeing the same thing.
Fixed this issue by downloading the two missing libraries from and copying them both (, ) to .

Correct me if I am wrong, but that solution is not answering the original issue: I was having the same issue when trying to run the minimal cpp frontend example here: I grabbed libtorch linked on the main pytorch site: You are right, had neither nor in . However, copying those files to that location did not solve the issue for me. I was able to get the minimal example by giving cmake the for Pytorch's torch library (compiled from source): I am going to try compiling the DCGAN example for the cpp frontend in this same way. I assume that this is not going to work, that we will ultimately need to point to for something like data loading, etc. I am on Mac 10.14.3
I was facing almost same problems here and managed to fix it by downloading and from . Just in case anyone needs this, please do NOT download the newest post there! Instead find the file instead of file. ! I didn't find the difference between and at first, but succeeded once downloaded the ones.
Any idea whats going on with these missing MKL libraries for the mac c++ libtorch? Somehow this is still an issue dating back since 2018, and even after pytorch 1.3, I just tried it out again. The workaround done by above works for me, which involves manually copying the dylib files from old (pre v1.0) intel binaries.
I fixed all such issues for v1.3.0 in or so I thought. But I only fixed them for pip and conda packages, not libtorch. I'm looking into it right now and will fix libtorch too.
will kick off new binary builds as the fix went in. will close the issue after the builds are uploaded and live.
this is fixed now with fixed binaries that are re-uploaded.