[Tianlei Wu (tianleiwu)]

Summary

• add an adapterIndex provider option for selecting a zero-based physical Dawn adapter
• enumerate adapters matching the requested backend and power preference in native Dawn builds
• reject unsupported external-Dawn/wasm combinations, out-of-range indices, invalid values, and conflicting context reuse
• document the distinction between physical adapterIndex and ORT deviceId

Testing

• clang-format --dry-run --Werror on all changed C++ files
• fresh current-main native Dawn configuration completed
• webgpu_context.cc and webgpu_provider_factory.cc compiled successfully against Dawn v20260818.211311
• full local plugin link was blocked by unrelated existing GCC 13 -Werror=maybe-uninitialized failures in WebGPU Gemm/InstanceNorm; PR CI covers the supported build matrix

[Copilot]

Pull request overview

Adds physical Dawn adapter selection to the WebGPU EP through adapterIndex.

Changes:

• Parses and validates the new provider option.
• Selects indexed native Dawn adapters and detects context conflicts.
• Adds tests and Python-facing documentation.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 5 comments.

Show a summary per file

File	Description
plugin-ep-webgpu/README.md	Documents adapter selection.
plugin-ep-webgpu/python/onnxruntime_ep_webgpu/README.md	Adds Python usage guidance.
onnxruntime/test/providers/webgpu/webgpu_context_test.cc	Adds option parsing tests.
onnxruntime/core/providers/webgpu/webgpu_provider_options.h	Defines the option key.
onnxruntime/core/providers/webgpu/webgpu_provider_factory.cc	Parses and logs the index.
onnxruntime/core/providers/webgpu/webgpu_context.h	Stores adapter configuration.
onnxruntime/core/providers/webgpu/webgpu_context.cc	Implements indexed selection and reuse validation.

---

💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Xiaofei Han (xiaofeihan1)]

Tianlei Wu (@tianleiwu) Thanks for addressing this! Great fix.

We recently ran into a similar multi-GPU challenge with the WebGPU EP as well. While reviewing the design, a couple of related scenarios and use cases came to mind that might be worth considering:

1. Plugin EP integration: When using the options.AppendExecutionProvider_V2(env, ep_devices, ep_options) API for Plugin EPs, we might need to select/initialize the corresponding Dawn adapter based on the specified ep_device.

2. Multi-device / multi-session support in a single process: Would it be feasible to support running different sessions on different GPUs? Currently, as mentioned, a single shared WebGPUContext is assumed. However, in scenarios like WebNN—where multiple sessions or contexts coexist within the same browser GPU process—different clients might request different power preferences (e.g., one site opting for low-power while another requests high-performance). If the context is strictly singleton across the process, they end up bound to the same underlying GPU. Supporting distinct adapters/devices across sessions would make this much more flexible.

const context = await navigator.ml.createContext({
      deviceType: 'gpu',          
      powerPreference: 'low-power' //'default' | 'high-performance' | 'low-power'
    });
    const builder = new MLGraphBuilder(context);

Just wanted to share these observations to see how they align with your current scope and roadmap. Would love to hear your thoughts on this!

[Tianlei Wu (tianleiwu)]

Xiaofei Han (@xiaofeihan1) Thanks for raising both cases. They are valid follow-up concerns, but I would keep them separate from this PR because mapping an OrtEpDevice to Dawn is not just copying HardwareDevice_DeviceId() into adapterIndex: ORT's hardware device ID is the PCI product/device ID, while adapterIndex is an ordinal in Dawn's backend- and power-preference-dependent enumeration. A robust V2 integration needs an identity bridge (for example, DXGI LUID / PCI bus identity where available) and defined behavior for duplicate identical GPUs; an ordinal-only mapping could silently choose the wrong adapter.

For multiple sessions, WebGpuContextFactory is already a context-ID-keyed registry rather than a literal singleton, and separate externally supplied webgpuInstance/webgpuDevice pairs can coexist today. The remaining limitation is that only context 0 may create its Dawn device internally. Lifting that safely also requires making shared allocators and data transfer context-aware; those paths currently assume device/context 0. This PR therefore keeps adapterIndex as explicit native-Dawn selection and rejects conflicting reuse instead of silently binding a later session to the first device. I agree that V2 device-to-adapter mapping and internally created multi-context support are useful follow-up work.

[Xiaofei Han (xiaofeihan1)]

Thanks Tianlei Wu (@tianleiwu), LGTM! Have you tested different adapters with this PR on setups with 3 or more GPUs? Does it work as expected? My main concern is that our CI/pipeline runners might not have enough GPUs to cover this scenario, potentially leaving edge cases untested

[Xiaofei Han (xiaofeihan1)]

Please resolve the merge conflicts

[github-actions]

You can commit the suggested changes from lintrunner.