# **Summary**
Thanks everyone for valuable discussions. Here is a summary to conclude all the
comments, and we will follow it to file PRs.
- We will create a separate composite target macro as follows:
```c
TVM_REGISTER_TARGET_KIND("composite")
.add_attr_option("target_host")
.add_attr_
Thanks for the suggestion. "devices" sounds good to me.
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-composite-target/7744/7) 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
[quote="tqchen, post:3, topic:7744, full:true"]
I agree P2 is better. However, we need to be mindful that the composite can go
beyond single accelerator settings. For example, we might also want to compose
`arm_cl` and opencl on ARM GPU
[/quote]
Since `accelerators` is an array, we can specify
This is a follow-up RFC from
https://discuss.tvm.ai/t/rfc-tvm-target-specification/6844
This RFC is discussed with @junrushao1994.
In this RFC, we propose the way to represent a composite target. The motivation
is that now we have multiple codegens contributed by the community members via
BY
Also cc @zhiics for comments.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-savetofile-file-name-format-expected-behavior/7741/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/unsubs
@matt-arm For each BYOC backend such as DNNL, we could define a transform
sequence so that we can have `mod = transform.partition("dnnl")(mod)`. However,
there are some issues should be further discussed. For example, where should we
put those transform sequences (e.g., put them under `tvm.tr
Gentle ping for comments @anijain2305, @masahi, @matt-arm, @tqchen :)
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/4)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss
@anwang Ansor also has a "task" concept. A task is not necessary to be just for
one operator. It just means a "tuning" task. As a result, I still vote for task.
In addition, I don't think full enumeration is proper for several reasons.
1. Full enumeration will lose the flexibility when adding
General Comments
IMHO, @merrymercy's comments on log files are valuable. Many users now look
into the log file for the information they need, and even manually modify some
logs for experiments or optimizations. This can be achieved because 1) the log
files are in text format, and 2) one c
Also cc @JoeyChou @abergeron
---
[Visit Topic](https://discuss.tvm.ai/t/rfc-byoc-data-calibration-flow/7099/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/e825d1e5ca1d063
We don't have vim plugin for FFI navigator now, but you are welcome to
contribute one :slight_smile:
---
[Visit
Topic](https://discuss.tvm.ai/t/language-server-tool-to-navigate-across-packedfunc-ffi-for-ides-like-vscode-and-emacs/5226/28)
to respond.
You are receiving this because you en
Please also refer to this topic that moves AutoTVM log version to 0.2. Some
issues have been discussed there:
https://discuss.tvm.ai/t/autotvm-log-format/5630
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-canonicalizing-autotvm-log-format/7038/5)
to respond.
You are receiving this beca
Good point. We (AWS) have a plan towarding to this direction in this summer.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-ansor-an-auto-scheduler-for-tvm-autotvm-v2-0/7005/18)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [c
I agree. As long as we can demonstrate that Ansor customized rules can fully
cover the current AutoTVM templates in terms of the semantic and performance,
we can deprecate AutoTVM. While we are working to achieve this goal, we will
definitely have a period of time to keep both solutions.
Ah I see. That makes sense. Then how about putting it to config.cmake to be
something like `SET(STRICT_MODE ON)`?
---
[Visit
Topic](https://discuss.tvm.ai/t/discuss-the-meaning-of-float-in-relay/6949/16)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubs
Is the `TVM_STRICT_MODE` fails the CI if throw warnings? It looks not
sustainable to me because this is not in a normal logging system so people can
easily forget it.
My understanding about how to determine the log messages is that if we hope to
show them to end-users, then we should use INFO
Agree to make `float32` as the default and throw a warning if `float` is given
without specifying the bit number. On the other hand, simply putting the
warning at a lower level may not be effective. I believe most users do not
change the log level during the development. I would prefer the way
Per offline discussions, here is a summary of the updated proposal:
* The original proposal uses a runtime module to maintain both json and
metadata (e.g., constant weights) together. As @tqchen pointed out, although
this is simple to be implemented, it is hard to debug and cannot be shared ov
Thanks for the RFC. Some comments and questions:
- While I agree that the JSON encoding is powerful to cover all possibilities,
I am a bit confusing about the usage from a user's perspective. Are we
expecting users to write a separate JSON file like `target.json` and use `tgt =
tvm.target.cre
PR filed
https://github.com/apache/incubator-tvm/pull/5689
---
[Visit Topic](https://discuss.tvm.ai/t/patternlang-match-constant-nodes/6835/6)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/
Thanks for the pointer! So I'll open a PR this afternoon including the
following:
- Add ConstantPattern
- Add descriptions to the doc about how to match constant with or without a
specific value.
- Add description to the doc about welcome to raise an issue or open PRs to add
more pattern node
Update: For **A.2**, I've made a POC here:
https://github.com/comaniac/tvm/tree/add_const_to_pattern
With the POC, we can match the following pattern:
```python
conv2d = is_op('nn.conv2d')(wildcard(), ConstantPattern())
pattern = is_op('nn.bias_add')(conv2d, wildcard())
```
---
[Visit Top
Based on the offline discussion with @matt-arm, users may have a requirment to
match a pattern with constant nodes. For example, we may have a conv2d op with
two arguments.
```
%0 = nn.conv2d(%x, %w)
```
After we bind the second argument with constants, it becomes:
```
%0 = nn.conv2d(%x, me
New `MergeComposite` pass PR filed.
https://github.com/apache/incubator-tvm/pull/5656
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-use-pattern-language-to-create-composite-functions/6727/29)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from
Updated the gist with merged features (configurable partition function
attributes; pattern with more powerful attributes).
Once the last feature (partition callback) is in, we should be fine to rewrite
`MergeComposite` pass without any loss.
https://gist.github.com/comaniac/1f399dfdfee05a2f7a
@mbrookhart this sounds great!
Then I can use the second method to implement `MergeComposite` to allow
optional check functions as it currently does. Meanwhile, if a user's pattern
only needs to check attributes and shapes, the user can use the first method to
specify the pattern.
---
[V
I was mainly referring to this case
https://github.com/apache/incubator-tvm/pull/5637/files#diff-f9920485e5e341787129348ce1985db9R247-R251
and it does achieve the same functionality as the current `check` functions in
`MergeComposite` pass in my opinion.
In terms of ease-of-use, to me this pr
Thanks for the comments. Here are a short summary of supporting `check` using
pattern language based on my POC
(https://gist.github.com/comaniac/1f399dfdfee05a2f7a087c65c21f550c):
A. Callback
The `check` logic is used in callbacks to determine if this subgraph really
matches the pattern.
> Do you envisage this having a similar API to the existing pass? In particular
> it’s important for us to retain the added ‘check’ function to confirm whether
> a match is valid.
Good point. We need to evaluate if the check function can be fully integrated
into the pattern language.
@mbrook
@mbrookhart the PR is exactly I'm expecting!
I am also fine with the tags in a pattern. In this case, we can keep the infra
simple and transparent tag analysis to external codegens.
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-use-pattern-language-to-create-composite-functions/6727/11)
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 function with `fused_conv` attribute.
O
Pattern language infra works based on a pattern, so we will know which subgraph
is matched by which pattern.
For example, when we use `graph = pattern.partition(graph)`, the new
partitioned functions are based on the pattern. As long as we add the composite
attribute with this pattern's name
Thanks for pointing out. I missed this part in the original post. Currently
`MergeComposite` pass doesn't deal with the overlapping issue but let users
decide the pattern priority. It means that when performing pattern matching, it
should ignore existing composite functions. Is this functional
Since the pattern language has been merged, we are planning to rewrite
`MergeComposite` pass for BYOC with it.
## Brief Introduction to Merge Composite Pass
BYOC is designed to help 3rd party codegen and accelerators integrate into TVM.
Since 3rd party accelerator may have a specialized and p
Considering the weight of every layer will be an individual input, it might be
fine.
Could you print out the graph after the partition pass? For example:
```
print(mod)
mod = relay.transform.AnnotateTarget("external_compiler")(mod)
mod = relay.transform.MergeCompilerRegions()(mod)
mod = relay.t
@manupa-arm that's the ultimate goal to solve 2 problems currently the merge
composite pass facing:
1. As you pointed out, the current approach to specify the composite pattern
requires users to make lots of similar patterns. This problem was reported by
@masahi and @jonso if I remember corre
@Leo-arm thanks for the response.
> We mostly use pattern tables now but it depends. Why the question?
Just out of curious because we are planning to rewrite the composite pass using
the recent merged pattern language. I'm considering that if your flow only
leverages composite functions, then
Thanks for the RFC. While I'm also interested in the questions @zhiics raised,
I have a few more questions:
1. It seems like the major annotation process would be done by composite
functions. Will your flow use patterns to form composite functions only? Or you
will still have a list of suppor
Thanks for the explanation. I have a further question based on your example.
If I understand correctly, this example works for a scenario that a customized
codegen will generate metadata and kernel code. The kernel code here may
include external library APIs or graph execution engine that inte
Our concerns to put the supported operators in each codegen are readability and
maintenance. If we skip the central extern op module definition, we will need
every extern op function to use decorator, similar to the current TOPI
implementation:
```
@reg.register_extern_op("nn.conv2d", "gcc")
Here is a simple test with Relay function:
copy_out2 = deepcopy(out2)
copy_out2.args = new_args
f = relay.Function(new_args, copy_out2)
print(f)
But it seems not working either:
v0.0.4
fn (%new_data: Tensor[(1, 3, 224, 224), float32], %new_weights: Tensor[(32,
32, 1, 1
41 matches
Mail list logo
