areusch commented on a change in pull request #7823:
URL: https://github.com/apache/tvm/pull/7823#discussion_r613651678
##########
File path: python/tvm/driver/tvmc/runner.py
##########
@@ -112,8 +112,10 @@ def drive_run(args):
except IOError as ex:
raise TVMCException("Error loading inputs file: %s" % ex)
- outputs, times = run_module(
- args.FILE,
+ tvmc_package = TVMCPackage(package_path=args.FILE)
Review comment:
well I think this thread was originally about the format produced by
`--output` (@leandron, correct me if I miss something here).
I think it would be to use the metadata and parameter export formats from
model_library_format here. I see three areas of tension with doing this:
1. `codegen` is intended to be an exploded copy of the `.so`, so by adding
the `.so`, it creates some confusion as to what exactly is expected to be here.
it seems like we should be able to accommodate both source and binary forms in
Model Library Format, but it seems like we need to think through things like:
a) how should code consuming this format know whether it should expect a `.so`
or source? b) what is the method by which you build the source in `codegen`
into a binary? in having `codegen` source in Model Library Format, it would
almost seem as if you should be able to build it with e.g. a `make` command.
But if that's so, also having a binary pre-built seems weird without some
additional explanation of what each thing is for, and unit tests that verify
those stories.
2. doing this will expose Model Library Format to a lot more format
revisions (which are different from the breaking change identified by @leandron
here iiuc). Model Library Format revisions would impact downstream codegen
using the microTVM Project API.
3. the one I mentioned, which is that Model Library Format doesn't support
non-DSO-exportable Modules e.g. CUDA, Vulkan, etc.
i'm not sure what our policy is on maintaining `tvmc` output formats. I
think adding more to the output of tvmc makes sense, but we may need to choose
a command-line flag reflective of the format. I think also, perhaps given the
tensions with Model Library Format, we should either
a) implement something a bit different here, so there is no confusion
b) do an RFC to resolve at least issue 1, perhaps we can come to consensus
on a way to place the .so in Model Library Format
maybe since it seems like we should preface this PR with an RFC explaining
the API, option b isn't so bad? wdyt?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
