Closed #57.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/57#event-16780441908
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/16368#issuecomment-1882320646
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/15521#issuecomment-1673511370
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/102#issuecomment-1664957730
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/12651#issuecomment-1581123455
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
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/12651#issuecomment-1234673189
You are receiving this because you commented.
Message ID:
Thanks fo the RFC. Although I didn't involve the actual Relax development, I've
been attended the weekly open design review meeting for a while and I'm glad
that I could share our experience to help improve the Relax design. Thus, I
don't have specific questions to the design.
Regarding to the
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/12103#issuecomment-1187912759
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks all for your valuable comments and insightful discussions. This RFC is
now merged.
@ArmageddonKnight please open a tracking issue in the main TVM repo to start
tracking the progress. Thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#
Merged #72 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#event-6713028207
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/11415#issuecomment-1138929632
You are receiving this because you are subscribed to this thread.
Message ID:
@ArmageddonKnight we might present/demo DietCode and introduce this RFC in a
community meeting. Maybe in 5/25 or 6/1?
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#issuecomment-1130262561
You are receiving this because you are subscribed to this
As one of the co-authors, it glad to see this RFC finally out :)
cc @masahi @ZihengJiang @Laurawly @Hzfengsy @MasterJH5574 @jinhongyii please
help review and share your thoughts. Thanks.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/72#issuecomment
+1
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/10471#issuecomment-1058730515
You are receiving this because you are subscribed to this thread.
Message ID:
Thanks for the RFC. Will review next week.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/57#issuecomment-1045334149
You are receiving this because you are subscribed to this thread.
Message ID:
> @comaniac I'm starting to implement the first PR "Add libxsmm to TVM CI"
> recently. I wonder if there is any CI-related PR I can refer to?
You could refer to the PR like https://github.com/apache/tvm/pull/9881 or
something similar.
--
Reply to this email directly or view it on GitHub:
https
Thanks for the RFC. Would you please file a formal RFC here:
https://github.com/apache/tvm-rfcs along with the upstream plan? For example,
you have some TODOs in this PR, so it would be good to have a formal RFC and
tracking issue for the progress.
--
Reply to this email directly or view it on
Thanks @zhuwenxi this is now merged.
Also please file a follow-up PR to add the RFC information (start date, RFC PR
and RFC tracking issue). You can refer to other merged RFCs for details.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/47#issuecomme
Merged #47 into main.
--
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/47#event-5814329812
You are receiving this because you are subscribed to this thread.
Message ID:
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/9504#issuecomment-969154659
> @comaniac , thanks for the follow up, just saw this comments, already done.
Could you update the issue with a complete plan (e.g., milestones, expected
PRs) instead of adding one line when filing a PR? Otherwise people won't have
an idea about how many PRs you are going to send and what milest
For the proposed BYOC flow (i.e.,
`MergeAndAnnotate`/`AnnotateSEScopes`/`PlanDevices`/`PartitionBySEScope`), it
doesn't clear to me that whether the developer programming model will change or
not. Specifically, could we still use the current approaches (i.e., op-based
annotation and pattern-bas
Thanks @jtuyls, and also @leandron for helping update the CI :)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/8815#issuecomment-934588764
Merged #8815 into main.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/8815#event-5412138922
@huajsj please update this issue with a PR checklist. Please link all future
PRs to this issue for better progress tracking.
You can refer to other RFC issues like #8473
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https:
Agree with @leandron that we could firstly refer to the items there. Many
"initial" features in v0.7 are now stable. For example:
* Initial automatic scheduling support -> stable.
* Initial command line driver interface -> stable.
* Intial Hexagon support -> stable.
* Bring your own codegen (BYOC
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/8928#issuecomment-912831757
Merged #26 into main.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/26#event-5216568281
Thanks @huajsj
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/26#issuecomment-906932927
Thanks @AndrewZhaoLuo
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#issuecomment-904813648
Merged #6 into main.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#event-5201897255
Due to no objection, this RFC is now merged. Thanks @huajsj
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/14#issuecomment-902819997
Merged #14 into main.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/14#event-5187776681
btw, please change the RFC file name to align the PR number (0014).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/14#issuecomment-900566824
Took a quick pass to the updated RFC. I think it's almost ready to merge as
long as the last 3 comments are resolved.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#issuecomment-899
> I think it is a good idea to invite people working on RISC-V support for TVM
> for review/discuss, since the RISC V vector extension is similar to ARM SVE.
> I remember some people in Taiwan are working on this. Maybe @comaniac knows
> who?
Thanks for bringing up. cc @yrchen
--
You are rec
btw, according to #17, please update the RFC number on the file name to align
with this PR number.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/6#issuecomment-893007973
> @comaniac the RFC in my mind is mainly a design-level description of some
> aspect of TVM. Like e.g. PEP, they are meant to be consumed by people less
> familiar with the TVM codebase in order to gain familiarity.
>
> the tracking issue, on the other hand, documents the method and progress by
> i don't mind if we have a bunch of closed tracking issues. we can categorize
> them. i agree with @u99127 that maintaining a record is important, and i also
> think it makes sense that the first PR to land on a tracking issue would be
> its RFC. i think committers should be able to notify auth
> Deleting an issue is not something we should do - keeping a record of why
> something was rejected is useful on a later date to know why but perhaps the
> issue of too many issues with the label is solved by a query for open
> rfc-tracking issues ?
>
> Ramana
I think the record would always
> I'd suggest that "nearly done" is ambiguous? As a less ambiguous alternative
> I'd propose always opening a tracking issue (if the RFC is big enough to
> require it) when you raise an RFC and if it ultimately gets rejected we just
> close the issue? This also allows code to evolve alongside th
cc @tqchen @hogepodge @areusch @jroesch
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/13#issuecomment-887681011
Based on the two RFCs I've reviewed, there are two points related to the
RFC tracking issue could be improved IMHO.
1. We currently state that the tracking issue should be opened after the RFC PR
is merged. However, it means the author needs to file another PR to update the
issue link, which se
> > Thanks for the answers. I'll review the PR to get more implementation
> > details.
> > One more question regarding the extensibility: can this be extended easily
> > to support bfloat16?
>
> It should be trivial (hope I don't eat my words). I'm not 100% sure of the
> support for bfloat16 in
Thanks for the answers. I'll review the PR to get more implementation details.
One more question regarding the extensibility: can this be extended easily to
support bfloat16?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
h
Thanks for the RFC. I have two questions:
1. How to mark/set the color (i.e., attribute) of every operator?
2. It seems to me that if we register a casting checker instead of just a label
(color), then we can simplify the algorithm a lot. Taking the case `A(green) -
B(gray) - C(green)` as an exam
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/issues/7991#issuecomment-833728641
I have the same question as masahi. IIUC, after this PR, the PyTorch frontend
has the capablility to convert all unsupported ops to `torchop` so that we can
guarantee the flow would work. This is an interesting idea and this would be
the first BYOC use case that could potentially incopreate two
+1
* Checked the code compiles
* Checked LICENSE and NOTICE
* Checked version.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/6622#issuecomment-704406991
@ZihengJiang both were merged.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/6421#issuecomment-702523318
> @leandron @comaniac @tqchen
> We are still waiting CI for #6597 and #6578 . I have added them into the
> release note and let's merge them tomorrow morning.
Thanks. I am actually waiting to merge them today but still waiting for their
CIs.
--
You are receiving this because you are subscribed
> So, #6537 and #6578 would be the final two PRs to complete the first version
> of `tvmc`.
Per offline discussion with @leandron, the final PR for TVMC would be a simple
tutorial planned to be sent by tomorrow. We will do our best to review and
merge them before Oct 1st.
--
You are receivi
> At this point, we should focus on stablization, so we don't have to rush in
> features like Vitis-AI and TensorRT and can do them in the v0.8 cycle(for
> better stablization). We should instead list PRs that contains necessary
> fixes that need to be inlcuded.
Make sense. Removed them from th
A brief summary of the related PRs missed in the current release note
candidates. Not sure if all of them have to be listed so just for reference.
Except for the note followed by the PR indicating its status, all PRs listed
here are merged.
Automatic Scheduling (Experimental)
* [AutoTVM][Anso
> @comaniac if we land the final error reporting PR it removes the existing
> error reporting from type checker completely, I think we should either choose
> to ship it this release or delay until next release. One worry is that there
> will probably be a period of stability where we iterate/pol
1. Is the error reporting feature included in this release as an experimental
feature or it would be in the next release?
2. For the experimental features, auto_scheduler and uTVM, would that be better
to decorate their entry points with something like `@experiment` so that it
pops a warning to
+1 (non-binding)
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/6332#issuecomment-679424892
+1
Exciting to become an Apache project contributor :D
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/6299#issuecomment-676599145
+1
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/issues/5947#issuecomment-651326848
Polyhedral analysis would be an approach to generate the constraints in this
scenario. On the other hand, the runtime validation sounds not a general
solution, because it might affect the tuner. For example, throwing invalid
configs in `next_batch` would result in no measurement results for thos
@DKXXXL , thanks for the clarification and it seems fair enough to me :)
Then it seems like #4449, #3895 and this RFC should be unified and designed
together.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.c
Hey @DKXXXL, thanks for the example!
Just curious. Do you think the case of copy propagation caused dead code
happens in current workloads? Or this is more like a concern to the TVM
programming model as your example?
Another question is that the name "data-flow" analysis confuses me a bit,
bec
63 matches
Mail list logo
