Issue Station
Sign In
Tools hereToolbox

pytorch - ✅(Solved) Fix test utilities should intersect `torch.accelerator.get_device_capability` when resolving dtypes used for a test [1 pull requests, 2 comments, 3 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#177969•Fetched 2026-04-08 01:07:49
View on GitHub
Comments
2
Participants
3
Timeline
37
Reactions
1
Author
mikaylagawareckimikaylagawarecki
Participants
guangyeyguangyeymalfetmalfetmikaylagawareckimikaylagawarecki
Timeline (top)
mentioned ×12subscribed ×12labeled ×6commented ×2

PR fix notes

PR #165631: [Accelerator] Add Accelerator Capabilities API

Description (problem / solution / changelog)

Motivation

There are several issues related to the data type and precision that an accelerator supports (see #165038 and #143112). Sometimes, we have to check for these capabilities in the document, and then hard-code. This PR proposes a new unified API for users to check their accelerator capabilities.

Changes

This PR creates a new data structure DeviceCapability containing the capabilities that an accelerator commonly has:

  • Supporting DataType (set to be supported as default):
    • fp16, int32, complex ... etc
  • Other capabilities (need to be discussed)

To access the structure, this PR defines a new Python API in the Accelerator module -- get_device_capability. It takes device as an input and returns a dictionary containing the capabilities (now we have supported_dtypes as the key).

Usage

>>> import torch
>>> import torch_openreg
>>> torch.accelerator.get_device_capability('openreg:0')
{'supported_dtypes': [torch.uint8, torch.int8, torch.int16, torch.int32, torch.int64, torch.float16, torch.float32, torch.float64, torch.complex32, torch.complex64, torch.complex128, torch.bool, torch.qint8, torch.quint8, torch.qint32, torch.bfloat16, torch.quint4x2, torch.quint2x4, torch.bits1x8, torch.bits2x4, torch.bits4x2, torch.bits8, torch.bits16, torch.float8_e5m2, torch.float8_e4m3fn, torch.float8_e5m2fnuz, torch.float8_e4m3fnuz, torch.uint16, torch.uint32, torch.uint64, torch.uint1, torch.uint2, torch.uint3, torch.uint4, torch.uint5, torch.uint6, torch.uint7, torch.int1, torch.int2, torch.int3, torch.int4, torch.int5, torch.int6, torch.int7, torch.float8_e8m0fnu, torch.float4_e2m1fn_x2]}

TODO

  • So far, precision is the only capability to track, based on my knowledge. But we can find more capabilities in common, and the API should be designed for good extension.
  • It will support other in-tree accelerators, such as cuda and mps.
  • Clarify whether the capabilities are software or hardware supported. (By @guangyey )

cc @FFFrog

Changed files

  • aten/src/ATen/DeviceAccelerator.cpp (modified, +6/-0)
  • aten/src/ATen/DeviceAccelerator.h (modified, +5/-0)
  • c10/core/DeviceCapability.h (added, +76/-0)
  • c10/core/impl/DeviceGuardImplInterface.h (modified, +27/-0)
  • c10/core/impl/VirtualGuardImpl.h (modified, +4/-0)
  • test/cpp_extensions/open_registration_extension/torch_openreg/csrc/runtime/OpenRegGuard.h (modified, +9/-0)
  • test/cpp_extensions/open_registration_extension/torch_openreg/tests/test_device.py (modified, +8/-1)
  • torch/_C/__init__.pyi.in (modified, +1/-0)
  • torch/accelerator/__init__.py (modified, +26/-1)
  • torch/csrc/DeviceAccelerator.cpp (modified, +19/-0)
RAW_BUFFERClick to expand / collapse

https://github.com/pytorch/pytorch/pull/165631 added an accelerator hook to register supported_dtypes for accelerators. this should be queried when resolving the dtypes used for a test.

Placeholder issue (not actionable yet) as I fill in more details

cc @mruberry @albanD @guangyey @EikanWang

extent analysis

Fix Plan

To resolve the issue, we need to update the dtype resolution logic to query the supported_dtypes for accelerators.

Steps

  • Update the _get_dtypes() function to query the supported_dtypes for accelerators.
  • Modify the _parametrize_test functions in the @dtypes, @ops, @modules, and @optims paths to use the updated _get_dtypes() function.

Example Code

# Update _get_dtypes() function
def _get_dtypes(device_type, accelerator):
    supported_dtypes = accelerator.supported_dtypes
    # Filter dtypes based on the device type and supported dtypes
    dtypes = [dtype for dtype in device_type.dtypes if dtype in supported_dtypes]
    return dtypes

# Update _parametrize_test functions
def _parametrize_test(test_case, device_type, accelerator):
    dtypes = _get_dtypes(device_type, accelerator)
    # Parametrize the test with the updated dtypes
    test_case.parametrize("dtype", dtypes)

Verification

To verify the fix, run the tests with the updated dtype resolution logic and check that the tests pass with the correct dtypes.

Extra Tips

  • Make sure to update all occurrences of the _get_dtypes() and _parametrize_test functions in the @dtypes, @ops, @modules, and @optims paths.
  • Test the changes thoroughly to ensure that the fix does not introduce any regressions.

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

Still need to ship something?

×6

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

Back to top recommendations

TRENDING