Add antialias support to nn.Upsample for linear and cubic modes

[lyonsno]

Summary

Adds an antialias parameter to nn.Upsample, upsample_linear(), and
upsample_cubic() for the default align_corners=False interpolation path,
matching PyTorch's F.interpolate(antialias=True) on the tested bilinear and
bicubic cases.

When downsampling with antialias=True, the interpolation kernel widens
proportionally to the inverse scale factor, applying a low-pass filter that
prevents aliasing artifacts. For "cubic" mode, this also switches the
kernel coefficient from a=-0.75 (OpenCV) to a=-0.5 (PIL), matching
PyTorch's convention.

Motivation: PyTorch-origin vision model ports that use
F.interpolate(antialias=True) currently hit a parity gap. Representative
examples include DINOv2, MoGe, SDXL VAE, and many modern vision architectures.

Implementation

• Shared _aa_indices() function that takes a kernel callable and support
  radius, eliminating duplication between linear and cubic paths.
• Linear: triangle filter, support 1/scale in input pixels.
• Cubic: Keys cubic kernel with a=-0.5 (PIL convention).
• Out-of-bounds taps zeroed, weights renormalized per output pixel.
• Antialiased interpolation uses a separable mx.take path so very small
  downscales do not construct a cartesian product of per-axis taps. No
  C++/Metal changes.
• antialias=True with align_corners=True raises ValueError in both
  Upsample and the direct linear/cubic helpers; that coordinate convention is
  deliberately outside this patch's supported surface.
• antialias=True with "nearest" mode raises ValueError at init time.

Parity

Tested against PyTorch F.interpolate(antialias=True) for 2D bilinear and
bicubic align_corners=False paths at multiple integer-ratio scale factors and
input sizes:

Mode	Scale	Max abs diff vs PyTorch
bilinear	0.5x	< 2e-7
bilinear	0.25x	< 2.4e-7
bicubic	0.5x	< 2e-7
bicubic	0.25x	< 2.4e-7

Cubic upscale with antialias=True also matches PyTorch (the a=-0.5
coefficient applies to both up and downscale when antialias is enabled).

Tests

11 test methods, 162 subtests:

• test_torch_upsample_antialias: bilinear + bicubic at 0.5x/0.25x,
  sizes 4×4 to 64×64, square/non-square, asymmetric scales per dimension.
  All cross-validated against PyTorch.
• test_antialias_upscale_linear_is_noop: linear antialias has no
  effect when upscaling.
• test_antialias_upscale_cubic_matches_pytorch: cubic antialias
  matches PyTorch on upscale (a=-0.5 coefficient change).
• test_antialias_non_integer_scale_smoke: property tests for
  non-integer scales (shape, finite output; linear AA boundedness).
• test_antialias_1d_smoke: 1D spatial input smoke test (PyTorch
  doesn't support 1D antialias).
• test_antialias_uses_separable_path: verifies antialiased linear and
  cubic paths do not call the cartesian product interpolation path.
• test_antialias_align_corners_raises: ValueError at init for downscale
  and upscale.
• test_antialias_align_corners_direct_functions_raise:
  direct upsample_linear() and upsample_cubic() helpers reject the same
  unsupported contract for downscale and upscale.
• test_antialias_nearest_raises: ValueError at init.
• test_antialias_differs_from_non_antialias: AA output has lower
  variance than non-AA on random data.

Focused existing upsample coverage also passes: python/tests/test_nn.py -q -k upsample.

Limitations

• antialias=True with align_corners=True is not supported and raises
  ValueError. align_corners=False (the default) works correctly.
• The pure-Python antialias path is separable and avoids cartesian
  per-axis tap expansion, but very small downscales still require more
  per-axis taps than non-AA interpolation. A fused C++/Metal kernel could
  improve both AA and non-AA paths in future work.
• Non-integer scale ratios may show small divergence from PyTorch due to
  a pre-existing difference in _scaled_indices step computation.

[Pablosinyores]

I spent some time verifying this one against the pure-Python layer (built a small harness with the prebuilt wheel's core + this branch's upsample.py), and the antialias math checks out. A few things I confirmed independently:

• Kernels are correct. _triangle_kernel gives 1 / 0.5 / 0 at x = 0 / 0.5 / 1. _cubic_kernel (Keys, a=-0.5) gives 1 at x=0, 0 at x=1 and x=2, and 0.5625 at x=0.5 — matches the closed form ((a+2)x - (a+3))x² + 1 for a=-0.5. Switching the coefficient from -0.75 (OpenCV) to -0.5 (PIL) for the antialiased path is exactly what PyTorch does, and the comment update in _cubic_indices keeps the two paths self-documenting.

• The filter weights are right. For a 1-D linear downscale at scale=0.5, N=4, align_corners=False, an impulse test gave per-tap weights [0.4286, 0.4286, 0.1429] on x[0..2] for the first output pixel — which is what you get by hand from a triangle filter widened to support 1/scale = 2 and renormalized (0.75, 0.75, 0.25 / 1.75). So the support = kernel_radius / scale, zero-OOB, renormalize sequence is doing the right thing.

• Tap coverage is safe. num_taps = ceil(support) + 1 with the symmetric floor(center) + k range always spans every in-support integer tap; the extras fall outside the kernel and get exactly 0 weight, so nothing in-support is dropped.

• Multi-axis broadcasting is fine. I briefly worried expand_dims(w, -1) would misalign on the first axis of a 2-D resize, but _scaled_indices already reshapes indices to shape[dim] = -1, so the weight ends up (out_i, 1, 1) and broadcasts along the correct axis. A non-square 2-D downscale (1,8,6,2) -> (1,4,3,2) runs and produces the right shape.

Two small things worth considering, neither blocking:

1. Test coverage is square + integer-ratio only. All the test_torch_upsample_antialias cases use square inputs with equal per-axis scales, so the non-square path and per-axis-different scales aren't exercised against PyTorch even though they run. Since the note already flags non-integer scales as potentially divergent (#2186), it might be worth at least one non-square integer-ratio case (e.g. (8,4) -> (4,2)) to lock in the per-axis behavior.

2. antialias=True still routes upscale through the separable path. For scale >= 1 the triangle case reduces to plain linear (3 taps, the far one gets 0 weight), so it's correct, just slightly more work than the non-AA path. Not important, but if you wanted, antialias could no-op when every scale factor is >= 1.

Nice, clean addition overall — the separable rewrite and the OOB-zero-then-renormalize approach are the standard way to do this.

[lyonsno]

Thanks for the independent harness and the detailed check. The tap-coverage and per-axis broadcasting confirmations are especially helpful. I agree a non-square integer-ratio case is worth adding to lock down that path; I’ll add one. I’m inclined to leave the upscale antialias=True fast-path optimization out of this PR unless maintainers want it, since the current route preserves correctness and keeps the patch focused.

Appreciate you taking the time to verify it independently.