-
Notifications
You must be signed in to change notification settings - Fork 53
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
Handling bfloat16 constant propagation #1484
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1484 +/- ##
==========================================
- Coverage 77.63% 77.59% -0.05%
==========================================
Files 212 212
Lines 23011 23023 +12
Branches 3945 3951 +6
==========================================
- Hits 17865 17864 -1
- Misses 4393 4399 +6
- Partials 753 760 +7 ☔ View full report in Codecov by Sentry. |
Test Results 28 files ± 0 28 suites ±0 2h 37m 28s ⏱️ - 14m 3s For more details on these failures and errors, see this check. Results for commit 7152688. ± Comparison against base commit 7b10687. This pull request removes 4 and adds 2028 tests. Note that renamed tests count towards both.
|
Just a temporary workaround for #1471 for experimentation/discussion.
It looks like the issue is that bfloat16 tensor constants are represented as float32 numpy arrays (in ONNX itself), when converted to numpy array. In the context of constant-propagation, this means that we cannot rely solely on the numpy value's dtype to figure out the ONNX type.
The hack below suppresses constant-propagation for bfloat16 constants: partially because of the above reason, and partially since I am yet unclear if this convention is supported by the onnx reference implementation (or ORT), etc. Assuming the backend supports it, we can try other alternative solutions too. One possibility is to simply suppress constant-propagation if the output-types are unknown (in the onnx model).