Skip to content

test: size test_int64_upsample3d largeTensorTest guard to actual peak (64GB)#3457

Open
fjankovi wants to merge 1 commit into
release/2.10from
users/fjankovi/upsample3d-largetensor-64gb
Open

test: size test_int64_upsample3d largeTensorTest guard to actual peak (64GB)#3457
fjankovi wants to merge 1 commit into
release/2.10from
users/fjankovi/upsample3d-largetensor-64gb

Conversation

@fjankovi

Copy link
Copy Markdown

Problem

test_int64_upsample3d (test/test_torch.py) guards itself with @largeTensorTest('56GB'), but its true peak footprint is ~63.3 GiB: a 7.03 GiB bf16 input (1, 256, 16, 720, 1280) plus the 56.25 GiB scale_factor=2 nearest-mode output held at the same time.

largeTensorTest only skips when free VRAM at test start is below the stated size. So when free memory lands in the 56–63 GiB window, the gate admits the test and it then fails with HIP out of memory (56.25 GiB allocation). This is the intermittent gfx1151 failure tracked in ROCm/TheRock#6567:

  • py3.13 run happened to have < 56 GiB free → gate skipped it.
  • py3.12 / py3.14 runs had 56–63 GiB free → gate admitted it → OOM.

The "skip on py3.13" was never Python-version logic — just runtime memory luck.

Fix

Raise the guard to 64GB (ceil of the ~63.3 GiB real peak) so the memory check matches the actual footprint. The test is now deterministically skipped when the device cannot hold it, and only runs when it will actually fit — removing the OOM flake across all Python versions without special-casing any of them.

-    @largeTensorTest('56GB', device='cuda')
+    @largeTensorTest('64GB', device='cuda')

Notes

  • expectedFailure (upstream's MI200 approach for this test) is unsuitable here: the test genuinely passes when the card has enough free memory, so an xfail would flip to an erroring unexpected-pass on idle runners.

Refs: ROCm/TheRock#6567

… (64GB)

The test allocates a 7.03 GiB bf16 input plus a 56.25 GiB nearest
scale_factor=2 output simultaneously (~63.3 GiB peak), but guarded
itself with largeTensorTest(56GB). When free VRAM was in the 56-63 GiB
window the gate admitted the test and it OOMed. Raise the guard to 64GB
(ceil of the true peak) so the check matches the real footprint.

Refs: ROCm/TheRock#6567
@rocm-repo-management-api

rocm-repo-management-api Bot commented Jul 21, 2026

Copy link
Copy Markdown

Jenkins build for e666b775034d22beaf2fc58adcebe6a59fdbb537 commit finished as ABORTED
Links: Pipeline Overview / Build artifacts / Test Results

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant