| commit | 82022e7ae3e92f148edd91f62c841460b61e2154 | [log] [tgz] |
|---|---|---|
| author | Lei Zhang <antiagainst@google.com> | Tue Jul 28 15:07:08 2020 -0700 |
| committer | Copybara-Service <iree-copybara-bot@google.com> | Tue Jul 28 15:09:11 2020 -0700 |
| tree | 2e79e1f59c29950587b786fed051c025a9303f5e | |
| parent | e1910acc0e13ea9b87a54d39acdb98a76c1b18a7 [diff] |
Merge main -> google * c404740c Merge pull request #2677 from antiagainst/google-to-main * 300ea5e3 Report error message for type mismatch (#2666) * 0a9b1266 Upload integrations bazel invocation to result store (#2658) * e84db55a Revert "Add GitHub action to create PRs merging google -> main" (#2676) * 360e2f09 Add a VM to EmitC conversion and CModule Target (#2536) * 7283cee4 Avoid running docker builds as root (#2663) * ffc70804 [ci] Add Dockerfile for bazel-nvidia and use it in Kokoro (#2546) * f5368718 Enable iota.test on vulkan-spirv and llvm-ir backends. (#2670) * 326a9950 Update third_party/sdl2 submodule to latest. (#2657) * 6326322c Include python headers even if nested. (#2669) * 06ed2dbc Add matmul tile and vectorize lowering stratgy to LinalgToLLVM passes (#2608) * a1914e7f Add a ZLIB find_package call for INSTALLED llvm builds. * d7412e9d Merge remote-tracking branch 'origin/main' into bazel-gpu * d687de87 Fix format * 96e224c7 [ci] Add Dockerfile and Kokoro configuration for Bazel and SwiftShader (#2646) * 6e5ddbc0 Test entry function conversion to LLVMIR (#2641) * 314afa52 Disable sliding window * 36f85516 Merge google -> main #2656 * 8baacad5 Disable SDL sensor support on Windows. (#2655) * 2b91d9ad Run integrations build as root (#2654) * b784bf23 Delete unnecessary 'continuous' Kokoro configs (#2649) * 84f52e13 Fixes dead getting started link. (#2652) * 50d15b49 Shuffle file again * a33973eb [ci] Add docker and kokoro configuration for SwiftShader (#2628) * 71dbd915 Move file to proper place * c9cd5f09 Add build.sh and update build_and_update_gcr.py * 11729722 Update to the new structure * ac7d6618 Merge remote-tracking branch 'origin/main' into bazel-gpu * 1425737d Fix flatcc target name and binary path (#2599) * 8c18b8c3 Refactoring bytecode_module to use flatcc instead of flatbuffers C++. This imp.. * 3762c132 Linking in the flatcc bytecode_module_def files. This ensures they are correct.. * eb53de3e Building bytecode_module_def with flatcc. * a47b4bda Fix docker names in comments * c8bc5aa2 Merge remote-tracking branch 'origin/main' into bazel-gpu * 6622499d [ci] Add Dockerfile for bazel-nvidia and use it in Kokoro COPYBARA_INTEGRATE_REVIEW=https://github.com/google/iree/pull/2691 from antiagainst:merge-main c404740c6a7d20688c38790dad0612cceff3acb3 PiperOrigin-RevId: 323662370
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 still at its early stage; we have lots of exciting future plans. Please check out the long-term design roadmap and short-term focus areas.
We use GitHub Projects to track various IREE components and GitHub Milestones for major features and quarterly plans. Please check out for updated information.
| CI System | Platform | Build System | Component | Status |
|---|---|---|---|---|
| Kokoro | Linux | Bazel | Core |  |
| Kokoro | Linux | Bazel | Bindings |  |
| Kokoro | Linux | Bazel | Integrations |  |
| Kokoro | Linux | CMake | Core + Bindings |  |
| Kokoro | Android | CMake | Runtime (build only) |  |
IREE is licensed under the terms of the Apache license. See LICENSE for more information.