[js/web] revise backend registration

[fs-eire]

Description

This PR revises the backend registration.

The following describes the expected behavior after this change: (bolded are changed behavior)

• (ort.min.js - built without webgpu support)
  • loading: do not register 'webgpu' backend
  • creating session without EP list: use default EP list ['webnn', 'cpu', 'wasm']
  • creating session with ['webgpu'] as EP list: should fail with backend not available
• (ort.webgpu.min.js - built with webgpu support)
  • loading: always register 'webgpu' backend
    ( previous behavior: only register 'webgpu' backend when navigator.gpu is available)
  • creating session without EP list: use default EP list ['webgpu', 'webnn', 'cpu', 'wasm']
    • when WebGPU is available (win): use WebGPU backend
    • when WebGPU is unavailable (android): should fail backend init, and try to use next backend in the list, 'webnn'
      (previous behavior: does not fail backend init, but fail in JSEP init, which was too late to switch to next backend)
  • creating session with ['webgpu'] as EP list
    • when WebGPU is available (win): use WebGPU backend
    • when WebGPU is unavailable (android): **should fail backend init, and because no more EP listed, fail.

related PRs: #18190 #18144

[gyagp]

As I commented in the PR, the description has problem with EP list like ['webnn', 'webgpu'].
So the only diff between ort.min.js and ort.webgpu.min.js is webgpu support, due to concern of package size. For any release, a list of EPs will be served (designated by default or provided by developers), and webgpu will only be initialized when it's chosen.
BTW, for the default EP list, do we have any spec to describe the sequence? What's difference between cpu EP and wasm EP? Why do we put cpu prior to wasm?

[fs-eire]

As I commented in the PR, the description has problem with EP list like ['webnn', 'webgpu']. So the only diff between ort.min.js and ort.webgpu.min.js is webgpu support, due to concern of package size. For any release, a list of EPs will be served (designated by default or provided by developers), and webgpu will only be initialized when it's chosen. BTW, for the default EP list, do we have any spec to describe the sequence? What's difference between cpu EP and wasm EP? Why do we put cpu prior to wasm?

If we create session with executionProviders, the names will be used as EP list.
If we create session without executionProviders in session options, the default EP list will be used.

The default EP list is registered from lib/index.ts, with the BUILD_DEFS set correspondingly.

for example:

    registerBackend('webgpu', wasmBackend, 5);

This registered object wasmBackend with backend name "webgpu" and priority 5. The lower number means higher priority.

Technially they are all the same except webgl. For the "backend" concept defined in onnxruntime-common, there are only 2 backends implemented in onnxruntime-web: the web assembly backend and the webgl backend. Now in this PR, backend name is added into the init() function to allow the web assembly can do things differently when being called for a specific backend name.

The probject history may explain why the backend registery/resolve concept is confusing: when we migrated onnx.js to onnxruntime-web, the new concept "execution provider" came and it is similar to but yet different from the old "backend" concept. Now, "backend" is an internal concept and "execution provider" is the public term and used in API. Also, since the new onnxruntime-web is based on web assembly, for long term, every backend will be wasm backend.

[fs-eire]

This PR now includes all changes from #18756.

Initializations are now splitted into 3 steps for wasm. The last step is for initializations for EP speicific ( currently webgpu )

The wasm initialization steps are all combined and put into backend.init(), guarded as call_once.

The EP initialization step may be call multiple times, but for each EP name, it will also be called once.

[qjia7]

Nice work! I like this refactor.

[gyagp]

LGTM with 2 nits. Thanks for working on this!

[guschmue]

on top of this we need to also implement onnxruntime.get_available_providers()
because depending on the provider the app might want to load a different model, say for wasm quantized, for webgpu and webnn fp16 so it needs to know before it creates the session.

[gyagp]

on top of this we need to also implement onnxruntime.get_available_providers() because depending on the provider the app might want to load a different model, say for wasm quantized, for webgpu and webnn fp16 so it needs to know before it creates the session.

EP is available doesn't mean it can fully support a specific model. We may suppose developers would test their models with a specific version of onnxruntime-web, and set their EP list correctly.

[guschmue]

yes, and not all gpu's come equal even if the model works well on gpu in general.
Hard for developers to deal with this - longer term we should have some utility functions to help app developers with it.