| commit | 919fd71063eda7fe3233579344ac79e486c98643 | [log] [tgz] |
|---|---|---|
| author | Geoffrey Martin-Noble <gcmn@google.com> | Mon Jan 11 18:02:04 2021 -0800 |
| committer | GitHub <noreply@github.com> | Mon Jan 11 18:02:04 2021 -0800 |
| tree | f2d165a61edb137f34152b22c3ba50363c6ad0ad | |
| parent | a6e2d78338dda3be9455ca39666f3f6a7da6839b [diff] |
Force push when synchronizing submodules (#4426) Instead of adding a new commit that fixes up the submodules, rewrite the HEAD commit so that they are correct. This action was originally intended for rare cases where Copybara messed up integrations. These "rare cases" now happen multiple times a day and are cluttering the repository history with useless commits. We have already decided it's ok to rewrite the google branch history to fix up Copybara failures to create merge commits, so this doesn't change things much. It also us to expand this action to create those merge commits as well. Somewhat incidentally, I noticed that this action doesn't actually need to initialize the submodules themselves. It only really deals in hashes, which are already recorded. Dropping this makes it ~10x faster. This has a couple disadvantages: - If multiple commits are pushed and an intermediate one is the one that introduces a submodule diff, the changes will get erroneously attributed to the current HEAD commit. The rate of pushes to this branch is pretty low, so I don't think that will happen to frequently. I can work on some more complex logic that walks the history instead. - If someone is trying to track the google branch, rewriting history more frequently will make things difficult for them. This branch is only intended for the export from google source control, so the only people who should care about it are build cops and maybe googlers, and I think the inconvenience will be minor. - There will be some lag time between when a commit is exported and when it can be safely merged into the main branch. This action runs in about 10 seconds and quickly reports a failure (plus you can see the pending status as well), so I think this isn't likely to happen. Tested: Ran this on my fork. Initially pushed a cherry-picked version of https://github.com/google/iree/commit/78170d0a58fe . The check action failed on this, marking it with an "x" (https://github.com/GMNGeoffrey/iree/runs/1666244136) and the synchronize action fixed it up (https://github.com/GMNGeoffrey/iree/runs/1666187868) with the final result being https://github.com/GMNGeoffrey/iree/commit/ec9e72364088.
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!
Python packages are published on the releases page. See the colab/ directory for examples.
IREE can be built from source using both Bazel and CMake on Windows and Linux. We also have experimental macOS support.
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.
| CI System | Build System | Platform | Architecture | Component | Status |
|---|---|---|---|---|---|
| Kokoro | Bazel | Linux | x86 | Core |  |
| Kokoro | CMake & Bazel | Linux | x86-swiftshader | Integrations |  |
| Kokoro | CMake & Bazel | Linux | x86-turing | Integrations |  |
| Kokoro | CMake | Linux | x86-swiftshader | Core + Bindings |  |
| Kokoro | CMake | Linux | x86-turing | Core + Bindings |  |
| Kokoro | CMake | Android | arm64-v8a | Runtime (build only) |  |
| BuildKite | CMake | Android | arm64-v8a | Runtime |  |
IREE is licensed under the terms of the Apache license. See LICENSE for more information.
