►
From YouTube: Apache TVM Community Meeting, March 23, 2022
A
Great
so
welcome
everyone
to
the
march
23rd
edition
of
the
tbm
community
meeting.
My
name
is
andrew.
I'm
the
host
here
and
see
looking
at
the
agenda
here.
It
looks
like
we
have
a
couple
different
things
for
this
week
with
some
announcements
to
start
out
with,
as
well
as
then
we'll
have
a
discussion
on
publishing
pi
pi
packages.
A
A
B
So
we
don't
have
to
do
that
manually
anymore,
because
you
know
last
time
it
was
like
months
out
of
date
just
because
someone
had
to
remember
to
go.
Do
it,
so
that's
all
squared
away
in
live
so,
but
I
mean
I
see
some
follow-up
work
there
around
making
it
easy
to
select
old
versions
of
the
docs
and
things
like
that.
B
B
So
what
this
issue
allows
you
to
do.
Is
you
just
leave
a
comment
with
your
username
and
the
tags
you're
interested
in
and
my
dad
already
added
himself
for
some
stuff,
so
you
can
just
copy
whatever
he
did
and
then
anytime
someone
puts
that
in
their
pr
or
an
issue
it'll
ccu
on
that
automatically,
so
you
will
just
get
an
email
about
it,
and
so
the
idea
is
like
this
is
all
you
know
opt-in.
B
A
Yeah,
that's
pretty
much
it
yeah
awesome.
Both
those
things
are
super
useful
and
so
yeah
for
the
last
one.
I
think
just
to
emphasize
you,
you
know
the
way
that
you
subscribe
and
unsubscribe
is
to
leave
a
comment
in
the
same
form
as
as
the
ones
that
are
already
left
there
or
dad's
being
a
good
example
and
just
edit
the
comment
or
delete
it.
If
you
want
to
unsubscribe
that,
I
think
I
have
that
right,
yeah,
but
yeah.
A
So
it's
a
little
bit
of
a
you
know,
there's
no
official
system
for
this.
It's
just
us
using
github
to
keep
track
of
this.
So
we'll
go
with
that
for
now
yeah.
This
will
be
great
and
I
think
the
other
thing
is
that
we'll
probably
be
working
to
kind
of
standardize.
The
list
of
topics
I
mean
they're
already
semi-standard,
but
I
don't
know
if
anyone's
written
down
exactly
you
know
for
microtvm
use
the
specific
tag
you
know
not
not
utvm
or
or
whatever
so
take
it.
A
I
guess
be
on
the
lookout
for
that
in
the
next
couple
of
weeks
or
months
as
we
get
to
it
so
great,
and
then
with
that,
let's
see
some
other
announcements
just
welcome
christoph
and
see
you
into
the
pmc.
You
know.
I
think
that
it's
great,
that
the
leadership
is
growing
on
the
project
and
you
know
we're
looking
forward
to
welcoming
more
folks
as
committers
and
pmc
members
in
the
coming
weeks.
A
So
as
this
kind
of
grows,
I
just
wanted
to
see
if
anyone
is
interested
in
helping
to
either
host
the
meeting
or
also
to
take
notes,
there's
landra,
I
see
him
so
good
morning
yeah.
So
I
just
wanted
to
to
kind
of
post
up
just
a
note
that
there's
kind
of
a
couple
different
roles
that
we
were
kind
of
envisioning
here
for
this
meeting,
one
one
would
be
someone
who
is
sort
of
the
host
and
could
sort
of
just
coordinate
the
zoom
call.
A
So
anyway,
I'm
gonna
continue
doing
that.
But
if
that's
something
you're
interested
in
I'll
post
up
a
discuss
thread
at
some
point-
and
you
know
feel
free
to
reply
there
or
to
dm
me-
and
you
know
a
few
folks
have
already
reached
out
and
offered
to
help.
So
thank
you
for
that
already,
and
I
think
you
know
as
going
forward.
A
C
C
Only
package
I
mean
tlc
pack
is
is
is
great
from
one
point
of
view,
which
basically
it
offers
our
users
with
some
packaging.
It's
not
very
intuitive.
There
is
always
kind
of
a
big
explanation.
You
need
to
do
when
you
try
to
advertise
dlc
pack
for
people,
because
they
say
hey.
Look
if
you
want
to
install
tvm
here.
C
Is
this
tlc
pack
thing
you
can
install
and
you
get
access
to
what
is
literally
pvm,
compiled
and
packaged
as
a
python
package
or
on
the
package,
and
this
sort
of
thing
now
we've
been
having
talks
for
a
while
in
order
to
kind
of
improve
that
situation,
and
the
idea
is
to
from
recent
conversations
to
publish
tvm
publishes
up
as
apache
tvm,
so
the
I
mean
the
dream.
The
goal
we
want
to
have
with
this
is
to
offer
our
users
with
a
kind
of
a
really
what
they
expect,
which
is
the
sort
of.
C
C
C
So
at
the
moment
I
have,
I
have
a
pr
going
on
on
tlc
pack,
which
basically
allows
this
build
packages
to
be
uploaded
to
to
pipei.
We
have
the
credentials
sorted
out
for
one
project
which
is
apache
tvm.
So
if
you
install,
if
you
get
your
your
script
or
your
thing
or
your
requirements,
dot
text
or
whatever
you
add
the
apache
tvm,
you
are
expected
to
have
a
cpu
package,
not
not
right
now,
because
that
that
pr
is
not
closed
is
ongoing.
C
We
expect
to
follow
a
similar
approach
to
what
is
done
on
mxnet,
for
example,
so
mxnet
they
have
one
package
for
each
version
of
cuda
that
they
offer.
So
our
expectation
is
when
sort
of
some
work
is
done
in
in
the
sense
of
enabling
this
package
in
this
packages
that
we
just
reuse
the
same
infrastructure
that
I
created
for
the
cpu
package,
just
to
upload
them
to
the
right
package
names.
This
is
all
sort
of
expected
to
be
covered
in
terms
of
infrastructure.
C
C
From
here
I
mean
once
we
get
this
pr
merged.
What
we
will
need
to
do
is
to
I
guess,
for
the
sake
of
the
users,
they
were
the
kind
of
a
type
of
users
we
have.
The
next
big
step
would
be
start
enabling
these
gpu
packages,
and
for
that
we
will
need
probably
to
understand
which
are
the
ones
that
we
will
prioritize.
C
If
we
get
some
help
on
people
that
are
really
interested
in
those
packages,
it
would
be
good
as
well
so
yeah.
I
mean
we
can
also
use
this
meeting
to
our
folks
that
are
here
today
to
advertise
on
this
and
and
let
everybody
know
that
this
work
is
ongoing
and
this
kind
of
effort
is
trying
to
to
create
this
sort
of
a
packaged
versions
of
tvm.
C
We
want
to
link
this
work
with
the
some
other
work
that
is
being
done
in
terms
of
release
cadence.
At
this
moment,
I
I'm,
I
guess
we
are
building
that
strategy.
We
are
as
a
community
at
this
point.
We
are
not
very
good
of
releasing
often
and
organizing
these
releases
and
everything,
so
this
work,
that
is,
that
is
ongoing,
will
at
some
point,
be
linked
into
how
we
release
vectors.
So
we
really
will
declare
a
version
on
the
tvm
project,
which
is
one
thing
for
the
sort
of
apache
process.
C
We
will
have
a
branch
that
is
stacked
with
a
given
version.
That
means
that
is
what
a
release
means
on
the
tvm
project,
but
on
the
side
of
that
in
parallel
to
that,
we'll
probably
need
to
have
some
community
effort
to
package
that
release
and
update
that
release.
That
will
probably
be
worth
to
be
coordinated
by
the
release
manager
with
the
help
from
the
community.
C
A
A
How
are
we
planning
to
mark
those
as
like,
like
the
versions
of
those
uploads,
I
mean
we
talk
about
not
doing
a
release
super
frequently,
but
you
know,
on
the
other
hand,
doing
a
nightly
upload
is
sort
of
doing
a
release
in
some
sense
right.
So
I
think
there's
ways
to
mark
dev
packages-
and
I
was
just
curious-
if
you
know-
is
that
kind
of
the
plan
for
now
and
yeah.
C
C
So
once
we
match
on
a
specific
release
tag,
if
we
run
the
same
tooling,
we
have
right
now
we
will
generate
a
release
package
as
well.
So
this
is
all
the
infrared.
Dlc
pack
is
already
sort
of
implemented.
With
this
in
mind,
this
is
I
mean
this
is
not
work
that
I
I
have
done
all
myself
in
the
context
of
this
is
something
that,
as
I
said,
is
being
developed,
for
I
mean
many
people
in
the
last
year
or
so
yeah,
so
that
that's
covered
in
the
current
tooling.
C
A
Got
it
okay,
so
basically
we'll
create
these
packages.
I
guess
to
start
with
that
are
named
like
0.8.dev,
something
or
other
and
that'll
sort
of
be
what
we
upload
at
first,
and
so
when
that,
when
that
pr
lands,
what
will
change
is
that
you
could
run
pip
install
apache
tvm,
but
I
think
that
means
you'd
also
have
to
pass
dash
dev.
That's.
E
C
A
Yeah,
I
agree
with
that.
I
actually
don't
know
the
answer
to
this
either
if
anyone
else
has
experience
with
pi
pi
here
and
and
knows
that,
I'm
curious
to
the
to
the
response
to
the
answer
here,
but
otherwise
we'll
try
this
for
now
and
if
we
wind
up
having
to
move
the
dev
packages
back
to
you
know,
dash
f,
you
know
a
separate
index.
Basically,
I
think
that
that's
the
plan
so
yeah.
C
C
F
F
C
For
dependencies,
what
do
you
mean
for
the
tvm
version
itself
for
dependencies
right?
So
dependencies
is
another
very
contentious
thing
that
we
need
to
deal
with.
I
guess
it's!
It's
independent
at
this
point
on
the
on
the
tooling
to
generate
a
package.
It's
something
that
go
in
parallel,
that
it
doesn't
block.
Really
one
thing
doesn't
block
the
other,
that
that
is
a
discussion
that
we
need
to
have
as
a
community
in
order
to
sort
out
our
dependencies.
C
A
C
A
Right,
yeah-
and
I
think,
probably
almost
a
year
ago
now,
I
posted
up
an
idea
for
dealing
with
those
dependencies
and
I
have
not
actually
implemented
it.
Yet
david's
been
doing
a
little
bit
of
work
to
move
some
of
the.
There
was
a
couple
pipeline
packages
that
were
installed
last
minute
in
the
ci
and
I
think
david's
doing
some
work
there.
I
don't
know
if
you
have
your
hand
up
david
to
speak
to
that
or
if
you
have
another
question.
B
A
A
G
Oh
yeah,
this
is
related
to
just
how
we
are
able
to
measure
and
track
downloads
from
the
python
packaging.
So
I
was.
I
was
trying
to
understand
like
how
how
much
uptake
there
was
for
the
python
packages
that
we
that
we've
been
publishing
to
to
github
and
one
of
the
side
effects
of
pushing
new
packages
nightly,
as
it
would
reset
the
download
counters
that
that
github
keeps
track
of
which
makes
it
really.
G
G
B
C
C
C
One
challenge
with
the
current
scheme
is
that
we
we
not
only
upload
new
packages,
but
we
delete
the
previous
packages,
so
we
have.
This
has
kind
of
a
many
side
effects
that
that
I
would
like
to
have
sold
to
that.
I
would
like
to
solve
with
the
ipi
packaging
upload,
for
example,
well,
which
I
said
before.
If
somebody
reports
me
an
issue
on
a
package
on
a
given
version
and
it
is
tomorrow,
I
cannot
reproduce
that
locally.
C
I
need
to
recreate
all
the
packages
by
myself,
and
this
is
something
if
we
have
a
more
consistent
package
kind
of
storage
on
pipi
that
something
we
can
reproduce
as
well
as
the
sort
of
metrics
like
this
sort
of
downloads
and
everything.
If
the
packages
are
there,
we
can
consolidate
all
that
information
because
david,
I
don't
know
if
you,
if
you
raise
your
hand
against.
B
B
So
I'm
not
saying
we
use
a
block
or
anything,
but
I
think
it'd
be
nice
if
we
had
like
at
least
a
small
set
of
like
core
tbm
tests
and
we
could
check
out
evm
just
run
these
tests,
like
you
know
not
something
very
long
like
five
minutes
or
whatever,
just
to
check
that,
like
the
basic
stuff
works
on
all
these
different
kind
of
platforms,
which
is
kind
of
like
a
smoke
test
type
thing.
So
it's
kind
of
like
a
follow-up
test.
I
think
we
should
do
so.
C
C
It
is
sort
of
a
installable.
So
you
can
install
that
in
in
the
versions
you
publish
and
we
get
an
import
tvm
working,
that's
sort
of
a
surprisingly
was
was
not
something
that
worked
100
of
the
time.
So
that's
why
I,
but,
as
I
mean
this
is
less
than
the
minimum,
so
I
I
agree
with
you
that
we
need
to
do
some
sort
of
functional
testing
on
the
on
the
package
itself.
Okay,.
C
C
C
A
A
A
E
A
Right,
yeah,
that
makes
sense,
I
guess
we're
still
we
haven't
really.
I
mean
I
think
that
to
me
this
is
a
little
bit
of
a
chicken
and
egg
problem
in
the
sense
that
we
don't
have
a
conveniently
available
package
binary,
and
so
you
know
doing
things
like
tbmc
micro
may
often
require
building
from
source.
We
do
have
this.
I
guess
we
do
have
this.
A
I
C
A
Everyone
here
is
like
a
developer
yeah.
I
I
I
kind
of
was
expecting
that
everyone
here
would
say:
well
we're
still
going
to
build
from
source,
but
I
was
just
curious
if
there's
any
workflows
out
there
that
people
know
of
now.
That
would
be
helpful
and-
and
you
know
I
feel
like
I
know
of
some,
but
I
would
still
build
from
source
kind
of
a
thing
right
now.
G
Yeah
I
mean
it
really.
I
mean
it
really
seems
like
you
know,
for
the
for
the
person
who
wants
to
try
this
out
inside
of
like
pie,
torch
environments.
This
would
this
would
be
really
useful
and
also
any
alternative
packaging
too.
For
for
the
runtime,
because
I
could
see
like
the
whole
end
goal
of
tvm
is
to
be
able
to
to
get
packages.
G
You
know
like
compiling
is
not
shouldn't,
be
the
end
of
what
we're
doing
getting
these
the
production
would
help
and
being
able
to
do
a
minimal
installation
of
the
runtime.
I
would
imagine,
would
be
a
use
case
that
would
be
requested
as
tvm
becomes
more
popular,
but
you
know,
but
it
seems
like
getting
into
like
third-party
environments
like
like
pie,
torch
and
then
getting
into
production
are
kind
of
like
the
steps
that
packaging
gets
you
and
get
you
to.
C
C
By
having
packages
and
having
versions,
we
can
do
some
more
kind
of
experiments
with
tvm.
If
we
know
that
we
have
this
version
that
this
release
against
some
other
release-
yeah,
I
think,
and
as
sort
of
as
a
python
first
framework,
I
think,
having
a
package
is
kind
of
a
vital
thing
to
have.
I
guess
gustavo
wants
to
comment.
E
Yeah,
I
was
just
wondering
that,
as
users
will
use
more
the
packages
for
tvm
installable
stall
from
pi
pi,
there
will
be
they
will
for
sure
file
issues
and
complaining
about
some
yeah.
Some
issues
there-
and
this
is
very
helpful
for
us
to
you-
know,
determine
precisely
what
was
the
config
file
used
for
that
particular
binary
package
and
also
the
tag
used
to
build
it.
So
how
do
you
envision?
C
Yeah,
that's
that's
a
good
point,
one
of
the
things
that
one
of
the
things
that
is
clear
sort
of
from
the
released
or
the
version
tag
number
according
to
this
python
or
this
pep
here
it
does,
it
doesn't
have
a
space
and
it
doesn't
really
accept
the
git
hash
that
we
use
to
sort
of
a
track.
What
is
generated
so
what
I
was
really
thinking
about,
that
is,
each
package
will
have
it
name
its
name
and
once
we
start
generating
packages,
we
can
go
there
and
tag
the
repository.
C
B
H
C
C
A
I
think
I
think
I
remember
the
point
you
were
gonna
say
though
gustavo,
which
was
that
I
think
you
were
discussing.
We
were
trying
to
reproduce.
Basically,
someone
had
a
problem
with
tvmc
and
we're
trying
to
figure
out
how
to
reproduce
it
and
it'd
be
so
helpful
to
basically
be
able
to
ask
for
you
know
one
thing,
whether
it's
the
version
number
or
something
like
that.
A
C
Yeah,
so
this
is
this
is
something
that
I
kind
of
thought
initially
when
I
was
doing
this,
which
is
kind
of
hard
at
this
point
for
us
to
propose
changes
on
how
the
from
the
cmake
used
to
generate
the
package.
So
this
is
something
that
at
some
point,
I
guess
again
in
the
sort
of
a
dream
packaging
thing
this
he
make
would
be
part
of
tvm
and
the
package
would
just
consume
say
I
mean
what
is
according
to
tvm
repository
the
way
we
generate
packages
from
it.
C
So
this
obviously
opens
all
the
doors
to
have
sort
of
a
package
with
debug
symbols,
and-
and
this
sort
of
thing
I
mean
whatever-
is
the
weight
and
the
flags
we
consider
that
are
safe
to
include
in
the
package.
We
would
put
that
on
tv
in
in
the
tvm
repository
and
the
packaging
tooling
would
just
consume
that
at
this
moment,
if
you
go
to
tlc
pack
repository,
there
is
a.
There
is
a
script
in
there
that
contains
the
cmake
flags
that
we
use.
C
But
your
voice
disappeared
again,
so
I'll
just
feel
that
just
feel
that
saying
that
we
have
a
set
of
docker
images
and
that
those
dependencies
on
the
docker
images
we
need
to
match
with
the
flags
we
are
using.
So
we
have
a,
for
example,
when
we
build
some
of
our
drivers
for
the
arm
neural
network
accelerators,
and
we
need
to
build
those
in
the
many
linux
platform.
C
A
Yeah,
that's
right,
so
the
the
specific
c
plus
dependencies
would
have
to
be
built
against
that
mini
linux
thing
is
what
you're
saying
so
yeah
that
makes
sense,
and
then
the
other
thing
is.
I
guess
we
might
need
to
think
a
little
bit
about
like
if
we're
going
to
generate
a
gpu
package,
for
example,
that
probably
builds
off
of
the
python
and
simple
plus
dependencies
that
we
have
in
the
gpu
docker
image,
which
I
think
is
something
similar
to
what
you
were
saying
or
the
same
thing.
A
What
you
were
saying,
yeah,
there's
sort
of
an
open
question
of
how
do
we
sort
of
I
guess.
Another
thing
I'd
like
to
see
us
do
is
like
reorient
the
ci
around
basically
a
similar
test
environment
to
that
which
we
would
use
to
test
the
python
packages.
So
you
know
right
now.
For
example,
we
run
all
the
tests
from
the
root
of
the
source
tree,
and
so
you
can
kind
of
just
like
open
a
file
that
happens
to
be
in
the
repo
and
no
problem
there
right.
A
But
if
we're
going
to
test
the
wheels-
and
we
want
to
run
the
test
case
against
the
wheel,
you
know
that
will
not
be
true,
and
so
it
would
be.
You
know,
I
think
another
thing
that
I'd
like
us
to
look
at
in
the
coming
months
is:
you
know,
moving
the
the
tests
away
from
the
source
repo
so
that
you
have
to
do
a
little
more
work
to
get
those
dependencies.
Basically,.
C
Yeah
yeah
one
concrete
case
on
that
was
the
standalone
crt
files.
We
realized
at
some
point
that
we
couldn't
get
that
from
the
package.
All
the
tests
work
pass
perfectly,
but
when
you
package
that
sub
directory
was
not
there,
that's
so
we
got
some
work.
That
was
done
just
to
add
that,
as
part
of
the
the
package.
A
Right-
and
I
mean
that
was
meant
to
be
put
in
the
as
a
data
dependency
to
the
package,
but
you
know
someone
had
to
do
that
work
and
actually
make
sure
it
was
a
data
dependency.
So
you
know
we'll
have
to
have
some
way
of
fetching
stan
these
data
dependencies
from
either
source
or
from
the
package,
and
I
think
there
are
lots
of
python
utilities
that
do
this.
But
just
you
know
more
things
to
work
on
so
yeah.
C
Yeah
yeah,
but
I
mean
all
this
probably
will
start
as
soon
as
we
get.
I
mean
I,
I
think
our
direction
and
our
plan
is
kind
of
correct,
because
we
will
start
having
packages
there
that
are
known
binding,
so
to
speak.
They
are
not
attached
to
releases,
we
sort
of
how
to
say
we
communicate
with
the
community.
C
A
C
D
A
In
that
yeah
I'll
announce
this
also
internally
within
octoml.
This
is
means
a
little
bit
early
for
folks
here
to
to
come
to
kind
of
every
week,
but
so
usually
make
sure
I
especially
announce
it
on
weeks
where
we're
gonna
be
talking
about
something
like
this,
but
anyhow
I'll,
be
sure
to
announce
that
more
in
optimal
and
then
see.
If
anyone
here
who
works
more
closely
with
gpus
could
provide
some
some
input
there.
So.
C
C
A
Definitely
and
then,
probably
a
few
more
things
that
are
longer
term,
that
we
just
need
to
work
on
like
properly
tracking
the
500
dependencies
in
containers
and
and
a
few
just
making
sure
that
we
figure
out
how
this
impacts
our
ability
to
get
performance
numbers
and
things
like
that
in
terms
of
in
terms
of
downloads.
So
yeah
yeah.
A
Yeah
yeah
four
meetups,
but
yeah
about
a
month,
sounds
good
cool
all
right.
That
sounds
good.
Well,
so
everyone
feel
free
to
follow
along
on
the
thread
and
also
on
the
pr
and
we'll
just
keep
pushing
this
along
and-
and
I
think
it's
great
to
see
this
improving.
So
thank
you
so
much
andrew
for
pushing
on
this.