Support Float8_e8m0fnu and Float4_e2m1fn_x2 in stable ABI#173669
Support Float8_e8m0fnu and Float4_e2m1fn_x2 in stable ABI#173669janeyx99 wants to merge 7 commits into
Conversation
[ghstack-poisoned]
This PR needs a
|
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/173669
Note: Links to docs will display an error until the docs builds have been completed. ✅ You can merge normally! (2 Unrelated Failures)As of commit c12c194 with merge base 89f3102 ( FLAKY - The following jobs failed but were likely due to flakiness present on trunk:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
Attention! PyTorch one of the C-stable API file was changedYou MUST NOT change existing function declarations in this, as this header defines a stable C ABI. If you need to change the signature for a function, introduce a new v2 version of the function and modify code generation to target the new version of the function. Caused by: |
Missing tests! Will add after landing Nicolas' PR. [ghstack-poisoned]
| ' | ||
| HeaderFilterRegex: '^(aten/|c10/|torch/).*$' | ||
| WarningsAsErrors: '*' | ||
| LineFilter: |
There was a problem hiding this comment.
was this intentional
There was a problem hiding this comment.
thanks for the catch, this was unintentional, but this LineFilter thing keeps tripping up my local clang extension. If this happens for u too i'll make a sep PR to remove this
There was a problem hiding this comment.
Thanks, looks good to me. Tested this through pytorch/ao#3610 and it works well. I'll let @mikaylagawarecki do the final stamp
mikaylagawarecki
left a comment
There was a problem hiding this comment.
Stamp as long as clang-tidy is in a separate PR (I don't run into issues/am not sure what the change does)
|
Starting merge as part of PR stack under #174809 |
|
Starting merge as part of PR stack under #174809 |
2 similar comments
|
Starting merge as part of PR stack under #174809 |
|
Starting merge as part of PR stack under #174809 |
|
Starting merge as part of PR stack under #174735 |
Pull Request resolved: #174733 Approved by: https://github.com/zou3519 ghstack dependencies: #173669
This fixes the bug where SymInts, MemoryFormat, ScalarType, and Layout were all entering the IntType path instead of going on their respective branches. We do explicitly point SymInt to Int for now, because we do not support having a StableIValue from SymInt yet, but nothing has decreased in support due to this change. If you don't believe me, check out the test case I added in the stack just one above that tests that with or without this change, registering certain ops with SymInt schemas work and don't cause recompiles. Pull Request resolved: #174734 Approved by: https://github.com/albanD ghstack dependencies: #173669, #174733
We already had a shim for it, so we're merely adding a C++ convenience wrapper and tests. This is why we can stick it in libtorch_agn_2_9. I had wanted to just write a test that would take in a Tensor and return a Layout and then check that the layout matches in python, but I learned that our python binding code (pytorch/torch/csrc/jit/python/pybind_utils.cpp) doesn't properly convert Layout IValues to torch.layout (because layout, dtype and memory format are all treated like ints). So the test case I ended up writing takes in a Layout and runs the check from C++. Further testing I've done: I wanted to confirm that my_layout would still run with no problems on 2.9 even if it needs to be built with 2.11 for the layout API. So I: - built a wheel for libtorch_agn_2_9 with my PR's torch - went to a different conda env - installed 2.9.1 torch - installed the wheel i just built - ran the test `python test/cpp_extensions/test_libtorch_agnostic.py -v -k my_layout` and it passed! Pull Request resolved: #174735 Approved by: https://github.com/andrewor14 ghstack dependencies: #173669, #174733, #174734
ghstack-source-id: e5fafc4 Pull Request resolved: pytorch/pytorch#173669 mend
* fix: gate torch stable ABI on >=2.11 and allow env override torch 2.10's stable ABI is missing Float8_e8m0fnu (ScalarType 44), so passing a UE8M0 weight scale through torch.ops.humming.launch_kernel fails with "RuntimeError: Not yet supported ScalarType 44". Support for Float8_e8m0fnu and Float4_e2m1fn_x2 in the stable ABI was added in pytorch/pytorch#173669, gated by TORCH_FEATURE_VERSION >= TORCH_VERSION_2_11_0 (first available in torch 2.11.0, released 2026-03-23). Bump the version threshold to >= 2.11 so the stable ABI path is only taken when its dtype coverage matches humming's needs, and add the HUMMING_USE_TORCH_STABLE_API env var so users can force the choice. The non-stable ABI fallback already exists in csrc/launcher/torch_api.h and supports the full ScalarType enum via native at::Tensor. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * address review: include stable-ABI flag in cache key, drop redundant import - get_humming_launcher_build_dir now takes use_torch_stable_api and appends "stable" / "nostable" to the build dir, so toggling HUMMING_USE_TORCH_STABLE_API no longer risks loading a stale launcher binary compiled with the opposite flag value. - Drop the now-unused packaging.version.Version import in init_humming_launcher; the version comparison lives in _resolve_use_torch_stable_api. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Missing tests! Will add after landing Nicolas' PR.
Ahh I still need to clean some stuff up: gotta remove my clang-tidy removal oop. And I'm now reconsidering whether I want float4 in the supported dtypes lol. cc @pearu if you have thoughts on this second point.
Stack from ghstack (oldest at bottom):