Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WebNN EP] Support int64 output data type for CoreML backend #21401

Open
Honry opened this issue Jul 18, 2024 · 3 comments
Open

[WebNN EP] Support int64 output data type for CoreML backend #21401

Honry opened this issue Jul 18, 2024 · 3 comments
Labels
ep:WebNN WebNN execution provider feature request request for unsupported feature or enhancement platform:mobile issues related to ONNX Runtime mobile; typically submitted using template

Comments

@Honry
Copy link
Contributor

Honry commented Jul 18, 2024

Describe the feature request

WebNN CoreML backend doesn't support int64 data type, however some ops from ONNX produce int64 output, e.g. ArgMax, ArgMin, etc., CoreML's AragMax reproduces int32 output.

That means we should check the dimension size being reduced is within int32 range, then do type casting (int32 -> int64) for the output.

The node of such op must be the output of a subgraph model, as its next node is int64 input which is not supported by CoreML backend, and it will fall back, unless it is a special case: ArgMax-Cast (from int64 to int32).

Following actions can be taken into account:

  • Use WebNN's opSupportLimits() to check if whether int64 data type is supported
  • Make sure producing int32 output instead is safe
  • Fuse ops for e.g. ArgMax-Cast(int64->int32)
  • Convert int32 output tensor back to int64

Besides, how CoreML EP handles int64 data type would be a good reference.

Describe scenario use case

N/A

@Honry Honry added the feature request request for unsupported feature or enhancement label Jul 18, 2024
@github-actions github-actions bot added the platform:mobile issues related to ONNX Runtime mobile; typically submitted using template label Jul 18, 2024
@fdwr
Copy link
Contributor

fdwr commented Jul 18, 2024

how CoreML EP handles int64 data type would be a good reference

Indeed, I really wonder given all indices are int64 in ONNX.

@fdwr fdwr added the ep:WebNN WebNN execution provider label Jul 18, 2024
@sophies927 sophies927 added the ep:CoreML issues related to CoreML execution provider label Jul 18, 2024
@skottmckay
Copy link
Contributor

CoreML EP converts all int64 attribute and initializer values to int32 when creating the CoreML model (and checks for overflow errors as it does it).

it also tracks if it needs to convert specific inputs/outputs between int64 and int32 when executing the CoreML model.

Once you have the attributes, initializers, and coreml model inputs as int32 the internals of the coreml model will produce int32 values, and we just need to convert the output from the coreml model back to int64 if applicable.

@Honry
Copy link
Contributor Author

Honry commented Aug 30, 2024

Thank you @skottmckay, that's really helpful!

  • For initializer conversion, the code is here, right? Looks like most of them are written into local weight files, then the conversion from int64 to int32 was handled by CoreML, right?

  • For input conversion (int64->int32), the code is here, right? How does it handle the data overflow for int64 inputs? For WebNN EP we need to use cast op to convert the int64 inputs to int32, it is not safe if there's data overflow exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ep:WebNN WebNN execution provider feature request request for unsupported feature or enhancement platform:mobile issues related to ONNX Runtime mobile; typically submitted using template
Projects
None yet
Development

No branches or pull requests

5 participants