commit | a3e97f1f74e51524fbd2f2fc27579b8bf15e68f2 | [log] [tgz] |
---|---|---|
author | Stella Laurenzo <stellaraccident@gmail.com> | Sat Dec 05 23:29:13 2020 -0800 |
committer | Stella Laurenzo <stellaraccident@gmail.com> | Mon Dec 07 15:10:32 2020 -0800 |
tree | f8dacac9910ba8b816738e6e65070cfc7f7738bb | |
parent | e5faf044ae469a6f15114c54aec05bfebcf9127b [diff] |
Step 4/n: Integrate TensorFlow compiler build and tests into CMake. * New option: 'IREE_BUILD_TENSORFLOW_COMPILER' * Adds some cmake hackery to find and configure bazel, scoping it under the build directory. * Adds an iree_add_bazel_invocation() function that executes bazel and creates cmake targets for some built executables. * Adds the cmake target 'integrations_iree_tensorflow_importers' as a bazel invocation. * Wires up the build for pyiree.tools.tf to link the binary from the bazel side. The result is a built bindings/python directory that can be used for tests and such with no further build required (or deployed directly). * Once I'm done with this transition, we can completely remove all of the python building from bazel, likely just replacing tests with a shell script runner, since they can just run standalone. * Also had to fix some issues with the python config (it wasn't detecting virtual envs properly due to using the old FindPython vars). * Added yet another hack to run_lit.sh because with bazel's out directory living in the build directory, it was taking 2m+ to scan files for things to add to the path. We shouldn't have been doing that, but also... Bazel, WTF? * Note that old build/tests of the integrations directory were double building almost everything because Bazel was differentiating between objects bound for binaries and for shared libraries. In addition, since it included the complete IREE compiler, it was building all of LLVM. * In the new world, we only build one static binary, and since it is just the frontend, the amount of things it needs to compile from LLVM are minimal. Most of the time is in compiling eigen kernels. * This will probably take some tweaking before it is ready for prime time. Stats: Clean build: configure: ~1m ninja build: ~10m (includes TF) ctest -E 'vulkan|benchmark': 14s (includes new TF tests but not the whole e2e directory yet) On a rebuild with CCache and Bazel's disk cache enabled from the above, a rebuild of everything took 18s.
IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler that lowers ML models to a unified IR optimized for real-time mobile/edge inference against heterogeneous hardware accelerators. IREE also provides flexible deployment solutions for the compiled ML models.
IREE is still in its early phase. We have settled down on the overarching infrastructure and are actively improving various software components as well as project logistics. It is still quite far from ready for everyday use and is made available without any support at the moment. With that said, we welcome any kind of feedback on any communication channels!
For development, IREE supports both Bazel and CMake on Windows and Linux. We are working on enabling macOS support. For deployment, IREE aims to additionally cover Android and iOS.
Please see the Getting Started pages on IREE's documentation hub to configure, compile, and run IREE in your favorite development environment!
IREE hosts all its documentation and project status dashboards on GitHub Pages. We are still building up the website; please feel free to create issues for the documentation you'd like to see!
We also have some public talks that explain IREE's concepts and architecture:
IREE adopts a holistic approach towards ML model compilation: the IR produced contains both the scheduling logic, required to communicate data dependencies to low-level parallel pipelined hardware/API like Vulkan, and the execution logic, encoding dense computation on the hardware in the form of hardware/API-specific binaries like SPIR-V.
The architecture of IREE is best illustrated by the following picture:
Being compilation-based means IREE does not have a traditional runtime that dispatches “ops” to their fat kernel implementations. What IREE provides is a toolbox for different deployment scenarios. It scales from running generated code on a particular API (such as emitting C code calling external DSP kernels), to a HAL (Hardware Abstraction Layer) that allows the same generated code to target multiple APIs (like Vulkan and Direct3D 12), to a full VM allowing runtime model loading for flexible deployment options and heterogeneous execution.
IREE aims to
IREE is in the early stages of development and not yet ready for broad adoption. Check out the long-term design roadmap to get a sense of where we're headed.
We plan on a quarterly basis using OKRs. Review our latest objectives to get a sense of what we're up to in the near term.
We use GitHub Projects to track progress on IREE components and specific efforts. We use GitHub Milestones to track the work associated with plans for each quarter.
IREE is licensed under the terms of the Apache license. See LICENSE for more information.