Add non-TS'able _resize_image_and_masks variant with less tensor ops

[ezyang]

We did some horrible things to _resize_image_and_masks
to make it TorchScriptable, and those horrible things cause
weird divergences when you send the float computation
to a real compiler that is willing to do fastmath optimizations
to floating point, see pytorch/pytorch#93598

This PR adds a non TS-goopified version of the operator which doesn't
have this problem, since it does the size compute the "normal way"
(and consequently, doesn't get fastmath'ified).

Signed-off-by: Edward Z. Yang ezyang@meta.com

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/vision/7592

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure

As of commit d8043a9:

NEW FAILURE - The following job has failed:

• unittests-linux (3.8, linux.g5.4xlarge.nvidia.gpu, cuda, 11.7) / linux-job (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[NicolasHug]

Thanks for the PR @ezyang . I am growing wary of the maintenance cost we're facing with recent PRs related to PT 2.0 support (#7587, now this PR). Both PRs add a separate implementation for an existing function.

Do we expect to have a lot more of those PT 2.0 support issues in the future? And if yes, is there a alternate solution to what we're currently doing which is to duplicate all implementations?

Supporting the cross product of JIT x ONNX x all_platorms x <insert your preferred tech here> has been a massive challenge in torchvision (and I'm being diplomatic), and I fear that adding yet another factor to that is going to be... err... difficult.

[NicolasHug]

tests failing because this needs an import. But please use the RNG from torch instead of Python, so that users can fully control randomness by just calling torch.manual_seed() and similar mechanisms.

[ezyang]

PT 2.0 support (#7587)

I want to treat this and #7587 separately. #7587 has nothing to do with PT2 support per se, it's entirely around support for deterministic algorithms (which I ran into while working on PT2, sure, but it stands on its own.) On the subject of deterministic algorithms, there really are two main approaches for how you can add a deterministic version of a CUDA kernel that uses gpuAtomicAdd: (1) you can write a decomposition (which is what the PR does) or (2) you can write another copy of the CUDA kernel by hand that doesn't have atomic adds in it (the easiest approach is to change the iteration space from grad_output to grad_input, so that the summation happens from a single thread). Writing the decomposition has the added benefit that you can use it to compile things in PT2 (though I don't actually do this in the PR) and it can be a nice, pure-Python reference implementation that you can use for testing / experimentation. So it seems preferable over banging out another CUDA kernel. This seems... like a fair trade for "code duplication"? In the limit, we'd be applying this treatment to every custom operator in torchvision. A long term vision for PT2 is that you wouldn't need to write hand-written CUDA code at all; you could write the pure Python code and generate a kernel automatically from it, but we're still a little bit away from it.

Supporting the cross product of JIT x ONNX x all_platorms x has been a massive challenge in torchvision (and I'm being diplomatic), and I fear that adding yet another factor to that is going to be... err... difficult.

I think the question I would ask you is, if you didn't have to support TorchScript JIT / ONNX, what would this code look like? I argue that your code would look like the new version I've posted: why would you intentionally create a tensor just to do shape computation and convert it back out again? The version of the code here is the clear, idiomatic PyTorch eager implementation of the function.

[ezyang]

Attempted simplifying the duplication

[NicolasHug]

Thanks for trying to minimize the code duplication @ezyang . As discussed offline the ONNX tests are red, but I'll stamp to unblock.

[github-actions]

Hey @ezyang!

You merged this PR, but no labels were added. The list of valid labels is available at https://github.com/pytorch/vision/blob/main/.github/process_commit.py