Remove the conv2d op-test case that can never be delegated, so the WebGPU op tests can run

[shoumikhin]

What is broken

The WebGPU op-test generator refuses to run:

RuntimeError: conv2d/gemm_batched produced NO VulkanBackend delegate (silent CPU fallback) - this case would not exercise the WebGPU path.

Why it happens

The op-test generator exports every case in
backends/webgpu/test/op_tests/cases.py and then checks that the exported
program really contains a WebGPU (Vulkan) delegate. If it does not, the case
would run on CPU and prove nothing, so the generator refuses to write it.

The gemm_batched case gives conv2d an input of shape (2, 8, 16, 16), so a
batch of 2. check_conv_node in backends/vulkan/op_registry.py returns False
for any 4-D convolution whose batch is not 1:

if len(x_shape) == 4:
    batches = x.meta["val"].size()[0]
    if batches != 1:
        return False

So this case can never be delegated. It has been in cases.py since the suite
was added and has never worked.

Why it only turns the job red now

This is an old failure that was being hidden, not a new one.

The generator has raised on this case since #21620 landed, which is the change
that added generate_op_tests.py to main. But the CI script wrapped the whole
stage in an if:

if $PYTHON_EXECUTABLE -m ...generate_op_tests --output "${OP_TEST_DIR}"; then
  ...
else
  echo "WARN: op-test manifest generation failed (needs the executorch wheel); skipping"
fi

So generation did run on every nightly, and it did fail on this exact case every
time. Run
31194597529,
from 2026-08-07, shows the whole sequence: the native tests pass, the generator
then runs for about 17 minutes, dies on
conv2d/gemm_batched produced NO VulkanBackend delegate, and the else branch
prints the WARN and the job goes green.

The part that had genuinely never run is the second half of the stage, the C++
op-test binary, because there was no manifest for it to load.

#21646 removed the if/else and left a plain call. The script runs under
set -e, so the same failure that had been warned about for weeks became fatal.

Making it fatal is the right call. The op tests are meant to run. This change
removes the one case that stops them.

The fix

Delete the gemm_batched case, and say in the suite comment why there is no
batched case, so it is clear what to add back once the partitioner accepts
batch > 1.

Why not mark the case required=False instead

required=False makes the generator print a warning instead of raising, but it
still writes the .pte and still adds the case to the manifest. The C++ driver
would then load a CPU-only program, compare it to the torch golden, and pass.
That is a green tick for a test that never touches the GPU, which is worse than
having no case at all.

Teaching the generator to also drop the manifest entry in that situation would
be a reasonable follow-up, but it is a separate change.

Test plan

test-webgpu-native is the only job that runs the op tests, and on its own this
branch cannot reach them: the job still stops earlier on the missing RoPE fixture
that #21690 fixes. So the two changes were tested together, on a branch holding
both, and that run passes:

[       OK ] WebGPUNative.RopeHfDynamicSequenceReusedGraph (29 ms)
=== WebGPU native tests on Dawn: all run targets passed ===
Generated 390 cases -> /tmp/webgpu_op_tests/manifest.json
[----------] 6 tests from OpTest_conv2d
[==========] 391 tests from 88 test suites ran. (37413 ms total)
[  PASSED  ] 391 tests.
=== WebGPU op-test framework on Dawn: passed ===

So the generator now gets all the way through, the op-test binary runs for the
first time, and all 391 generated tests pass, conv2d included with its
remaining 6 cases.

Tested on this branch alone as well, to confirm this change does not break
anything earlier: the job reaches the native tests and 28 of them pass, with the
single failure being the RoPE fixture that #21690 fixes.

What this costs in runner time

Generating the 390 cases takes about 35 minutes. In the green run above the whole
job took 75.5 minutes, of which 17.7 was setup and 57.4 was the test script.

That fits inside the current 120 minute limit, but only because that run had a
fast setup. The same setup steps have been measured as high as 64 minutes on the
same runner label, which would put this job at about 121 minutes. #21690 raises
the limit to 150 for that reason.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21697

• 📄 Preview Python docs built from this PR

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

⏳ No Failures, 11 Pending

As of commit 033e484 with merge base 9cd0c12 ():
💚 Looks good so far! There are no failures yet. 💚

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

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.