You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we continue optimizing the performance and stability for igemmGen and this tool can generate more efficient kernels for igemm or direct conv, we may think about how to merge new asm files to miopen frequently. I think we can have a discussion here.
I could make some proposals here:
There is no obvious conflict between the two approaches, IMHO.
We could mimic the MIOpen staging approach:
Establish a branch within MIOpen repo, e.g. iGEMM-develop;
Automatically merge most recent ASM kernels generated by this tool to the above branch;
TUNA should keep track of the branch's performance data in its database, and when the "staging" performance is good, merge it to MIOpen develop branch.
Well, we really need the performance tuning and monitoring automation tool (TUNA) to be deployed. i.e. our performance CI 😀
CC: @JehandadKhan@atamazov
@carlushuang I am not against "non-standard" usage of the preprocessor. However this requires careful and clean design. Please explicitly ask me to review relevant PRs.
As we continue optimizing the performance and stability for igemmGen and this tool can generate more efficient kernels for igemm or direct conv, we may think about how to merge new asm files to miopen frequently. I think we can have a discussion here.
I could make some proposals here:
The text was updated successfully, but these errors were encountered: