Thanks everyone for discussions so far. There are a lot of conversations around
the clarifications and issues being answered. Two of the main concern being
raised so far seems to be:
- rationales and alternatives.
- overall scope and execution
In this case, @YuchenJin have:
- Updated the RFC w
Thanks @YuchenJin for updating this RFC!
>From the use-cases that I have observed in my experience, the symbolic shape
>capabilities allows TVM to handle dynamic workloads that cannot be handled in
>other frameworks and get more widely adopted. And we can quickly enable
>iterations of unity co
Based on our experience at NIO, dynamic shape support in Relax is **extremely**
important for us. In fact, we have done many things on Relay trying to cover
dynamic shape support on our user cases, however lack of first class support
for symbolic dynamic shape still constraint us some ops / patt
+1 (binding)
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/12651#issuecomment-1266327470
You are receiving this because you commented.
Message ID:
In addition to the use cases and experience I've mentioned previously, I want
to further highlight that symbolic shape support becomes even more important in
these months, mainly due to the requirements of deploying decoder models (e.g.,
GPT). Since the text generation process is a natural dynam
### adreno
* #12537, #12286, #11878
### aot
* #12550, #12182, #11876
### autotvm
* #12685, #12521
### byoc
* #12353, #12320, #12151, #12105, #12086, #12078, #11993, #11981, #12006,
#12002, #11822, #11979, #11770
### ci / testing
* #12778, #12695, #12773, #12534, #12663, #12473, #12361, #1
