commit | fa16b40b0fb446262da9ac7f194d551ef68bb554 | [log] [tgz] |
---|---|---|
author | Scott Todd <scotttodd@google.com> | Fri Sep 11 08:07:02 2020 -0700 |
committer | GitHub <noreply@github.com> | Fri Sep 11 08:07:02 2020 -0700 |
tree | 7565c4a7403fb9044cff31b389ef0cbf34a3d0cf | |
parent | 465279e585ebb0bec7c2213ba043a3db74db48e2 [diff] |
Refactor semaphore use in async and sync public ABI functions. (#3118) This makes async the "default", with sync wrapping async, instead of the other way around. Now we can push semaphores down further into the compiler (e.g. to remove hal.ex.submit_and_wait). Progress on https://github.com/google/iree/issues/1285 --- If the test is hard to read, here's a sample from simple.mlir's translation: * Note how the `$sync` function creates a semaphore to pass into the `$async` function and waits for it to be incremented from `0` to `1` before returning. The `$async` function still waits and signals, but could instead pass the semaphores into the raw function for a `hal.submit`, removing the need for `hal.ex.submit_and_wait`. Before: ```mlir func @abs$sync(%arg0: !hal.buffer_view) -> !hal.buffer_view attributes {iree.abi.stub, iree.module.export = "abs", iree.reflection = {f = "I6!B3!t6R6!B3!t6", fv = "1"}} { %buffer = hal.buffer_view.buffer %arg0 : !hal.buffer %0 = call @abs(%buffer) : (!hal.buffer) -> !hal.buffer %view = hal.buffer_view.create %0, shape = [], element_type = 16777248 : !hal.buffer_view return %view : !hal.buffer_view } func @abs$async(%arg0: !hal.semaphore, %arg1: index, %arg2: !hal.buffer_view, %arg3: !hal.semaphore, %arg4: index) -> !hal.buffer_view attributes {iree.module.export = "abs$async"} { %0 = hal.semaphore.await %arg0, min_value = %arg1 : i32 hal.check_success %0, "semaphore wait failed" %1 = call @abs$sync(%arg2) : (!hal.buffer_view) -> !hal.buffer_view hal.semaphore.signal %arg3, value = %arg4 return %1 : !hal.buffer_view } ``` After: ```mlir func @abs$async(%arg0: !hal.semaphore, %arg1: index, %arg2: !hal.buffer_view, %arg3: !hal.semaphore, %arg4: index) -> !hal.buffer_view attributes {iree.module.export = "abs$async"} { %0 = hal.semaphore.await %arg0, min_value = %arg1 : i32 hal.check_success %0, "semaphore wait failed" %buffer = hal.buffer_view.buffer %arg2 : !hal.buffer %1 = call @abs(%buffer) : (!hal.buffer) -> !hal.buffer %view = hal.buffer_view.create %1, shape = [], element_type = 16777248 : !hal.buffer_view hal.semaphore.signal %arg3, value = %arg4 return %view : !hal.buffer_view } func @abs$sync(%arg0: !hal.buffer_view) -> !hal.buffer_view attributes {iree.abi.stub, iree.module.export = "abs", iree.reflection = {f = "I6!B3!t6R6!B3!t6", fv = "1"}} { %c0 = constant 0 : index %c1 = constant 1 : index %dev = hal.ex.shared_device : !hal.device %semaphore = hal.semaphore.create %dev, initial_value = %c0 : !hal.semaphore %0 = call @abs$async(%semaphore, %c0, %arg0, %semaphore, %c1) : (!hal.semaphore, index, !hal.buffer_view, !hal.semaphore, index) -> !hal.buffer_view %1 = hal.semaphore.await %semaphore, min_value = %c1 : i32 hal.check_success %1, "semaphore wait failed" return %0 : !hal.buffer_view } ```
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.
IREE is licensed under the terms of the Apache license. See LICENSE for more information.