-
Notifications
You must be signed in to change notification settings - Fork 648
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
[python] Add an iree.build package with API/tooling for program building. #18630
Conversation
Thanks for early look. PR is still draft. Tests and compile actions are coming. I really want it to be |
…ing. Signed-off-by: Stella Laurenzo <[email protected]>
6ff9f64
to
8502cdd
Compare
Signed-off-by: Stella Laurenzo <[email protected]>
73d9120
to
325dbbc
Compare
Signed-off-by: Stella Laurenzo <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. And thank you. It's really important that we have a unified methodology here. With the compiler action this will cover a lot of ground that otherwise usually turns into some clunky, bespoke process.
def invoke(self): | ||
import iree.compiler.tools.import_onnx.__main__ as m | ||
|
||
args = m.parse_arguments( | ||
[ | ||
str(self.input_file.get_fs_path()), | ||
"-o", | ||
str(self.output_file.get_fs_path()), | ||
] | ||
) | ||
m.main(args) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this support passing extra args/kwargs to the underlying script/tool? iree-import-onnx
has a few other supported arguments:
iree/compiler/bindings/python/iree/compiler/tools/import_onnx/__main__.py
Lines 118 to 134 in df2b8a4
parser.add_argument( | |
"--no-verify", | |
action="store_true", | |
help="Disable verification prior to printing", | |
) | |
parser.add_argument( | |
"--data-prop", | |
default=True, | |
action=argparse.BooleanOptionalAction, | |
help="Toggle data propogation for onnx shape inference", | |
) | |
parser.add_argument( | |
"--data-dir", | |
help="Path to the base directory of the data." | |
" Defaults to the directory of the input file.", | |
type=Path, | |
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It can be made to do so. Let's get the basics in and iterate. TBH - I only wrote this boilerplate ONNX support for testing the basic tool flow because ONNX is the only path that doesn't require carefully juggling the knives of an ML framework. So it was a pragmatic thing to get something going vs a fully formed thought on "this is the full solution for ONNX".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Trying to test this locally on Windows since MLIR Python bindings tend to break in weird ways there. Bumped into an unrelated error first though: #18910 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That will also require followons I expect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just don't want our 6 hour nightly Windows build to fail if we merge this before testing on Windows. (#18813 will get faster builds running more frequently)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well I'm still reconstructing my Windows build environment... but I think I got enough signal from a partial build to trust this.
Test failed on macos bot: https://github.com/iree-org/iree/actions/runs/11627272067/job/32380320905#step:9:1650
Python 3.10 |
Test also failed on Windows bot, same error: https://github.com/iree-org/iree/actions/runs/11627295212/job/32380385457#step:8:1703 The release build succeeded though, so that's less urgent to fix |
_locals = threading.local() | ||
|
||
|
||
class FileNamespace(enum.StrEnum): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
enum.StrEnum
was added in Python 3.11, so this code is failing to run on Python 3.10, which we still support
https://docs.python.org/3/library/enum.html
Added in version 3.11: StrEnum, EnumCheck, ReprEnum, FlagBoundary, property, member, nonmember, global_enum, show_flag_values
Failing CI builds:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, we only publish wheels for Python 3.11+ on Windows and macOS, so we could bump those workflows to use newer Python versions. I'll send a PR.
Pending CI builds (since these are nightly / on-demand and take hours): * Windows: https://github.com/iree-org/iree/actions/runs/11689195978 * macOS: https://github.com/iree-org/iree/actions/runs/11689197108 The new `iree.build` package depends on Python 3.11: #18630 (comment). We currently publish Python packages for 3.9+ on Linux but only 3.11+ on macOS and Windows: * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/build_tools/python_deploy/build_linux_packages.sh#L68 * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/.github/workflows/build_package.yml#L259-L266 * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/.github/workflows/build_package.yml#L247-L254 We can relax the 3.11 dependency in the package, but we might as well update these workflows to test with the version that we distribute packages for.
As discussed on #18630 (comment), now that `iree-import-onnx` supports upgrading the model version itself (added in #18880), we don't need to also maintain this logic in the `iree.build` package.
Pending CI builds (since these are nightly / on-demand and take hours): * Windows: https://github.com/iree-org/iree/actions/runs/11689195978 * macOS: https://github.com/iree-org/iree/actions/runs/11689197108 The new `iree.build` package depends on Python 3.11: iree-org#18630 (comment). We currently publish Python packages for 3.9+ on Linux but only 3.11+ on macOS and Windows: * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/build_tools/python_deploy/build_linux_packages.sh#L68 * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/.github/workflows/build_package.yml#L259-L266 * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/.github/workflows/build_package.yml#L247-L254 We can relax the 3.11 dependency in the package, but we might as well update these workflows to test with the version that we distribute packages for.
…rg#19210) As discussed on iree-org#18630 (comment), now that `iree-import-onnx` supports upgrading the model version itself (added in iree-org#18880), we don't need to also maintain this logic in the `iree.build` package.
…ing. (iree-org#18630) This is the first step of providing a unified user-oriented build tool for IREE export and compilation. This initial version supports the CLI environment, network/fetch actions, and ONNX import+upgrade. A follow-on step will build out the compiler invocation rules, specifically focusing on getting option, device, and parameter handling and manifest/metadata propagated properly. The intent is that downstream users of the IREE/Turbine tools can have one stop modules to efficiently export and compile arbitrarily complicated pipelines without reinventing the wheel or needing to do the advanced compiler juggling that comes with some of the more complicated (and performant) workflows. As a by-product this will standardize a directory layout and manifest/metadata to accompany it for pipeline construction. The intent is that this will simplify serving tooling, which currently has to get a number of out of band parameters and files put together in the right way and matching how they were compiled. --------- Signed-off-by: Stella Laurenzo <[email protected]> Signed-off-by: Giacomo Serafini <[email protected]>
Pending CI builds (since these are nightly / on-demand and take hours): * Windows: https://github.com/iree-org/iree/actions/runs/11689195978 * macOS: https://github.com/iree-org/iree/actions/runs/11689197108 The new `iree.build` package depends on Python 3.11: iree-org#18630 (comment). We currently publish Python packages for 3.9+ on Linux but only 3.11+ on macOS and Windows: * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/build_tools/python_deploy/build_linux_packages.sh#L68 * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/.github/workflows/build_package.yml#L259-L266 * https://github.com/iree-org/iree/blob/9650bfe441d5f8ce4a16395ee6b3ad43968caa2e/.github/workflows/build_package.yml#L247-L254 We can relax the 3.11 dependency in the package, but we might as well update these workflows to test with the version that we distribute packages for. Signed-off-by: Giacomo Serafini <[email protected]>
…rg#19210) As discussed on iree-org#18630 (comment), now that `iree-import-onnx` supports upgrading the model version itself (added in iree-org#18880), we don't need to also maintain this logic in the `iree.build` package. Signed-off-by: Giacomo Serafini <[email protected]>
This is the first step of providing a unified user-oriented build tool for IREE export and compilation. This initial version supports the CLI environment, network/fetch actions, and ONNX import+upgrade. A follow-on step will build out the compiler invocation rules, specifically focusing on getting option, device, and parameter handling and manifest/metadata propagated properly.
The intent is that downstream users of the IREE/Turbine tools can have one stop modules to efficiently export and compile arbitrarily complicated pipelines without reinventing the wheel or needing to do the advanced compiler juggling that comes with some of the more complicated (and performant) workflows.
As a by-product this will standardize a directory layout and manifest/metadata to accompany it for pipeline construction. The intent is that this will simplify serving tooling, which currently has to get a number of out of band parameters and files put together in the right way and matching how they were compiled.