Update python bindings to be able to use a shared allocator and/or IDataTransfer registered by a plugin EP in the Environment

[skottmckay]

Description

Add ability to get shared allocator from env.
Add ability to create a MemCpyFunc using the IDataTransfer from the environment.

Motivation and Context

[skottmckay]

@gedoensmax will this provide what you need? not sure if there are any other places needing updates.

[github-actions]

You can commit the suggested changes from lintrunner.

[Copilot]

Pull Request Overview

This PR adds the ability for Python bindings to use shared allocators and IDataTransfer instances registered by plugin execution providers in the Environment. The main purpose is to enable data transfer operations between CPU and plugin-defined device memory for OrtValue objects.

Key changes include:

• Added shared allocator lookup from the Environment for plugin EPs
• Added ability to create MemCpyFunc using IDataTransfer from the Environment for device-to-CPU transfers
• Enhanced CUDA EP support to use shared allocators from plugin EPs in non-CUDA builds

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
onnxruntime/test/python/onnxruntime_test_python_autoep.py	Added test for shared data transfer and allocator usage, fixed typo
onnxruntime/test/autoep/library/ep_factory.cc	Renamed variable from cpu_allocator to device_allocator
onnxruntime/python/onnxruntime_pybind_state.cc	Enhanced tensor-to-numpy conversion to use plugin EP data transfer as fallback
onnxruntime/python/onnxruntime_pybind_ortvalue.cc	Added plugin EP allocator/data transfer fallback for device memory allocation
onnxruntime/python/onnxruntime_pybind_mlvalue.h	Changed MemCpyFunc from function pointer to std::function, added new helper function declarations
onnxruntime/python/onnxruntime_pybind_mlvalue.cc	Implemented helper functions for getting shared allocators and creating data transfer functions
onnxruntime/python/onnxruntime_inference_collection.py	Enhanced OrtDevice creation to support vendor_id parameter and simplified device creation logic
onnxruntime/core/session/environment.cc	Added shared allocator lookup with alignment-ignoring comparison and cleanup improvements
include/onnxruntime/core/session/environment.h	Added GetRegisteredSharedAllocator method and made mutex mutable
include/onnxruntime/core/framework/ortdevice.h	Added EqualIgnoringAlignment method for device comparison

[TedThemistokleous]

@snnn this broke Mainline for AMD, not sure why this got in without anyone from out end even looking at this or CI checks right now.

[skottmckay]

@snnn this broke Mainline for AMD, not sure why this got in without anyone from out end even looking at this or CI checks right now.

I'm not sure why the conflict detection didn't work. Typically if main has changed a PR that has conflicts with that change should be blocked from being checked in. The signature of GetCudaToHostMemCpyFunction for example was changed in different ways (return value in one PR, arguments in the other) by the two PRs and that should be trivial to detect as a conflict.

@snnn is something not setup or working correctly in the ORT repo?

[TedThemistokleous]

@skottmckay - Relevant read #25532

You guys are flying blind on all MIGraphX/ROCm/AMD stuff. Feel free to reach out if you need further support and resources from AMD.

[skottmckay]

@skottmckay - Relevant read #25532

You guys are flying blind on all MIGraphX/ROCm/AMD stuff. Feel free to reach out if you need further support and resources from AMD.

I'm slightly confused as to what the breakage was though. Was the breakage due to the checkin of this PR with the pending MIGraphX PR or did it break checked in code? If the latter, the conflict detection should have caught it, but based on the sequence of changes it's not clear to me that that was the case.

Original main from June 13
const std::unordered_map<OrtDevice::DeviceType, MemCpyFunc>* GetCudaToHostMemCpyFunction() {

Change from this PR updated the return value but the function still took no args.
const std::unordered_map<OrtDevice, MemCpyFunc>* GetCudaToHostMemCpyFunction() {

Change in new PR adds a new argument which matches what's in #25583 but as that's not checked in yet wouldn't have blocked any other changes going into main.
const std::unordered_map<OrtDevice, MemCpyFunc>* GetCudaToHostMemCpyFunction(const OrtDevice& device) {

What is 'mainline for AMD' building against?