I would sort of like to keep the sort-by-target structure proposed. I don't
think it affects anything for the time being, and it would be a good discussion
to have as to how to identify `runtime.Module`. They are fairly opaque now.
I think the part that's unanswered for me is whether anyone would want to
generate configuration from within the BYOC compiler step and then generate
actual device code after exporting to Model Library Format. The advantage of
this is that the output from the TVM memory planner is available after export.
I think it largely depends on what the memory planner can offer, but we haven't
settled that yet, and even so it may change over time or differ per-target.
> I think only exception for this usecase is where we would have an packed
> function directly stored in an accelerator memory space that can support
> execution of standard procedure calls in its own binary format. Do you have a
> such a usecase in mind ?
I'm not so much thinking about this as that if generating some type of code to
drive an accelerator, addresses of pinned tensors may be a part of such code.
It's possible that an accelerator compiler may even be a separate invocation of
gcc with different flags, linker script, etc. It may in general be easier to
drive this from the Project rather than from a BYOC callback.
>I think in the world of micro, both of these should be invoked in the
>target_host via Driver/Runtime API component.
I agree. I think BYOC should expect to generate PackedFunc that invoked from
the runtime to launch the compute. The context will be likely not CPU e.g.
`DLContext{ext_dev, 0}`. In the future, we need to make some consideration for
concurrent execution, but that would likely come in the form of some kind of
continuation PF and not affect the way things are launched.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-tvm-model-library-format/9121/5) 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/56e4aa126c277d06c45028411940f2463602f97726929980b3d559d2de17b2fb).
