Google Git
Sign in
opensecura / 3p / openxla / iree / 77ff2e862e58cbb2716859f482da9a25aef278a0
commit77ff2e862e58cbb2716859f482da9a25aef278a0[log] [tgz]
authorphoenix-meadowlark <meadowlark@google.com>Mon May 11 15:34:34 2020 -0700
committerCopybara-Service <copybara-worker@google.com>Mon May 11 15:37:47 2020 -0700
treedb723a1c7dfc8e12f4c022507d48ca62b175da03
parent9ce4a06fe65e0fab132ed6e38f83f89094cdacba [diff]
Adds Dockerfiles for building with bazel and updates GitHub CI workflows

- Adds Dockerfiles that define images for our bazel and bazel with tensorflow builds.
- Adds a script for updating these images on the IREE-OSS Google container registry (GCR).
  - These images are hosted as `gcr.io/iree-oss/bazel` and `gcr.io/iree-oss/bazel-tensorflow`
- Updates the GitHub CI workflows to use these images.

This change adds Dockerfiles specifying the dependencies of IREE's core bazel build and IREE's integrations/bindings builds. This allows us to run CI tests in GitHub Actions without having to install the dependencies for each commit to master.

We are hosting the Docker images that these files build on the IREE-OSS GCP project. Currently, this means that every time there is a change to one of the Docker images, someone who is a storage admin for IREE-OSS must run the `build_tools/docker/update_gcr_images.sh` script. It should be possible to automate this process whenever a change is made to these files on GitHub in a future PR.

This change was tested by creating another branch based off of this one, changing the workflows to run on push to that branch and then pushing that change. Links to each test:

- [Bazel Build - Bindings](https://github.com/phoenix-meadowlark/iree/actions/runs/100891735)
- [Bazel Build - Fallthrough](https://github.com/phoenix-meadowlark/iree/actions/runs/100891736)
- [Bazel Build - Integrations](https://github.com/phoenix-meadowlark/iree/actions/runs/100891738) (Failed due to the build being broken at the time of testing).
- [Bazel Build -Core](https://github.com/phoenix-meadowlark/iree/actions/runs/100891741)

Since the integrations build failed due to the state of the repo at the time it was run, I ran the test again on my machine on a commit with a working build as a stand in and it passed.

Closes https://github.com/google/iree/pull/1874

COPYBARA_INTEGRATE_REVIEW=https://github.com/google/iree/pull/1874 from phoenix-meadowlark:docker-containers b280481b306a1a2ba76758437930a235ef6cf4f7
PiperOrigin-RevId: 311007783
7 files changed
tree: db723a1c7dfc8e12f4c022507d48ca62b175da03
  1. .github/
  2. bindings/
  3. build_tools/
  4. colab/
  5. docs/
  6. experimental/
  7. integrations/
  8. iree/
  9. kokoro/
  10. scripts/
  11. third_party/
  12. .bazelignore
  13. .bazelrc
  14. .bazelversion
  15. .clang-format
  16. .gitignore
  17. .gitmodules
  18. BUILD.bazel
  19. CMakeLists.txt
  20. CONTRIBUTING.md
  21. LICENSE
  22. README.md
  23. repo_utils.bzl
  24. SUBMODULE_VERSIONS
  25. WORKSPACE
README.md

IREE: Intermediate Representation Execution Environment

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.

Project Status

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 logisitics. 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!

Communication Channels

Related Project Channels

  • MLIR topic within LLVM Discourse: IREE is enabled by and heavily relies on MLIR. IREE sometimes is referred to in certain MLIR discussions. Useful if you are also interested in MLIR evolution.

Getting Started

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!

Documentation and Talks

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:

  • 2020-03-18: Interactive HAL IR Walkthrough (Ben Vanik and core team) (recording)
  • 2020-01-31: End-to-end MLIR Workflow in IREE (recording and slides)

Architecture and Goals

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:

IREE Architecture

Being compilation-based means IREE does not have a traditional runtime that dispatches “ops” to their fat kernel implemenations. 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

  • Support advanced models on mobile/edge devices. Dynamic shapes, dynamic flow control, dynamic multi-model dispatch, streaming models, tree-based search algorithms, and other are all good examples of exciting ML evolution. We are trying to build IREE from the ground-up to enable these models and run them efficiently on modern hardware, especially on mobile/edge devices.
  • Demonstrate MLIR‘s ability to develop non-traditional ML compiler backends and runtimes. MLIR enables IREE’s holistic approach of focusing on the math being performed and how that math is scheduled rather than graphs of “ops”.
  • Embrace standard-based ML via Vulkan. The graphics world is shifting towards favoring mordern explicit APIs for performance and predictability and Vulkan is emerging as the “compatibility” layer. We would love to allow hardware vendors to be able to make ML efficient on their hardware without the need for bespoke runtimes and special access. We also would love to let developers and users utilize all the hardware available on as many platforms as possible.

Roadmap and Milestones

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.

Build Status

CI SystemBuild SystemPlatformComponentStatus
GitHub ActionsBazelLinuxCoreWorkflow History
GitHub ActionsBazelLinuxBindingsWorkflow History
GitHub ActionsBazelLinuxIntegrationsWorkflow History
GitHub ActionsBazelLinuxOtherWorkflow History
KokoroBazelLinuxCorekokoro-status-bazel-linux
KokoroCMakeLinuxCore + Bindingskokoro-status-cmake-linux

License

IREE is licensed under the terms of the Apache license. See LICENSE for more information.