| commit | eae7bfbf6f365b5b1315fb9c2bb5e854862c7537 | [log] [tgz] |
|---|---|---|
| author | Ben Vanik <ben.vanik@gmail.com> | Tue Dec 10 09:05:46 2024 -0800 |
| committer | GitHub <noreply@github.com> | Tue Dec 10 09:05:46 2024 -0800 |
| tree | c0013c76649af3e0234fa9743ce1732d94717a73 | |
| parent | e53fea4c68d2b53de9a566f6daedf9d533a44e88 [diff] |
Adding iree_hal_buffer_placement_t info to allocated HAL buffers. (#19160) This allows users to query for the device, queue affinity, and origin flags of an allocated buffer so that they can decide whether to copy buffers when moving across devices/queues, perform synchronous or asynchronous deallocations, and select queues to perform such operations. The downside is that prior to this buffers could be defined as shared across multiple devices that share a single allocator - because it's still the case that they can be shared "placement" was used as it's not "availability" or "access permissions" but only indicating the origin of the buffer and where it's preferred location is. Buffer compatibility queries are still the way to determine access visibility. The base `iree_hal_buffer_t` structure was cleaned up a bit and though still ugly is better prepared for removal of the device allocator back reference. #19159 tracks removing the allocator reference that is currently only used by the caching allocator due to our lack of dynamic casts. Breaking API changes: * `iree_hal_buffer_subspan` now requires an `iree_allocator_t host_allocator` that was previously implicit. * `iree_hal_subspan_buffer_initialize` removed as it was not safe and shouldn't have been used. * `iree_hal_deferred_buffer_t` removed as it is not possible to do the placement checks without an allocated buffer reference. This is used in a branch for async allocations on CPU but either a different approach is required there or it can be moved into `iree/hal/local/` where we can make assertions about universal accessibility. * `iree_hal_heap_buffer_wrap` and all other buffer creation now requires a placement. * `iree_hal_buffer_initialize` used by HAL implementations now requires a placement.
IREE (Intermediate Representation Execution Environment, pronounced as “eerie”) is an MLIR-based end-to-end compiler and runtime that lowers Machine Learning (ML) models to a unified IR that scales up to meet the needs of the datacenter and down to satisfy the constraints and special considerations of mobile and edge deployments.
See our website for project details, user guides, and instructions on building from source.
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
| Package | Release status |
|---|---|
| GitHub release (stable) |  |
| GitHub release (nightly) |  |
| Python iree-base-compiler |  |
| Python iree-base-runtime |  |
| Host platform | Build status |
|---|---|
| Linux |   |
| macOS |  |
| Windows |  |
For the full list of workflows see https://iree.dev/developers/general/github-actions/.
See our website for more information.
Community meeting recordings: IREE YouTube channel
IREE is licensed under the terms of the Apache 2.0 License with LLVM Exceptions. See LICENSE for more information.