Issue Station
Sign In
Tools hereToolbox

pytorch - ✅(Solved) Fix Add a bypass features to bypass the @onlyOn-based decorator [2 pull requests, 7 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
pytorch/pytorch#177248•Fetched 2026-04-08 00:42:51
View on GitHub
Comments
7
Participants
4
Timeline
85
Reactions
0
Author
fffrogfffrog
Participants
anubhavjanaanubhavjanafffrogfffrogmikaylagawareckimikaylagawareckiXAheliXAheli
Assignees
XAheliXAheli
Timeline (top)
subscribed ×24mentioned ×23unsubscribed ×8commented ×7

Fix Action

Fixed

PR fix notes

PR #1135: [RFC] Test Suite Configuration for running upstream pytorch tests from OOT devices

Description (problem / solution / changelog)

Thanks for sending a pull request! Please make sure you read the contributing guidelines.

What type of PR is this?

  • documentation

What this PR does:

The PR introduces a RFC which defines a YAML-based configuration framework that enables out-of-tree (OOT) PyTorch device backends to reuse upstream PyTorch tests without upstream modification. It provides a structured way to declare device capabilities — supported ops, dtypes, and tolerances — and control how each upstream test variant is treated: run and must pass, expected to fail, or skipped entirely. The framework is device-agnostic and demonstrated through IBM Spyre as the reference implementation.

Does this PR introduce a user-facing change?

No

Changed files

  • RFCs/TestConfigFramework/TestConfigFramework.md (added, +758/-0)

PR #178135: [Test] Add bypass_device_restrictions to allow PrivateUse1 backends to run @onlyOn gated tests

Description (problem / solution / changelog)

Fixes #177248

Adds a bypass_device_restrictions flag to DeviceTypeTestBase that allows PrivateUse1 based out-of-tree backends to run tests currently gated behind @onlyCUDA, @onlyOn and related decorators without modifying any upstream test files.

Changes

torch/testing/_internal/common_device_type.py

  • Add bypass_device_restrictions: bool = False class attribute to DeviceTypeTestBase (default False -- no impact on existing backends)
  • Set bypass_device_restrictions = True on PrivateUse1TestBase so that registered PrivateUse1 backends opt in automatically
  • In onlyOn.__call__ check the flag before raising SkipTest — if True the test proceeds on the PrivateUse1 device instead of being skipped

test/cpp_extensions/open_registration_extension/torch_openreg/tests/test_device.py

  • Add TestBypassDeviceRestrictions exercising both @onlyCUDA and @onlyOn(["cuda", "cpu"]) bypass via the openreg backend

cc @mruberry @NmomoN @mengpenghui @fwenguang @cdzhan @1274085042 @PHLens @albanD

Changed files

  • test/cpp_extensions/open_registration_extension/torch_openreg/tests/test_device.py (modified, +34/-0)
  • torch/testing/_internal/common_device_type.py (modified, +12/-0)

Code Example

class DeviceTypeTestBase(TestCase):
    bypass_device_restrictions = False 

class onlyOn:
    def __call__(self, fn):
        @wraps(fn)
        def only_fn(slf, *args, **kwargs):
            if hasattr(slf, "bypass_only_on") and slf.bypass_only_on:
                return fn(slf, *args, **kwargs)  # 绕过
            if slf.device_type not in self.device_type:
                raise unittest.SkipTest(...)
            return fn(slf, *args, **kwargs)
        return only_fn
RAW_BUFFERClick to expand / collapse

Some PyTorch testcases are also meaningful for verification on out-of-tree backends (PrivateUse1-based) as well, and the restrictions of some decorators like @onlyCUDA need to be removed.

Bypass restrictions like @onlyCUDA through DeviceBaseClass, with no other impact on the current community path.

class DeviceTypeTestBase(TestCase):
    bypass_device_restrictions = False 

class onlyOn:
    def __call__(self, fn):
        @wraps(fn)
        def only_fn(slf, *args, **kwargs):
            if hasattr(slf, "bypass_only_on") and slf.bypass_only_on:
                return fn(slf, *args, **kwargs)  # 绕过
            if slf.device_type not in self.device_type:
                raise unittest.SkipTest(...)
            return fn(slf, *args, **kwargs)
        return only_fn

cc @mruberry @NmomoN @mengpenghui @fwenguang @cdzhan @1274085042 @PHLens @albanD

extent analysis

Fix Plan

To bypass restrictions like @onlyCUDA through DeviceBaseClass, we will modify the onlyOn decorator and DeviceTypeTestBase class.

Steps

  • Modify the DeviceTypeTestBase class to set bypass_only_on to True for private use cases.
  • Update the onlyOn decorator to check for bypass_only_on attribute and bypass the restriction if set.

Example Code

class DeviceTypeTestBase(TestCase):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self.bypass_only_on = True  # Enable bypass for private use cases

class onlyOn:
    def __init__(self, device_type):
        self.device_type = device_type

    def __call__(self, fn):
        @wraps(fn)
        def only_fn(slf, *args, **kwargs):
            if hasattr(slf, "bypass_only_on") and slf.bypass_only_on:
                return fn(slf, *args, **kwargs)  # Bypass restriction
            if slf.device_type not in self.device_type:
                raise unittest.SkipTest("Test skipped for device type")
            return fn(slf, *args, **kwargs)
        return only_fn

Verification

To verify the fix, run the test cases with the modified DeviceTypeTestBase class and onlyOn decorator. The tests should now bypass the @onlyCUDA restriction for private use cases.

Extra Tips

  • Make sure to update the device_type attribute in the onlyOn decorator to include the private use case device types.
  • Consider adding additional logging or debugging statements to ensure the bypass mechanism is working as expected.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#installation#tensor shape#autograd error#batch processing#GPU compatibility#latency issue#model loading#dependency error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING