We discussed this a bit offline; posting some brief outcomes of that call here and some additional response I had from before.
[quote="MJKlaiber, post:4, topic:12039"] Let’me give you a pain points why we think changes in the codegen should be possible for the standard developer: Adding an include statement like `#include "accelerator_a_lib.h"` to the target code requires to change **codegen_c.cc** and recompile (at least that a solution we are aware of). There are more cases like this, and we think that a Python interface is required. [/quote] Agreed the Python interface is better. Does attaching [pragma `"import_c"`](https://github.com/apache/tvm/blob/main/python/tvm/topi/arm_cpu/mprofile/dsp/conv2d.py#L1840) work for your use case? There is also [this RFC](https://discuss.tvm.apache.org/t/tvm-capturing-dependent-libraries-of-code-generated-tir-initially-for-use-in-model-library-format/11080) about tracking lib dependencies properly. [quote="MJKlaiber, post:4, topic:12039"] We are under the impression that there is no “standard flow” for accelerator. [/quote] Yeah I agree there isn't a standard set of steps to take when integrating an accelerator. Here I'm referring more to the set of steps taken by `tvm.relay.build` when an accelerator or library is offloaded. We discussed this a bit offline and overall we agree that there is a desire to unify the "plumbing" part of the pipeline (e.g. ensure that UMA's interface interacts with the standard `tvm.relay.build` flow using widely-used APIs. Here are the pieces we discussed: - Partitioning: UMA is using the standard TVM partitioner, registering patterns using the pattern-table infrastructure, and invoking the same 3 passes used elsewhere to partition. This is a reuse of existing infrastructure so no further discussion is needed here. Should UMA choose to use any different partitioning scheme, we would need to ensure we are agreed on how it marks the end result of partitioning on the IRModule (e.g. which attribute and how does that correspond to target, etc). - Codegen: UMA would like to provide a wrapper class which affords users the ability to implement a [TIR-to-runtime Hook](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0010-target-registered-compiler-flow-customisation.md#relay-to-runtime-hook) (NOTE: RFC'd but not yet landed in the codebase cc @Mousius) for their target. @MJKlaiber let me know if this is not correct, but I think the overlap is pretty close to my understanding here. - Scheduling and post-scheduling passes: UMA would like to allow users to register custom passes and enable them based on some conditions. The exact conditions are yet to be discussed. We've discussed adding flexibility to do this based on the presence of a particular Target, but it would be great to spell this out here. Additionally, we need to discuss the points in the compilation flow where these passes should be run. These last two bits are a bit complex and may be better discussed in a high-bandwidth setting. I'll organize a community meeting so we can discuss them in an open forum sometime in the next few weeks. --- [Visit Topic](https://discuss.tvm.apache.org/t/rfc-uma-universal-modular-accelerator-interface/12039/6) to respond. You are receiving this because you enabled mailing list mode. To unsubscribe from these emails, [click here](https://discuss.tvm.apache.org/email/unsubscribe/491cf439dc8b222562771ed60b1e64ec89e395ad70e283f60551fffe379d0d64).
