Version compatability scheme for PyTorch and compiled Torch extensions

username: charliebudd
cooked: <p>I’m current experiencing inter-op issues for code compiled for torch 1.12.0 being called from python running torch 1.12.1 and vice-versa. What compatibility should I expect for code compiled for different patch versions of torch? Is this a bug introduced by 1.12.1 or is it a miracle it worked for the other minor versions of PyTorch so far?</p>

username: ptrblck
cooked: <p>PyTorch should be backwards compatible. I.e. a model written in <code>1.12.0</code> should work in <code>1.12.1</code>, but not necessarily vice versa.</p>

username: charliebudd
cooked: <p>Sorry, my original question was poorly worded. To clarify, the python compatibility is not my issue. I have a compiled c++ .so containing a torch extension. This was compiled with torch 1.12.0. My question is, should we expect this to be callable from python code working with torch 1.12.1 (and any subsequent patch versions of 1.12). This certainly works for patch versions of 1.10, and 1.11, and the symbol definitions have not changed between 1.12.0 and 1.12.1.</p>
<p>The error I get is when passing a jit model down to c++. Before 1.12.1, the _c attribute on a jit script model returned a torch.jit.ScriptModule which will cast to a torch::jit::Module when passed to a c++ function. However, in 1.12.1, the _c attribute returns a torch.ScriptModule which no longer casts in the same way causing an exception to be thrown.</p>

username: ptrblck
cooked: <aside class="quote no-group" data-username="charliebudd" data-post="3" data-topic="164637">
<div class="title">
<div class="quote-controls"></div>
<img loading="lazy" alt="" width="24" height="24" src="https://discuss.pytorch.org/letter_avatar_proxy/v4/letter/c/5e9695/48.png" class="avatar"> charliebudd:</div>
<blockquote>
<p>This was compiled with torch 1.12.0. My question is, should we expect this to be callable from python code working with torch 1.12.1 (and any subsequent patch versions of 1.12).</p>
</blockquote>
</aside>
<p>No, I would not expect this to work and would assume you need to rebuild all libs (e.g. <code>torchvision</code>) as well as extensions using the matching PyTorch version.</p>

username: charliebudd
cooked: <p>I’m not sure that this should be the intended behaviour, taken to its extreme where even basic functionality broke between patches, developers wishing to build CUDA extensions for distribution would need to build for every patch version. Multiply this by every python version, and multiply this by every CUDA version. You’re essentially limiting PyTorch extension code to be distributed as source to be compiled on the user’s machine, which also requires that they have the CUDA toolkit installed and that the CUDA toolkit version matches that which was used to build their version of torch. The build matrix is already pretty substantial just for covering recent minor versions of Pytorch.</p>

username: ptrblck
cooked: <p>Yes, you are right that the support matrix is large, but it’s also a balance to support users on older GPUs while also allowing the latest generation(s) to run. You are asking for an ability to e.g. mix and match <code>torch</code> and <code>torchvision</code> (or any other sub-library/extension) freely, which I’m sure won’t work in some cases and which is why the releases are aligned.<br>
However, if you are only concerned about patch releases (no major/minor releases) then I think your extension should just work since only critical bug fixes should land in patch releases.</p>

username: charliebudd
cooked: <p>Yes I think it’s reasonable to expect issues between major and minor versions. My build matrix accounts for all of these. My current issue is due to a patch difference though. Thanks for your help, I’ll make a git issue explaining the situation.</p>
<p>Git Issue: <a href="https://github.com/pytorch/pytorch/issues/88301" rel="noopener nofollow ugc">https://github.com/pytorch/pytorch/issues/88301</a></p>