ROCmSoftwarePlatform
Incorporate fin into MIOpen
Add fin source into MIOpen. Allows build checks in consistent environment. Removes circular repo dependency. Updates to Jenkinsfile to add and cleanup fin tests.
The ratio .cpp/.cmake less than 1 :smile:. Do we really need a complete copy of all files from cmake directory?
The ratio
.cpp/.cmakeless than 1 😄. Do we really need a complete copy of all files fromcmakedirectory?
The eventual goal would be to integrate with MIOpen's cmake, at which point these could be deleted. For now this accomplishes the goal of keeping the build environments in sync.
@cderb @JehandadKhan @averinevg it may have value to let FIN remain a separate submodule. Let's settle on the design Pros and Cons before we proceed.
@junliume @cderb @JehandadKhan @averinevg There is a requirement for MIOpen to be able to provide some extended information to Tuna, and be able to be controlled by Tuna with some extended ways. "Extended" in this context means that the level of interaction is much deeper than normal MIOpen clients require. Therefore, the required API is not a part of the public API of the library. Unfortunately, the interface wasn't designed carefully prior implementation (likely the justification is "due to a lack of time", as usual). Nevertheless that's what we have right now: fin provides the ability of Tuna to interact with MIOpen. In other words, it implements a mandatory feature of the library and I do not see why it should reside in some external repository.
[Side note] I had exactly the same opinion when fin was separated from the library into a separate project, because I expected difficulties in maintenance. However, at that time I was too busy with my current stuff and had neither time nor energy for debates.
@junliume @cderb @JehandadKhan @averinevg [Side note] My view on the future development of finа is like this: As many as possible of the features currently implemented in fin for Tuna should be moved to a library and made available through a private API. This, of course, may require some modifications in the Tuna. Ideally, fin should be an executable wrapper of the library, a kind of "driver" for Tuna; and if (when) Tuna can directly interact with the library, then fin can be removed altogether. As usual, this can be done gradually, step by step.
I completely agree that at first it is necessary to declare some interface that will use 'FIN' to access the internal elements of MIOpen.
- Pros of using MIOpen element directly: FIN can experiment with data without wasting time on requests to change/add the interface. It's good for a startup when you don't know what data you will need and what you can give up, you don't have to wait for approval from the library.
- Cons: since there is no clear understanding of what data is used and what format is expected, the library may suddenly change them, which will negatively affect interproject interaction. And the longer such interaction takes place, the more often it will happen. As a result of this design, developers on both sides will need to study changes in the structure of another project to push PR through CI, which increases the time required to complete PR, and even worse, this will become clear only at the very last moment, after merging changes related to interaction.
Since FIN has existed as a full-fledged project for quite a long time, it is reasonable to develop an interface and maintain it at the library architecture level, which will allow architects to make a schedule for changes and solve the problem with sudden interaction errors. This will also reduce the burden on other developers, since they will not have to get into the details of the functioning of another object, they only need to maintain compatibility with the interface.
After that, we can already think about whether we need to combine the MIOpen and FIN code.
- From the users' perspective, FIN is not required to build and run MIOpen on their hardware.
- On the other hand, MIOpenDriver is also not required for these purposes, but it is located inside our repository. But it is mainly used as a tool to reproduce interface errors or a standardized way of measuring performance.
Maybe better to merge FIN in Tuna project? Because FIN code expands only if Tuna wants to change its coverage, not because MIOpen added a new solver. There are many solvers in MIOpen that are not tunable and are never used via FIN, but each of them can be executed through the MIOpenDriver.
As an example, MIOpen uses the rocBLAS interface, but we don't ask rocBLAS to store in their repository a solver-class that is used to interact with this interface .
