Thanks for participating in the TVM community! We use https://discuss.tvm.ai
for any general usage questions and discussions. The issue tracker is used for
actionable items such as feature proposals discussion, roadmaps, and bug
tracking. You are always welcomed to post on the forum first :)
I
A PR posted https://github.com/apache/tvm/pull/7425
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-add-while-loop-node-to-tir/9028/15)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apa
Catching up with all the messages here, it looks like there are two problems
and two solutions for the subsets of `tvmc` commands in discussion:
**P1:** **How can we create something that allows uTVM to be integrated
bare-metal and RTOS?** This is aimed to provide TVM/TVMC as *tools* to be
in
I'm not worried about the µTVM case especially if that's the only concern. The
main thing I'm wondering about is whether it makes sense to let the DLPack RFC
get accepted before we make changes here.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/909
Thanks for the discussions so far. I think everyone seems to agree on T1, it is
good to have a way to have a place where users and developers can look into. T2
and T3 are the ones that worth discussing.
Trying to summarizing a few rationales of the current CI pipeline.
### R0: Use Binary Tag
@manupa-arm @leandron thanks for the reply!
@manupa-arm wrote:
> I was hinting that we could do use export_library on the runtime.Module
> (which is a multi-module hierarchical tree) produced via relay.build using
> the correct cross compiler and target object format as .o/.a.
I agree we sho
> I agree we should support binary output. My thought is this would depend on
> the TVM target in use–but we can talk about it
Yeah I think so too. Like, I won't be good to always generated a .so and a .o
(for example) for the static runtime case, which afaics will only be
"interested" in the
I agree with the change, internally it would be nice to drop the TVM prefix as
well and just refer to it as a `tvm::Device` like we do with almost every
other data structure in the code base.
Thanks for doing this Haichen!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tv
My take on dropping the TVM prefix: given DLTensor/DLContext is the de facto
standard, we do not really need to define their TVM alias (e.g. TVMContext) and
can just use them directly
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/9090/11)
to respon
I think we can keep `TVMDevice` in the C++ and backend, but use `tvm.device` in
the python frontend. It can reduce the confusion when integrating TVM into
other frameworks if we keep `TVM` prefix.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/9090/1
@tqchen Thanks for the reply! A couple of points:
- You're right that I2/I3 don't capture all dependencies. There is a notable
gap between a set of Python dependencies and the docker container: the
remaining libraries which may be present in the container.
- The method by which those libraries
I'm open to changing `build.sh` to reference the previously-used lockfile,
which should make it possible to update containers independent of the Python
deps used.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-python-dependencies-in-tvm-ci-containers/9011/8)
to respond.
You are
"Which are summarized summarized from the forum discussion." double summarized
may be a small mistakes.
--
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/4845#issuecomment-776379632
Closed #4845.
--
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/4845#event-4312506615
v0.8 cycle tracking issue is created https://github.com/apache/tvm/issues/7434
--
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/4845#issuecomment-776396641
[quote="lsy643, post:4, topic:8139"]
VM
[/quote]
Sorry for acting a bit late on this thread. It slipped through due to the
conference and holiday break. Thankfully a lot of things are already under way.
A formal tracking thread is created here
https://github.com/apache/tvm/issues/7434
--
16 matches
Mail list logo
