Add support to fetch device type from EP subgraph assignment

[adrastogi]

Description

#26781 added support for retrieving subgraph metadata for the assigned EPs in the session. There was a request via #27167 to add device type support, so this change attempts to implement that suggestion.

Motivation and Context

See #27167 for details.

[Copilot]

Pull request overview

Adds hardware device type visibility to the existing “EP subgraph assignment” observability feature, by plumbing an optional per-subgraph OrtHardwareDevice from plugin EP fusion options through partitioning and into the session’s recorded EP-assignment metadata. This is then exposed via new C API/C++ wrapper entry points and a Python binding, with autoep + Python tests validating default and plugin-declared behaviors.

Changes:

• Extends plugin EP fusion options with an optional per-subgraph OrtHardwareDevice* and safely version-gates reading it for older plugin binaries.
• Records resolved hardware device(s) per assigned subgraph (prefer per-subgraph override, else EP’s first registered OrtEpDevice, else empty).
• Exposes the data via OrtApi::EpAssignedSubgraph_GetHardwareDevices, C++ EpAssignedSubgraph::GetHardwareDevices(), and a Python-facing property; adds tests.

Show a summary per file

File	Description
onnxruntime/test/python/onnxruntime_test_python.py	Extends Python test to validate device-type behavior for implicit CPU EP subgraphs.
onnxruntime/test/autoep/test_execution.cc	Adds/extends autoep coverage for hardware-device resolution, including per-subgraph override precedence.
onnxruntime/test/autoep/test_autoep_utils.h	Adds a new example-EP test hook signature for setting fused-node hardware device.
onnxruntime/test/autoep/test_autoep_utils.cc	Loads the new example-EP hook symbol from the plugin library.
onnxruntime/test/autoep/library/example_plugin_ep/example_plugin_ep_library.lds	Exports the new hook symbol on ELF platforms.
onnxruntime/test/autoep/library/example_plugin_ep/ep.cc	Plumbs the test-controlled hardware device into OrtNodeFusionOptions.
onnxruntime/test/autoep/library/example_plugin_ep/ep_test_hooks.h	Declares the new exported hook for setting per-fused-node hardware device.
onnxruntime/test/autoep/library/example_plugin_ep/ep_test_hooks.cc	Implements the new hook and stores the pointer in an atomic.
onnxruntime/python/onnxruntime_pybind_state.cc	Exposes device-type info on OrtEpAssignedSubgraph in Python.
onnxruntime/core/session/plugin_ep/ep_plugin_provider_interfaces.cc	Transfers plugin-declared per-subgraph hardware device into ComputeCapability.
onnxruntime/core/session/ort_apis.h	Declares the new C API entry point in ORT’s internal API surface.
onnxruntime/core/session/onnxruntime_c_api.cc	Implements and registers EpAssignedSubgraph_GetHardwareDevices in the OrtApi table.
onnxruntime/core/session/inference_session.cc	Resolves and records per-subgraph hardware device(s) into stored EP assignment metadata.
onnxruntime/core/session/ep_graph_assignment_info.h	Stores hardware device pointer(s) on OrtEpAssignedSubgraph.
onnxruntime/core/session/abi_ep_types.cc	Avoids out-of-bounds reads by version-gated, field-by-field copying of OrtNodeFusionOptions.
onnxruntime/core/framework/graph_partitioner.h	Updates callback documentation and adds an include (currently unused).
onnxruntime/core/framework/graph_partitioner.cc	Updates partition-assignment callback comment to mention device resolution inputs.
onnxruntime/core/framework/compute_capability.h	Adds optional ep_hardware_device field for observability plumbing.
include/onnxruntime/core/session/onnxruntime_ep_c_api.h	Adds OrtNodeFusionOptions::fused_node_hardware_device with documentation and versioning notes.
include/onnxruntime/core/session/onnxruntime_cxx_inline.h	Adds C++ inline wrapper to fetch subgraph hardware devices via the C API.
include/onnxruntime/core/session/onnxruntime_cxx_api.h	Declares EpAssignedSubgraph::GetHardwareDevices() in the public C++ API.
include/onnxruntime/core/session/onnxruntime_c_api.h	Adds the public C API doc + function pointer for EpAssignedSubgraph_GetHardwareDevices.

Review details

• Files reviewed: 22/22 changed files
• Comments generated: 3
• Review effort level: Low

[Copilot]

Review details

• Files reviewed: 22/22 changed files
• Comments generated: 3
• Review effort level: Low

[Copilot]

Review details

• Files reviewed: 22/22 changed files
• Comments generated: 0 new
• Review effort level: Low

[skottmckay]

I'd be reticent to add fused_node_hardware_device at this point as it's a value that potentially adds confusion when it's not the EPs default device. User has no way to directly use that device and it won't match the device in the OrtEpDevice default allocator.

This possibly requires a much broader design to best support EPs which have multiple devices internally. The current setup of an EP having a single default device type worked fine years ago where it was CPU or discrete GPU but limits what's possible. Unfortunately handling this well will require changes into many places.

One potential option would be to allow the EP to explicitly specify the device for inputs/outputs in the ComputeCapability during partitioning. We could set the OrtDevice in the NodeInfo values at that point (if not specified use current logic to set) instead of later downstream as we do currently. That's not a clean change though as for some usages you want OrtMemoryInfo and not just OrtDevice.

At least these and probably other areas need updates

• Should all devices be explicitly provided during EP registration for clarity on what's possible
• EP must provide CopyTensors implementations to handle any devices it uses.
  • this enables ORT users to be able copy/read data to/from the correct input/output for the inference setup if they want to do that directly
• Logic in the memcpy transformer needs to be able to handle these additional devices.
  • that's potentially quite a complicated update
• allocation planning and any code that uses the EP's default device needs review and potential update
• need to consider things like SessionGetMemoryInfoForInputs/SessionGetMemoryInfoForOutputs.
  • I think it would be much better for that to be able to return the 'real' device, but that could be considered to be a breaking change.
  • e.g. currently for OV or QNN it's always going to say CPU. those EPs provide a HOST_ACCESSIBLE allocator, and memory can be provided using that, however you don't actually know whether that's required/beneficial as the input may be used on CPU by the EP internally. if the EP can directly say where it will consume the data during partitioning there's no confusion.