| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
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 年前 | |
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 年前 |