The Apache TVM community is happy to announce the release of TVM v0.10.0.
The TVM community has worked since the v0.10.0 release to deliver many
exciting features and improvements.
- Metaschedule
- Software pipelining and padding for irregular shapes for auto
tensorization
-
Thank you for sharing your thoughts, @areusch. I think it might be helpful for
better discussion if you can clarify a little further especially about your
main concern (2nd one). Particularly, I want to hear more about your thoughts
on the following things:
1. Are you suggesting the consensus is
these two volunteered to help triage issues per [Issue Triage
RFC](https://github.com/apache/tvm-rfcs/blob/main/rfcs/0093_Issue_Triage.md).
@tqchen @driazati
You can view, comment on, or merge this pull request online at:
https://github.com/apache/tvm/pull/13141
-- Commit Summary --
* [sk
Thanks for contributing to TVM! Please refer to the contributing guidelines
https://tvm.apache.org/docs/contribute/ for useful information and tips. Please
request code reviews from
[Reviewers](https://github.com/apache/incubator-tvm/blob/master/CONTRIBUTORS.md#reviewers)
by @-ing them in a c
Merged #13141 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/13141#event-7625211200
You are receiving this because you are subscribed to this thread.
Message ID:
I wonder about a situation where some parties indicate up front that they are
resolutely opposed to ever permitting an S0 module to become S1. Even if this
process permits the module to be merged as S0, it would essentially be known in
advance that it is unlikely ever to be fully integrated into
thanks for the replies here, everyone.
@comaniac
>-1 is totally fine and I don't think this Process RFC forbids this. On the
>other hand, if an RFC is suspensive for a while but we still cannot make every
>-1 voter happy, it doesn't make sense to me to reject the RFC (we don't
>actually "reje
