> 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
I think it would be good to know the pattern matcher has the flexibility to
annotate rather than partition. However, that will be a more significant change
to the overall BYOC flow so the priority first should be just replicating
existing functionality as described in this RFC.
---
[Visit
## [Reminder] First Online Meetup: this Thursday
* Host: OctoML
* Format: Zoom (then recording on Youtube)
* Timezones: US and European friendly (planning to alternate to Asia friendly
for the next one)
* Current registered attendees: 29 (as of May 19)
Just as a reminder, we're going to run ou
[quote="matt-arm, post:13, topic:6727"]
Looking forward slightly, I do wonder whether it will start making sense to
instead of creating composite functions just directly insert the annotations
around the match. This would give us an opportunity to link up ‘composite’
matches with single ops as
[quote="matt-arm, post:13, topic:6727"]
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.
[/quote]
@matt-arm Can you point me at the API? I have something like this inte
Given that the old composite pattern is not yet part of a release, it might
easier to directly migrate to the new one so that we don't have to maintain two
variants of pattern languages in the spirit of reducing techinical debts.
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-use-patter
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
Thanks for this RFC Cody! I fully agree this pass should be re-implemented
using the pattern language, the logic was very much a stop-gap solution until
more powerful pattern matching appeared.
Do you envisage this having a similar API to the existing pass? In particular
it's important for us
[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
@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)
We'd still need something like this:
`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.`
But it would be analyzing strings instead of graphs.
---
[Visit
T
While I wasn't paying attention to the discussion, I implemented Cody's
original ask here:
https://github.com/apache/incubator-tvm/pull/5627
@masahi, what do you think of stringing together the types of all of the
nodes/names of all of the called ops in the partitioned function, in
topologic
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
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
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
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
The currently implementation wont, thinking over it more, but I'll work on an
update that adds that functionality and a user-specified set of attributes
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-use-pattern-language-to-create-composite-functions/6727/4)
to respond.
You are receivin
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
I'd be happy to extend the parition pass to accept an optional map of
attributes. I think it's a relatively small change to the pass, if you guys
think that would be the easiest option.
Something I thought of over the last few days: If some patterns in your list
are larger (say conv-bias-relu
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
@comaniac
I printed the mod value after partition. It is coming correctly. I found the
problem with my setup. The issue has been solved now.
---
[Visit
Topic](https://discuss.tvm.ai/t/seeing-many-input-placeholders-in-graph-json-using-byoc/6708/3)
to respond.
You are receiving this beca
Hello,
I am working at ST Microelectronics and am evaluating the TVM technology in our
environment.
I have noticed that in TVM 0.6 version the per-axis .tflite quantized models,
such as generated by TensorflowLite, are not supported. Is anybody working on
adding the support for such models. Ho
@comaniac No problem at all. This discussion is very relevant to the Ethos-N
integration.
I touched base with everyone here and I don't think there are concerns for us
at this point other than the ones discussed.
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-ethosn-arm-ethos-n-integratio
23 matches
Mail list logo
