>From what I know now, it looks like TVM doesn't take the
>`onnx_model.graph.initializer` into account when creating a list of inputs
>like above.
---
[Visit
Topic](https://discuss.tvm.ai/t/relay-onnx-keyerror-w-when-compiling-from-onnx/2102/2)
to respond.
You are receiving this because
RE: Node hierarchy. One ultimate direction is to use a DSL(for example python
with typing info) as a way of declaring the node relations and fields and
create generator util to generate the classes. The main challenge is to keep
most of the data structures purely in C(so we can get ABI compatibi
+1
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2973#issuecomment-480669435
> The main question is the naming convention to make sure we are not confusing
> the users.
Yeah I didn't put any thought into these, would welcome suggestions. Could do
something like `set_body_to_function_pointer` / `set_body_to_method_pointer`,
although those are a bit verbose.
--
You are
+1
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2973#issuecomment-480660138
+1
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2973#issuecomment-480658092
@tqchen, yeah those are good points. One possibility would be to use
hand-written languages for first-tier-supported languages like python and offer
the auto-generated wrappers for other languages.
If you did end up switching fully to auto-generated wrappers you could take
steps like committing
>From other thread:
@tqchen:
> I will summarize some of my take here. I like the idea of Node hierarchy
> compile time generation. This is something I have thought about and discussed
> with @jroesch for a while and might help [#2523
> (comment)](https://github.com/dmlc/tvm/issues/2523#issuecom
One thing I would like to mention is that manual wrapping has its merit :)
Take the following wrapper code for scan as an example. By manually wrapping it
in python, we can benefit from:
- A clear signature that users can look up
- Keyword argument and default value
- Python-specific documents, i
(Moved from #2981)
Proposal: add type signature metadata to PackedFunc
Each `PackedFunc` would have an optional field describing what arguments it
takes and what type it returns. This field would be automatically populated
during conversion from a `TypedPackedFunc`.
Once we have these type si
This idea actually comes a lot :P
https://github.com/dmlc/tvm/pull/2328#issuecomment-450001679
I know, for sure, that we could get good docs with _really good_ codegen like
that offered by Rust macros, but I also know for sure that we're not about to
rewrite TVM in Rust :)
I think that the boi
Thanks for the contribution, I like the automated detection of the signatures.
The main question is the naming convention to make sure we are not confusing
the users. Let us open a new issue about other parts of RFC.
I will summarize some of my take here(which can be moved to the RFC). I like
cc @nhynes @tqchen
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/pull/2981#issuecomment-480622604
This PR converts a good chunk of TVM's global `PackedFunc`s to be
`TypedPackedFunc`s. Right now, this shouldn't actually change any behavior,
since the type information is immediately discarded once the functions are
registered in the `Registry`.
It does make things a lot shorter, using a few
+1
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2973#issuecomment-480616095
In my vision, there could be a vendor-neutral library that implements higher
level MLIR dialect operators in lower (algebraic) level. There could be a
graph optimizer, a tensor optimizer and a traditional compiler optimizer.
Graph optimizer does higher level graph optimizations like fusion
+1
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/dmlc/tvm/issues/2973#issuecomment-480550080
17 matches
Mail list logo
