thanks @yrchen and colleagues for the RFC! overall it's very exciting work. a
couple of thoughts
- is your eventual target bare metal devices, or does your runtime require a
kernel?
- `riscv_cpu` target: in the past we had introduced a special `micro_dev`
target for µTVM work. recently, we de
**See also**: [strawman consolidated dependency
list](https://github.com/apache/incubator-tvm/pull/6620/files#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711)
- NOTE: the strawman was made a few weeks ago and may be out of date. It will
be manually rebuilt before merging.
@tqchen thanks for your reply. I agree we should not overly constrain
dependencies. my thinking is that, purely considering the non-dev dependencies
(i.e. those we might surface to `pip`/`conda`), there are two types of
dependenceis:
- direct dependencies
- indirect dependencies (I.e. dependen
@mjs thanks for your reply! I agree we should avoid overly restrictive version
constraints in our released packages. my thoughts are that specifying a range
for semver packages and especially complex dependencies with significant API
exposure to tvm (I.e. most frontend packages--tensorflow, to
@tqchen @mjs thanks for your replies
there is also a new [pip dependency
resolver](https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-2-2020)
that is about to be standard. this should alleviate a number of the
reproducibility problems, but i'm not sure if t
@tqchen I'm more concerned that there are at least 112 dependencies to specify:
```
$ docker/bash.sh -i tlcpack/ci-gpu:v0.70 pip freeze | wc -l
118
```
probably more when you include the lint deps.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/
I think we need to export the output of `pip freeze` from the CI containers to
help those who are trying to exactly reproduce the CI. I agree with you that we
should try to constrain as few packages as possible--so `ci_constraint.txt`
could be small. but for the purposes of exactly reproducing
it's not really a question that has a general answer. sometimes pinpointing
doesn't matter and other times it does. as an extreme case, pylint cannot be
reproduced without both precise pinpointing of both python packages and the
interpreter itself. that's why it can be hard to lint locally now
thanks for all the discussions! here are the next steps I can see:
1. create a `python/requirements.txt` for the core direct dependencies, specify
version constraints as appropriate to be used in the CI. also create e.g.
`python/requirements-tflite.txt` files (one per extra feature of TVM) in
sure, `python/requirements/requirements.txt`?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-consolidating-tvm-python-dependencies/8329/21)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tv
hi @cgerum, I have a prototype of P0
[here](https://github.com/areusch/incubator-tvm/tree/aot-experiment). it's not
ready to merge and I think we should move to the P1 approach before we do. Feel
free to take a look at it if you like.
Andrew
---
[Visit Topic](https://discuss.tvm.apache.o
In collaboration with @tqchen
See also: [PoC](https://github.com/apache/incubator-tvm/pull/6917)
## Overview
In RAM-limited deployment scenarios (i.e. µTVM), it's desirable to place as
much constant data as possible in a separate binary section and use it directly
from that section. To that
hi @aca88 @ds1231h @cgerum,
thanks for your comments! first off, it looks like I had some code committed
that compiled on my mac but maybe not more broadly. the fix seems to be simple
(use ostringstream instead of stringstream), but please pull again from the
brnach and give it a try to see i
hi @ds1231h,
Your thinking seems correct to me. Choice of GraphRuntime and AOT runtime don't
affect the operator implementation. Ultimately, the goal in compiling a full
model is to produce an implementation of the [Module-based Model Runtime
Interface](https://discuss.tvm.apache.org/t/discus
Great, let's discuss Model Library Format a bit further on another RFC. I will
try to start one early this week.
>> and a new command `tvmc micro gen-project` (or something) would be added to
>> generate the e.g. Zephyr project.
>
>oh that’s cool. Copying (or generating) it from the template d
context is definitely overloaded (can also mean "a collection of state related
to a request" e.g. when serving model inference requests).
I do think there are a couple of ways device could be confusing:
- for µTVM, a new user could consider the whole PCB could be a "device," even
though in re
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
@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
@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
At a high level I was kind of thinking to implement a mix of (1) and (2):
- Checkin a Python library to the TVM repo which makes this look like a Python
API to TVM and API implementation, and handles all the
serialization/deserialization using JSON
- Project API impls import this library and
tagging a few others who replied to the previous RFC
@mjs @leandron @comaniac
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-python-dependencies-in-tvm-ci-containers/9011/9)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these email
here's what I don't like about I1:
- it doesn't ensure dependency versions are compatible across all the various
extras in each container architecture
- it still means that `ci-lint` or `ci-gpu` could wind up with different
package versions from `ci-cpu`
I do agree that most of the large dir
one thing that's particularly annoying is when an error occurs in `ci-gpu`. I
can't run `ci-gpu` locally because I don't have nvidia-docker or a compatible
GPU, and people on e.g. Windows will be in exactly the same boat. it's
sometimes possible to quickly run the failing code locally in e.g.
# Model Library Format
## Background
TVM's build process for imported models centers around `tvm.relay.build`, a
function which produces a 3-tuple `(graph_json, lib, params)`. The inference
workflow then diverges depending on how the user wants to use the compiled
artifacts:
- If the build
>One of the things missing is a way to say the codegen name in the
>runtime.Module without overloading type_key.
I agree. I don't know exactly the best way to proceed here--we likely need
another RFC. The limitation is that with C++ runtime, the external compiler in
BYOC is expected to produc
I would sort of like to keep the sort-by-target structure proposed. I don't
think it affects anything for the time being, and it would be a good discussion
to have as to how to identify `runtime.Module`. They are fairly opaque now.
I think the part that's unanswered for me is whether anyone wo
> What is the expectation of the user to choose which “executor” to be compiled
> for ?
we haven't settled this. Ideally in my mind, the user could just specify a list
of executors, but I'm not sure what the effects of that are on the internals.
---
[Visit
Topic](https://discuss.tvm.apa
I agree we should unify them
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-graphruntime-and-ilk-to-e-g-graphexecutor/9255/12)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apac
I think I originally proposed A1 but one thing is that we have the TVM
extension device types, so perhaps keeping a separate Device is better. I'm ok
w/ A0.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-tvmcontext-to-tvmdevice/9090/26)
to respond.
You are receiving this
hi @giuseros,
> About the implementation we will have `aot_runtime.h` in a separate
> `src/runtime/aot` folder
Would it be possible to create just a library e.g.
`src/runtime/crt/aot_executor`? This will make things less complicated when the
C runtime is distributed with a TVM wheel.
> So t
One open question is where well-known implementations of Project API servers
should live. I see a couple of options:
O1. Place them in the tvm repo, probably under `apps/microtvm` as is roughly
done in [PR 7653](https://github.com/apache/tvm/pull/7653) (Project API not
implemented there, but
PR 7365 has landed -- heads-up that at `main`, GraphRuntime is now named
GraphExecutor! VM version to follow.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-rename-graphruntime-and-ilk-to-e-g-graphexecutor/9255/14)
to respond.
You are receiving this because you enabled mailing li
hi @stoa,
Thanks for the elaborate RFC here! You bring up a bunch of great points.
This is a really strong proposal and I think overall fairly well aligned with
the direction I want to take microTVM. Particularly since similar code has been
posted to the forum before, it would be great to h
Yeah that is a good point. I do think that if we are going with Executor to
describe the runtime, we should rename the existing `tvm.relay.Executor`
interface to something e.g. `ExecutorWrapper`. We could also contemplate the
future of `relay.create_executor`, but should probably do that in a
hey Arthur @stoa,
Great, here are some follow-ups:
### Shared activation pools
>> Could you say more about " it may be necessary that two models share their
>> ‘activation ’ pools?" Are these separate instances of the same model or two
>> different models?
>
>Two different models may be deplo
Great, a few final clarifications.
> The Module Library Format seems not fully finalized yet :wink: That’s fine. I
> will generate the structure as per your RFC proposal (no crt), and we can
> refine it from there. This is a minor detail.
It is somewhat of a living standard, but it's versione
hi @Mousius,
thanks for your proposal and your detailed evaluation of its impact on runtime
resources! i agree these improvements will simplify the generated code and
improve performance. Some thoughts below:
> When we packed and unpack values, we make use of the `data` portion of a
> DLTens
hi @tgall_foo,
I'm in support of this and would be happy to attend! It would be great if we
launched a thread a few days beforehand collecting some proposed topics.
cc @mehrdadh @thierry @tqchen @ramana-arm @aca88 @stoa @r.stahl @hogepodge
@jknight
Andrew
---
[Visit
Topic](https://dis
The main issue with the previous approach is that it wasn't possible to
transform the reference input when a schedule needed layout transformations.
I'm okay with bringing something back so long as we have a way to either
1. handle layout transformations to `ref_input`
2. determine when layout
@tqchen @manupa-arm @mjs @giuseros great discussions so far!
> Identifiers that begin with underscore are reserved by the C standard.
> Conformant C code should not use them, dropping the _ and using just “tvm_…”
> would be conformant.
I agree with this. Do we need to consider distinguishing
thanks for doing this @lunderberg, i think this will be a very positive change.
I do think it's worth discussing the "how do we use this?" angle more. As a
reviewer, there needs to be some very simple way to decide whether a test needs
to be parameterized or whether it can be allowed to remain
cc @MJKlaiber
@Mousius thanks for splitting this off into another RFC. I agree implementing a
low-overhead embedded interface is super important. A couple thoughts:
At a high level, it would be great to explicitly spell out the entire interface
we expect to implement here. I think it might b
i'd support this, i believe we already build something like this for unit
testing.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/any-interest-in-static-library-libtvm-runtime-a/9996/3)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from the
@Mousius @tqchen @stoa
Great discussions here and apologies for my delay in reply! I'm just adding
some thoughts here as context in reviewing PR 8023 and since I kind of left
this thread hanging.
> Thinking about how we expose this to the user, here is a proposed behaviour:
>
>* Default behav
> I agree with you wholeheartedly, we need to be careful with naming here;
> based on your comments it might be good to pick something like
> `--packed-functions` which defaults to running `MakePackedAPI` ? Maybe
> `--packed-internal-functions` or `--packed-operator-functions` ?
How about `--
can you open access to the doc?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/initial-tvm-community-meeting-agenda/9998/3)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.org/email/u
I think the functionality all makes sense to me. I have some questions on the
implementation:
1. Why do you assign global variables when declaring a param, then shadow them
in those functions that use them? This seems like a bad design because
unparameterized functions don't get an unbound va
hi @manupa-arm, thanks for posting this! there's a lot to unpack here.
I think we can break the work here into two parts:
P1. Implementing the unified memory planner based on information in TIR
P2. Modifying the codegen/output to implement various compiler optimizations
based on P1.
I think
hi @r.stahl ,
Thanks for posting your implementation!
> First results are shown below. This is evaluated on RISC-V and using the
> [code generator ](https://github.com/tum-ei-eda/utvm_staticrt_codegen/).
> There still might be some issue, because I would not expect the RAM usage to
> rise in
Hi all,
Currently the documentation for the TVM site is written in
[ReStructuredText](https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html).
However, just about everything else we do is in Markdown:
- this forum
- github
- discord
Needing to know two languages makes it hard
@tqchen thanks for the context. I agree that it may not be worth it if you
still have to learn restructuredtext to write a single document. with that
said, I do think that MyST-Parser seems to be an improvement over recommonmark.
There is also some [more
context](https://github.com/readthedoc
> Would either md or rST allow for cross-references between the python API
> documentation and the C++ documentation? I think that would be the biggest
> feature for me, since it would give a clear way to indicate which functions
> are intended to only be wrappers.
they both do via references
Thanks @leandron for the proposal! I agree this will be a great help in
monitoring the container rebuild process for problems and should reduce the
headache typically involved with updating containers.
I think we could prototype this first using
https://discuss.tvm.apache.org/t/ci-how-to-run-
Hi all,
PoC (rough):
https://github.com/apache/tvm/compare/main...areusch:move-backend-runtime?expand=1
As we work to merge AOT, define the µTVM firmware-facing API, and merge support
for existing embedded frameworks such as
[STM32](https://discuss.tvm.apache.org/t/rfc-standalone-code-genera
@Mousius thanks for this RFC and apologies for the long delay. I read this in
conjunction with [[RFC] Arm® Ethos™-U
Integration](https://discuss.tvm.apache.org/t/rfc-arm-ethos-u-integration/10504)
to try to understand the initial application. I think that should be a
sufficient example, but l
Just a reminder that our community meeting is happening tomorrow, Aug 18 at 8am
PDT 10am CDT, 1500 UTC, 1600 BST, 2030 IST, 2300 China.
Andrew
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-microtvm-community-meeting-august-18th/10686/6)
to respond.
You are receiving this becau
@mousius Thanks for this important RFC. I'd like to approach this from the
other way around: what parts of device configuration does it make sense for TVM
to involve itself with, and which parts don't necessitate any binding between
TVM runtime and device control? In this framework you can alm
Hi Everyone!
The next microTVM community meeting is planned to be Wednesday October 27th.
8am PDT 10am CDT, 1500 UTC, 1600 BST, 2030 IST, 2300 China
We’ll use zoom for the get together. The zoom connection link is located in the
agenda document which is at : [Apache TVM - microTVM Community M
@gromero yep please go for it!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pre-rfc-tvmc-add-support-for-microtvm-targets/11221/20)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.apache.o
Wow lots more discussion here! Thanks @junrushao1994 for writing up our
discussions. So one thing I'd like to point out is that the recursive Target
approach is not more expressive than the approach proposed by this original
RFC. Expressing a "contains" relation can be done equivalently well b
Hi all,
Due to the upcoming holiday in the US, we'll skip this next microTVM meeting
and reconvene on December 8th (one week before TVMCon, which I'd also like to
encourage everyone to attend as there will be many talks about and related to
microTVM).
Thanks,
Andrew
---
[Visit
Topic](h
Summarizing the discussion a bit here:
- There is consensus that such a bypass mechanism could be useful
- There is widespread concern of abuse. Due to this concern, it's been
suggested to also improve our CI filter to skip parts of the CI for certain
changes.
- There is consensus that committ
@MajorTom would BYOC + pattern matching against Relay ops work for your use
case?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/tvm-integration-with-external-dsp-accelerator-api/11641/4)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from t
Hi Everyone!
The next microTVM community meeting is planned to be Wednesday, January 5th at
8am PDT 10am CDT, 1500 UTC, 1600 BST, 2030 IST, 2300 China.
We’ll use zoom for the get together. The zoom connection link is located in the
agenda document which is at : [Apache TVM - microTVM Communit
hi @cyx thanks for this proposal! I have a couple questions for you on it.
First, could you elaborate a bit more on the use case you have in mind?
[quote="cyx, post:1, topic:11816"]
allows TVM containers to carry PackedFuncs,
[/quote]
it seems like this might be one of them. Given we can alre
thanks for the writeup @wrongtest! a couple points I am more curious about:
[quote="wrongtest, post:1, topic:11807"]
Our tir schedule phase would rewrite tensor layouts to fit hardware features,
so we modify the compile engine to give a chance of compatible updates at relay
level.
[/quote]
co
@MJKlaiber Thanks for the pre-RFC! Overall I'm very supportive of making it
easier to integrate custom accelerators with TVM. I agree it makes sense to
consider the set of interfaces an accelerator vendor may need to implement in
order to bring their accelerator to TVM and try to harmonize the
Thanks! filed https://github.com/apache/tvm/issues/10238, i think this is not a
formal requirement for TVM but just a loose end which was not updated.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/pillow-9-0-0-security-vulnerabilities/12070/2)
to respond.
You are receiving this beca
Hi all,
We're a bit busy this week and haven't gotten the microTVM Community Meeting
announcement out with enough time to collect ideas, so we'll skip this meeting
and resume on Mar 2.
Thanks,
Andrew
---
[Visit
Topic](https://discuss.tvm.apache.org/t/no-microtvm-community-meeting-feb-16
We discussed this a bit offline; posting some brief outcomes of that call here
and some additional response I had from before.
[quote="MJKlaiber, post:4, topic:12039"]
Let’me give you a pain points why we think changes in the codegen should be
possible for the standard developer: Adding an inc
[quote="MJKlaiber, post:7, topic:12039"]
This seems to be already in main:
[/quote]
You are right, my apologies. I'll edit the original post.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-uma-universal-modular-accelerator-interface/12039/8)
to respond.
You are receiving this bec
I support this RFC and will shepherd it through review process. It looks like
we have some :heart: from the OctoML folks, but would be great to get some
feedback from others in the community, particularly from folks who may be
monitoring TVM PRs less frequently than those of us at Octo.
Let's
@comaniac thanks for your comments!
[quote="comaniac, post:5, topic:12095"]
Improve the PR template to guide the contributors about how to improve the PR
visibility. We actually have this already but seems not effective. Pro: it is a
simple change. Con: it may be ignored by most contributors.
@MJKlaiber I'm going to take on hosting the community meetings from Chris
shortly. I'm just checking on a few last things before posting up about it.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/tvm-community-meeting-november-18-2021/11475/4)
to respond.
You are receiving this beca
### Background and Motivations
To date we’ve (up til Jan 2022) been hosting two different TVM Community
Meetings:
- A monthly TVM Community Meeting, hosted by Chris Hoge
- A bi-weekly microTVM Community Meeting, hosted by Tom Gall
Community Meetings are a great place for folks in the communit
Hi Everyone!
The next microTVM community meeting is planned to be Wednesday, March 2 at the
usual time of 8:00am PST, 16:00 UTC (4:00pm London), 17:00 CEST, 21:30 India,
24:00 China.
We are going to try to unify the microTVM Community Meeting with the TVM
Community Meeting (which has gone on
Hi all,
The next TVM Community Meeting is Wednesday, March 1 at 8:00am PST, 16:00 UTC
(4:00pm London), 17:00 CEST, 21:30 India, 24:00 China. This is the first TVM
Community Meeting of 2022 and is unified with the microTVM Community Meeting.
The agenda for this meeting can be found in the [age
Whoops, correction--the original post said March 1, but the meeting is actually
March 2. I've updated the original post with the correct date.
Thanks!
Andrew
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-mar-2/12192/2)
to respond.
You are receiving this b
We discussed this at the TVM Community Meeting this morning. There was a
presentation about the approach followed by some discussion. Thanks @MJKlaiber
@cgerum @SebastianBoblestETAS @paulpb @PhilippvK @r.stahl @aca88 for bringing
this to the meeting!
Here are some notes (please feel free to c
Overall I'm supportive. It looks like there is also [prior
art](https://github.com/jasonkuster/merge-bot) for an ASF project to do
something like this (although it's not clear how that bot is run). There is
also some mention of [preserving
provenance](https://www.mail-archive.com/search?l=d..
Hi all,
The next TVM Community Meeting is Wednesday, March 9 at 8:00am PST, 16:00 UTC
(4:00pm London), 17:00 CEST, 21:30 India, 24:00 China. This is the first TVM
Community Meeting of 2022 and is unified with the microTVM Community Meeting.
The agenda for this meeting can be found in the [age
thanks! feel free to open an RFC PR and we can iterate there if you like.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/rfc-uma-universal-modular-accelerator-interface/12039/15)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these email
We discussed this at the TVM Community Meeting this morning.
- It seems like some of the problems addressed here (unable to assign PRs to
folks outside the Apache org) are better handled by adding more folks to Apache
org. Are we exploring this?
- Yes, but separately from this automation. T
Thanks everyone for joining this morning! I've written some notes:
- https://discuss.tvm.apache.org/t/rfc-remove-codeowners/12095/14
- https://discuss.tvm.apache.org/t/why-c-unpacked-api-not-work-anymore/11845/25
Tune in next week for discussion of a Relay fuzzer. And as always, feel free to
ad
I support improving the process of updating the CI docker images. A couple of
thoughts here:
- I agree the Jenkinsfile security is a little bit arbitrary. I think maybe
there could be an aspect of protecting the Jenkins master (i.e. I think you can
get references to internal shared Java object
Hi all,
The next TVM Community Meeting is Wednesday, March 16 at 8:00am PDT, 15:00 UTC,
16:00 CEST, 20:30 India, 23:00 China. We are continuing our trend of unifying
the TVM and microTVM Community Meetings.
**Please note the time change due to Daylight Savings Time in the United
States.**
T
Looks like we have one agenda item for tomorrow: Type-directed Relay fuzzing
library. Let's plan to meet to discuss this one.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-march-16/12298/2)
to respond.
You are receiving this because you enabled mailing lis
We discussed this at the TVM Community Meeting this morning. A couple of notes:
- What is the best reference paper for Relay? Where was the algebra for the
type relations used here sourced from?
Steven: The [Relay paper](https://arxiv.org/abs/1810.00952) is still the
most comprehensive re
The recording has been [posted](https://youtu.be/1t2wf-hDjwg).
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-march-16/12298/3)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https:/
@SebastianBoblestETAS I think this could be helpful for folks consuming TIR
outside of TVM itself. A couple of thoughts:
1. Right now a related problem is that there isn't currently a way for
`tvm.relay.build` to return the `IRModule`s which contain TIR itself. You can
see that in the
[BuildO
Hi all,
The next TVM Community Meeting is Wednesday, March 16 at 8:00am PST, 16:00 UTC
(4:00pm London), 17:00 CEST, 21:30 India, 24:00 China. This is the first TVM
Community Meeting of 2022 and is unified with the microTVM Community Meeting.
The agenda for this meeting can be found in the [ag
It looks like we will have some discussion tomorrow about automatically
publishing PyPI packages. Hope to see you all there!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-mar-23/12347/3)
to respond.
You are receiving this because you enabled mailing list m
The recording for this is processing and will be available
[here](https://youtu.be/1XavUsUl7aM0) when it's finished.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-mar-23/12347/4)
to respond.
You are receiving this because you enabled mailing list mode.
To
@sven what's the status on this RFC? Is it something you're still interested in
contributing?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/byoc-add-verisilicons-npu-support/11097/10)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from thes
Hi all,
The next TVM Community Meeting is Wednesday, March at 8:00am PST, 16:00 UTC
(4:00pm London), 17:00 CEST, 21:30 India, 24:00 China. This is the first TVM
Community Meeting of 2022 and is unified with the microTVM Community Meeting.
Please note the time change due to Daylight Savings T
Hi all,
I started a new weekly format for the TVM Community Meetings about a month ago.
In this format, we continue to meet over Zoom, but:
- we change the cadence to a weekly meeting on Wednesdays
- require folks to include a discuss forum or PR link when proposing discussion
topics
- and can
Looks like we've got [Buffer Layout Padding
RFC](https://github.com/apache/tvm-rfcs/pull/77) on the agenda tomorrow. Hope
to see you there!
---
[Visit
Topic](https://discuss.tvm.apache.org/t/next-tvm-community-meeting-june-8-2022/12900/2)
to respond.
You are receiving this because you e
Please join us in welcoming @tkonolige as a new committer to TVM! Tristan has
been consistently contributing to all parts of TVM, from the runtimes to the
frontends, schedulers, tuning, documentation, CI and general bug fixing.
Notably, he contributed libbacktrace and PAPI support.
- [Commits
Hi all,
In [[mini-RFC] Name mangling in
AOT](https://discuss.tvm.apache.org/t/mini-rfc-name-mangling-in-aot/9907), we
discussed ways to accommodate the `runtime::Module` tree in an embedded
environment, where we prefer to call functions directly in the generated C
using their symbol name rat
1 - 100 of 107 matches
Mail list logo
