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

Consider dropping the support of uint64/int64 data type for some operators #654

Open
lisa0314 opened this issue Apr 24, 2024 · 5 comments
Open

Comments

@lisa0314
Copy link

As @RafaelCintron mentioned in Chromium CL-5470845 for triangular,

Web developers are not going to test on every Windows combinations for these surprise failures that aren't documented anywhere. If this cannot be supported reliably, we should spec the operator to not support these data types from the jump.

Currently, public OS release was DML FL 4.0 on Windows 11 22H1, some operators and operand data type can't be supported reliably. Maybe we should spec these operators to not support these data types, such as int64/uint64.

@lisa0314 lisa0314 changed the title Consider dropping the support of uint64/int64 data type for some operators Consider dropping the support of uint64/int64 data type for triangular Apr 24, 2024
@lisa0314 lisa0314 changed the title Consider dropping the support of uint64/int64 data type for triangular Consider dropping the support of uint64/int64 data type for some operators Apr 24, 2024
@lisa0314
Copy link
Author

The operators listed below can't support uint64/int64 before DML FL4.1:

@a-sully
Copy link
Contributor

a-sully commented Apr 25, 2024

Related to #653. Note that CoreML does not natively support 64-bit types at all. If WebNN specifies that an operator uses 64-bit types, then either the operator will not be supported on Mac, or the user agent must emulate it outside of CoreML

@inexorabletash
Copy link
Member

For DML at least, aren't we expecting that most browsers would include their own copy of the library rather than relying on whatever happens to be on the system? That would remove the need to consider older DML versions when considering data type / operator support.

@huningxin
Copy link
Contributor

For DML at least, aren't we expecting that most browsers would include their own copy of the library rather than relying on whatever happens to be on the system?

If that's the case, we may close this issue. @RafaelCintron @fdwr , WDYT?

@fdwr
Copy link
Collaborator

fdwr commented Sep 5, 2024

For DML at least, aren't we expecting that most browsers would include their own copy of the library rather than relying on whatever happens to be on the system? That would remove the need to consider older DML versions when considering data type / operator support

FYI, a preliminary FWP has been published, and it's in testing and review: https://chromium-review.googlesource.com/c/chromium/src/+/5758180 (so after that, Chrome can also take advantage of newer operators and data type support)

Also with opSupportLimits (which didn't exist when the issue was created), we now have a means to express that backend variation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants