-
Notifications
You must be signed in to change notification settings - Fork 221
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
[MLIR] Binary backend - step 1 - nonxdlops fwd path #841
Conversation
This comment has been minimized.
This comment has been minimized.
f0316ea
to
153a8f4
Compare
Reviewers, please review ;) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
[Off-topic] @jerryyin Please try to not forget to terminate outdated CI job after pushing to the repo. Thanks! |
@atamazov Sounds good, will keep a closer eye on delinquent CI jobs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like we should not borrow StridedMemRefType<>
from MLIR. Conceptually, it represents the layout of MLIR kernel parameters. IIUC this layout may change in the future, so the relevant abstraction should be a part of the Miir API. Otherwise we will have a situation when some part of Miir implementation is penetrated into MIOpen.
Luckily we do not need much. The only thing we need is a struct type (POD type equivalent to the data members of StridedMemRefType<void, 4>
). You can define it in the Miir.h, thus isolating MIOpen from the specific layout of MLIR kernel parameters.
When/if the implementation of StridedMemRefType<>
in MLIR change, you would need to update that struct type in Miir.h.
Sounds reasonable?
src/conv/invokers/mlir_impl_gemm.cpp
Outdated
target.basePtr = const_cast<void*>(ptr); // NOLINT (cppcoreguidelines-pro-type-const-cast) | ||
target.data = const_cast<void*>(ptr); // NOLINT (cppcoreguidelines-pro-type-const-cast) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[Optimization] Only initialization of pointers (buffer addresses) should be left in the Invoker... (see next comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's postpone this. #862 created.
std::copy(dims.cbegin(), dims.cend(), &target.sizes[0]); | ||
std::copy(strides.cbegin(), strides.cend(), &target.strides[0]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
...while strides and sizes and known in the Factory (outer lambda), and necessary initializations should be performed there. In this case the only thing that Invoker will need to do (before launching the kernel) is initialization of buffer addresses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's postpone this. #862 created.
@JehandadKhan #795 merged in. Please make necessary changes right in this PR to resolve #795 (comment). If you do not have time, please ask me and I will do that. @jerryyin Plase let us know if any objections. |
@jerryyin Merge conflicts. Please let me know if you need help. |
@atamazov I have updated the branch. |
* Fix find_permutation * Misc fixes
One step to the approval left: #841 (comment) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This PR enables the back-to-back execution of mlir binary backend fwd kernels.
I did the following in this PR:
.mlir
extension for binary backend compilation.mlir-cpp
and.mlir
extension are handledmemref.hpp
header from a subset of llvm source, refer to herePlease note: CI in full pass with initial commit 5ea65fb.
Also this is a follow-up from @atamazov 's review in this commit.
Update: MLIR repository has a breaking change in group convolution support. Because of that, I wouldn't be able to address any MLIR end concerns without adding the new feature. Therefore I will work in the following sequence:
StridedMemRef