This makes sense to me.
I'm curious to see how `calib_data` is going to be used during codegen.
Assuming you want to upstream this pass, how are you going to add tests for
this? I can imagine you can use the DNNL codegen to run a dummy calibration
pass, but not quantize.
---
[Visit Topi
One use case I have for a visualizer is to visualize the partitioning output in
BYOC flow. Right now I'd check the output by eye-balling the text rep, but I
wish there could be easier way than that.
It would be great if I could visualize the entire graph, with partitioned
functions color cod
Also looking forward to seeing performance on quantized models and comparison
against TFLite, FBGEMM and MKLDNN.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-ansor-an-auto-scheduler-for-tvm-autotvm-v2-0/7005/5)
to respond.
You are receiving this because you enabled mailing list mode.
Sure that sounds good. Since params are referenced by its numeric node id in
Torch IR and we line-by-line translate, we still need association of numeric ID
-> state_dict key name.
state_dict key name is available here as "full_attr" so you can use this name
when creating Var.
https://github
@yzhliu I see there are some PyTorch related fix, but the PyTorch frontend was
not part of v0.6 release.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-minor-bugfix-release-for-v0-6/6716/7) to
respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from th
For per-channel weight quantization, it is fully supported. I don't know much
about TFLite frontend, but our pytorch frontend fully supports per channel
quantization.
This tutorial demonstrate importing per-channel quantized pytorch model.
https://docs.tvm.ai/tutorials/frontend/deploy_prequa
We should have a utility that converts existing relay op based patterns to the
new pattern language. Otherwise it would break existing users code and we need
to rewrite merge composite test cases manually.
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-use-pattern-language-to-create-comp
[quote="comaniac, post:8, topic:6727"]
I see your point, although I personally think in this case we should either 1)
specify 4 patterns, or 2) use pattern language to match `fused_conv` , and let
codegen decide whether it is conv+bias or conv+bias+relu when the codegen is
parsing a composite
No, it is more complicated than that.
Currently our DNNL backends has two patterns, one for conv + relu and another
for conv + bias + relu:
https://github.com/apache/incubator-tvm/blob/master/python/tvm/relay/op/contrib/dnnl.py#L84-L86
Suppose we use optional to represent the two patterns. We
One thing that's not obvious to me is how we should interprete the result of
optional matching. Ideally there should be an easy way to tell which of
optionals are actually matched, for example by coming up with an appropriate
value for composite attribute.
Otherwise each backend needs to man
[quote="mbrookhart, post:24, topic:5833"]
V2 will include graph partitioning and verification to better support bring
your own code gen, starting in on those passes now.
[/quote]
I'm very interested in this. Using composite, I have to generate many slightly
different patterns (`with_bias`, `wit
I'm interested in this topic. Having worked on frontend stuff for some time,
now I'm looking to revive my backend-fu :) Also I wanted to learn about
graphics API, this seems a good opportunity.
I also hope that
`WebGPU + WASM = win`
Although GPU support in WASM doesn't seem official yet.
[q
[quote="zhiics, post:15, topic:6334"]
I have another thought on this, how about just put this one in the
backend/utils.h since the current usage of them would be for the code under
there?
[/quote]
Yes, that's where I'd put this class in, given the current usage of
`ExprFunctor`.
[quote="tqc
Since the new base class would be as simple as the one below, I don't think
there is much of abstraction cost. I don't see why we should prefer duplicating
the same `VisitExpr(const Expr& n)` over this solution.
```
template
class MemoizedExprFunctor : public ::tvm::relay::ExprFunctor {
usi
[quote="tqchen, post:6, topic:6334"]
That dispatching logic ca certainly be simplified as a one-liner, which will
reduce the memo logic addition to be about 10 loc
[/quote]
Yes, the point is each derived class ends up having the exact same 10 loc.
Until now we have 2 or 3 cases so that might b
[quote="tqchen, post:4, topic:6334"]
The addtional cost for memo is not taking a lot of locs
[/quote]
Note that in addition to the memo logic itself, we can also remove
`VisitExpr(const Expr& expr)` override in the derived classes (which to me
seems only exist for memoization), and hence the d
hmm, then does it make sense to have a another derived class, say
`MemoizedExprFunctor`, that does have a memo logic built in, for a simple use
case in derived classes that requires memoization? The PR I saw today could
derive from this instead of ExprFunctor, for example.
Basically for encap
Currently I'm about to merge a PR
https://github.com/apache/incubator-tvm/pull/5310 which adds memoization logic
for `ExprFunctor` in two different derived classes.
I've also noticed that there are many places in the code base that have the
same duplicated memoization logic for `ExprFunctor`
Yes https://github.com/apache/incubator-tvm/pull/5293
---
[Visit Topic](https://discuss.tvm.ai/t/spurious-ci-failures/6312/2) to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsubscribe/8
There was a related issue https://github.com/apache/incubator-tvm/issues/1732
that resulted in the introduction of .clang-format file. But we didn't do
anything else to improve consistency of existing code or enforce the style for
future code.
---
[Visit
Topic](https://discuss.tvm.ai/t/c
[quote="ANSHUMAN.TRIPATHY, post:8, topic:6129"]
But don’t you think the **“out of scope from TVM”** is applicable for all
frontends. As all frontends first need to beakdown the model received and put
all the pieces together to in terms of TVM.
[/quote]
No. For example, both Torchscript and ONNX
Your proposal is reasonable from perspective of existing Chainer users looking
for deployment solution. However, I see little benefit from TVM side.
First of all, compared to other framework like PyTorch, the number of Chainer
user had been very tiny even during Chainer was in active developme
I realized that `output_index_map` is completely redundant if we make `outputs`
a dict instead of a list. Because `outputs` is always accessed via
`output_index_map` like this, (here, outputs is a list)
```
outputs[output_index_map[var_name]]
```
instead it should be just `outputs[var_name]`.
[quote="jjohnson-arm, post:12, topic:6055"]
Is that right?
[/quote]
Yes, exactly right.
[quote="jjohnson-arm, post:13, topic:6055"]
I am wondering if it would be possible just to append some conversion entries
to the `output_map_index` instead and it would achieve the same thing?
[/quote]
I
Oh you are right... I also realized that in a typical AOT deploy use case, we
just load compiled models directly from exported libs, so there is no
torchscript or relay models. But users still need to keep input names around
somehow.
I agree that an ideal solution is for compiled runtime modu
@jjohnson-arm Do you want to send a PR about it? Otherwise I will, no problem
---
[Visit
Topic](https://discuss.tvm.ai/t/pytorch-frontend-graph-input-names-can-change-using-loaded-torchscript/6055/8)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe
No it is not strange, it is expected. `module.run()` is async-ish, to be sure
you can insert explicit sync after `run()`
---
[Visit
Topic](https://discuss.tvm.ai/t/ndarray-conversion-to-numpy-array-take-time-around-350ms-with-a-simple-data/6053/6)
to respond.
You are receiving this becau
PyTorch users should know the correct order of inputs, because PyTorch modules
`forward(...)` method expects its inputs to be in the correct order (otherwise
they cannot run any training code).
[quote="zhiics, post:5, topic:6055"]
And it is possible to connect the names after _run_jin_passes?
It is likely the inference hasn't been finished when you call `asnumpy()`. That
is why `asnumpy` takes some time to complete.
---
[Visit
Topic](https://discuss.tvm.ai/t/ndarray-conversion-to-numpy-array-take-time-around-350ms-with-a-simple-data/6053/4)
to respond.
You are receiving this
yes, we can repurpose and rename `_check_input_names` to do necessary input
validation.
For other frontends, I also remember being annoyed for having to supply input
names. Unfortunately for them it is too late to fix. We shouldn't repeat the
same mistake :wink:
---
[Visit
Topic](https:
Thanks, it seems to me the best to way to fix this issue is not to require
users to supply the correct input names, since this is an impl detail of torch
and we can figure out the names in `from_pytorch`.
Instead, users should just supply a list of input shapes in correct order. We
call `get
31 matches
Mail list logo
