-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Tracking] Refactor MLIR-AIE dependency #430
Closed
Comments
This was
linked to
pull requests
Jun 17, 2024
Closed
Closed
This was referenced Jun 17, 2024
Closed
Closed
Closed
The remaining AIE files we still depend on (after #546)
|
This was referenced Jul 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
TL;DR: This issue tracks ongoing work to refactor the dependency on MLIR-AIE
Description:
The goal of this sprint of work is to remove the dependency on AIE and AIEX dialects completely (AIEVec will remain). This includes artifact generation. Thus, one final deliverable is a build configuration (of this repo/plugin) that does not need to clone/build
Xilinx/mlir-aie
at all (for platforms/deployments that don't need AIEVec). The "business" goal is a more stable device configuration and runtime layer/experience for higher level dialects.Development Plan
The work proceeds in roughly two necessary phases (for the MVP) and planned extension work:
mlir-aie
;aie-rt
(the actual device configuration utility underneathmlir-aie
) andbootgen
(necessary for artifact construction) submodules;XCLBinGen
;aie-assign-lock-ids
,aie-assign-buffer-descriptor-ids
,aie-assign-buffer-addresses-basic
,aie-pathfinder
,aie-localize-locks
,aie-objectstateful-transform
,aiex-dma-to-npu
;aie-pathfinder
andaie-objectstateful-transform
perform any analysisaie-translate-cdo
,aie-translate-bcf
,aie-translate-ld-script
,aie-translate-npu
.aie-rt
into airee_aie_runtime
library which emulates the variousmlir_*_runtime
libs upstream (but still is only called at compile time; see planned work below);aie-pathfinder
(remove legacyd_ary_heap.h
) andaie-objectstateful-transform
;AIETargetModel
asAMDAIEDeviceModel
and base the latter onaie-rt
(i.e., useaie-rt
APIs for querying relevant device attributes/characteristics);objectfifo
directly instead ofbuffer
,dma
,switchbox
etc;At this point we will have a completely unified/self-contained path from
aie.objectfifo
to.xclbin
(modulo chess/peano) but we will still have a dependency on AIE dialect for theaie.objectfifo
op. The immediate next step is to connect directly toamdaie.logicalobjectfifo
in order to complete/reach the goal of removing the dependency on AIE/AIEX dialects (i.e., headers, libs, etc.). Because this last step is subject to progress on work involvingamdaie.logicalobjectfifo
, in fact all of the prior mentioned work will happen in a parallel lowering path through an ephemeral#hal.device.target<"amd-aie-direct", [#hal.executable.target<"amd-aie-direct">]>
. Once the direct connection toamdaie.logicalobjectfifo
is completeamd-aie-direct
takes over as the onlyhal
.Regarding, AIEVec dialect: the AIEVec dialect (used for emitting vector intrinsics targeting the single cores) does not depend on AIE/AIEX dialects and thus we can continue to keep it as a dependency.
Planned extension/further work includes:
iree-amd-aie
(this repo/plugin) and the single core compilers (i.e., chess and peano) by removing most of the "shell out";.ll
) for chess includes achesshack
step that rewrites present day LLVM IR to chess's version (15). Alternatively (I have verified this) we can emitllvm
dialect (MLIR IR) and translate it to LLVM IR usingmlir-translate-15
i.e., the version ofmlir-translate
built againstllvmorg-15.0.7
.chesshack
but furthermore link directly againstMLIRTranslateLib
built against the same tag1. I have verified this as well;xclbinutil
andbootgen
can also immediately be eliminated by simply making direct API calls into those libs (see xaiepy as a proof of this concept);chesscc
.aie-rt
actually emits) we are (mostly) free to move to a more conventional model of dispatch;aie-rt
can be "inlined" into the mid-level IR itself just as is done for the various GPU dialects, i.e.,iree_aie_runtime
can become a true runtime library;Testing Plan
Each step will be unit tested using the canonical ground-truth source:
mlir-aie/test
. I.e., in the intermediate phases steps, we vendor relevant tests in addition to code. In addition, at the phase that it becomes feasible (after the completion of vendoring) each step will be tested E2E i.e., artifact generation and testing for numerical accuracy. Prior to connecting toamdaie.logicalobjectfifo
we generate such executable starting fromaie.objectfifo
(usingmlir-aie
examples). After connecting toamdaie.logicalobjectfifo
we are free to use all of our own E2E tests.Current progress
Of the initial (MVP) work only the final step remains (redesigning CDO emission to consume
aie.objectfifo
). Timeline for this final step is ~1 week.Questions/comments/concerns
How/what/where/when questions are more than welcome here; why questions should be kept for 1-1/team meetings.
cc @stellaraccident @MaheshRavishankar @powderluv @jtuyls @kumardeepakamd @yzhang93 @newling @Abhishek-Varma @nirvedhmeshram @daveliddell
Footnotes
By using a small trick to create "versioned namespaces":
-DCMAKE_CXX_FLAGS="-Dmlir=mlir15 -Dllvm=llvm15"
. ↩ ↩2The text was updated successfully, but these errors were encountered: