| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Create MLIR functions for ONNX operators that are functions (#3409) Resolves #3384. Many ONNX operators are defined by functions and therefore could be expanded into simpler ONNX operations during importing, avoiding the need for tools downstream to support these operators directly. This commit adds this capability to onnx_importer.py. When importing a node, the schema for the node's operator is retrieved. If the schema provides a function for the operator, a specialized version for the node's types and attributes will be created and imported as an MLIR function with private visibility. An MLIR function call will then be emitted, instead of a normal operator node. Caching is used to avoid generating redundant functions within the same module. In order to avoid a disruptive change to the importer output for a large number of operators that already have TorchOnnxToTorch support, an allowlist strategy is used by default. With this commit, only one operator is allowlisted for expansion, MeanVarianceNormalization. However, many other operators can be correctly expanded by the current code, so hopefully the allowlist can be gradually extended. It is possible to disable the allowlist in the configuration, in which case all functions are expanded (useful for testing). Tools downstream of the importer may now need to do inlining when consuming the output of the importer, e.g.: cat imported.mlir | torch-mlir-opt --inline --convert-onnx-to-torch Explanations for subtle code changes: - Looking up the correct schema and function for an operator requires knowing the opset version. NodeImporter retrieves this from the opset imports on the ModelProto retained by the GraphInfo. Previously, the model_proto field on GraphInfo was None when importing a subgraph in import_regions, but this conflicts with the new need for opset version info. Since the apparent purpose of setting it to None was to control how GraphInfo generates its input map, a new flag is added to GraphInfo (is_subgraph) to control this behavior, so that the actual ModelProto can now be provided without breaking this. This also turned out to be useful for getting the Config via ModelInfo via GraphInfo. - Some operators' functions are context-dependent, which means the function definition depends on the types of the inputs. Therefore node importing now needs to look up the types of a node's inputs, not just its outputs as was the case previously. Consequently the operand to find_type_proto_for_name() may now be a graph input or initializer in some cases, so it has to be updated. | 2 年前 | |
Upstream the ONNX importer. (#2636) This is part 1 of 2, which will also include upstreaming the FX importer. I started with ONNX because it forces some project layout updates and is more self contained/easier as a first step. Deviating somewhat from the RFCs on project layout, I made the following decisions: * Locating the onnx_importer.py into torch_mlir.extras as Maks already has opened up that namespace and it seemed to fit. Better to have fewer things at that level. * Setup the build so that the root project only contains MLIR Python and pure Python deps (like the importers), but this can be augmented with the projects/ adding more depending on which features are enabled. * The default build continues to build everything whereas in TORCH_MLIR_ENABLE_ONLY_MLIR_PYTHON_BINDINGS=1 mode, it builds a torch-mlir-core wheel with the pure contents only. onnx_importer.py and importer_smoke_test.py are almost verbatim copies from SHARK-Turbine. I made some minor local alterations to adapt to paths and generalize the way they interact with the outer project. I expect I can copy these back to Turbine verbatim from here. I also updated the license boilerplate (they have the same license but slightly different project norms for the headers) but retained the correct copyright. Other updates: * Added the ONNX importer unit test (which also can generate test data) in lit, conditioned on the availability of the Python onnx package. In a followup once I know everything is stable, I'll add another env var that the CI can set to always enable this so we know conclusively if tests pass. * Moved the ONNX conversion readme to docs/. * Renamed CMake option TORCH_MLIR_ENABLE_ONLY_MLIR_PYTHON_BINDINGS -> TORCH_MLIR_ENABLE_PYTORCH_EXTENSIONS and inverted the sense. Made the JitIR importer and LTC options cmake_dependent_options for robustness. | 2 年前 | |
[ONNX] improve regex matching in onnx-importer name sanitization (#3955) Instead of adding unsupported characters on a case-by-case basis, we should replace anything that isn't alphanumeric, _, or .. | 1 年前 | |
[ONNX] improve regex matching in onnx-importer name sanitization (#3955) Instead of adding unsupported characters on a case-by-case basis, we should replace anything that isn't alphanumeric, _, or .. | 1 年前 | |
[onnx] Add torch-mlir-import-onnx tool. (#2637) Simple Python console script to import an ONNX protobuf to the torch dialect for additional processing. For installed wheels, this can be used with something like: torch-mlir-import-onnx test/python/onnx_importer/LeakyReLU.onnx Or from a dev setup: python -m torch_mlir.tools.import_onnx ... | 2 年前 | |
[NFC reformat] Applies pre-commit formatting to Python files. (#3244) This is a large change because prior to this point, Python files in the project were not consistently formatted. This reformats them all with black defaults. Based on experience with prior projects, if you have a dev/long-term branch with Python patches, you can minimize merge conflicts prior to rebasing to include this commit by running black on your modified Python files, squashing, and then rebasing/merging. | 2 年前 | |
[NFC reformat] Applies pre-commit formatting to Python files. (#3244) This is a large change because prior to this point, Python files in the project were not consistently formatted. This reformats them all with black defaults. Based on experience with prior projects, if you have a dev/long-term branch with Python patches, you can minimize merge conflicts prior to rebasing to include this commit by running black on your modified Python files, squashing, and then rebasing/merging. | 2 年前 | |
[ONNX] Fix import of boolean tensor constants (#4064) Currently the shape and element type of boolean tensor attributes are incorrect, since they use the shape/dtype of the packed numpy array rather than of the original tensor value. Specifying the shape and element type explicitly resolves this. | 1 年前 | |
[onnx] Add torch-mlir-import-onnx tool. (#2637) Simple Python console script to import an ONNX protobuf to the torch dialect for additional processing. For installed wheels, this can be used with something like: torch-mlir-import-onnx test/python/onnx_importer/LeakyReLU.onnx Or from a dev setup: python -m torch_mlir.tools.import_onnx ... | 2 年前 | |
[NFC reformat] Applies pre-commit formatting to Python files. (#3244) This is a large change because prior to this point, Python files in the project were not consistently formatted. This reformats them all with black defaults. Based on experience with prior projects, if you have a dev/long-term branch with Python patches, you can minimize merge conflicts prior to rebasing to include this commit by running black on your modified Python files, squashing, and then rebasing/merging. | 2 年前 | |
Upstream the ONNX importer. (#2636) This is part 1 of 2, which will also include upstreaming the FX importer. I started with ONNX because it forces some project layout updates and is more self contained/easier as a first step. Deviating somewhat from the RFCs on project layout, I made the following decisions: * Locating the onnx_importer.py into torch_mlir.extras as Maks already has opened up that namespace and it seemed to fit. Better to have fewer things at that level. * Setup the build so that the root project only contains MLIR Python and pure Python deps (like the importers), but this can be augmented with the projects/ adding more depending on which features are enabled. * The default build continues to build everything whereas in TORCH_MLIR_ENABLE_ONLY_MLIR_PYTHON_BINDINGS=1 mode, it builds a torch-mlir-core wheel with the pure contents only. onnx_importer.py and importer_smoke_test.py are almost verbatim copies from SHARK-Turbine. I made some minor local alterations to adapt to paths and generalize the way they interact with the outer project. I expect I can copy these back to Turbine verbatim from here. I also updated the license boilerplate (they have the same license but slightly different project norms for the headers) but retained the correct copyright. Other updates: * Added the ONNX importer unit test (which also can generate test data) in lit, conditioned on the availability of the Python onnx package. In a followup once I know everything is stable, I'll add another env var that the CI can set to always enable this so we know conclusively if tests pass. * Moved the ONNX conversion readme to docs/. * Renamed CMake option TORCH_MLIR_ENABLE_ONLY_MLIR_PYTHON_BINDINGS -> TORCH_MLIR_ENABLE_PYTORCH_EXTENSIONS and inverted the sense. Made the JitIR importer and LTC options cmake_dependent_options for robustness. | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 1 年前 | ||
| 2 年前 | ||
| 2 年前 | ||
| 2 年前 |