►
From YouTube: Apache TVM Community Meeting, March 2, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
so
welcome
everyone
to
the
march
second
tbm
community
meeting
and
I'm
andrew
royce,
I'm
one
of
the
pmc
members
for
tmc.
Excuse
me
tvm,
we'll
start
the
meeting
with
just
if
there's
introductions
for
anyone
who
hasn't
attended.
One
of
I
guess
the
tvm,
or
maybe
the
microtvm
community
meetings
before.
If
anyone
wants
to
introduce
themselves
to
the
community,
say
hi,
see
where
they're
from
and
say
what
they're
interested
in
tvm
go
for.
It.
A
I
do
see
a
lot
of
familiar
faces
here,
so
you
know,
I
think
that
almost
everybody
on
the
call
has
been
I've
seen
before
so
yeah.
That
said,
we'll
kind
of
just
move
on
here
to
the
agenda.
A
So
just
right
now
we
have
the
uma
accelerator
interface
and
that's
something
that's
brought
up
by
michael
kleiber
and
and
some
colleagues
that
at
university
of
munich,
as
well
as
at
bosch
and
as
well
as
then,
if,
if
time
permits
I'd
like
to
also
bring
up
this
remove
code
owner's
rfc
that
kind
of
affects
code
review
for
everyone.
A
As
far
as
announcements
and
news
goes,
I
don't
think
I
have
anything
super
specific,
although
I
do
want
to
congratulate
leandro
for
being
promoted
to
the
pmc,
so
great
work
and
we're
happy
to
have
you
and
and
excited
for
future
contributions.
Thank
you
very
much
yeah.
A
So
with
that,
I'd
like
to
move
on
to
the
umo
accelerator
interface-
and
I
guess
I'd
like
to
turn
it
over
if
this
is
the
the
discuss
thread
here-
that
has
started
the
discussion
and
you
know
we
have
our
our
image
reference
here,
and
so
I
don't
know
if
mike
or
one
of
the
folks
behind
this
wants
to
give
a
little
overview
of
the
proposal
here,
and
I
can
also
have
to
add
context
too,
as
well
as,
if
that's
helpful
hi.
Can
you
hear
me?
B
B
C
I
hope
I
didn't
screw
up
the
zoom
link
or
anything
like
that.
Yeah
so
give
us
a
few
more
minutes.
B
A
Problem
anyone
else
have
trouble.
Should
I.
D
Well,
I
think
I
think
one
of
the
things
that
can
happen
is,
if
you
have
a
zoom
account
and
you're
logged
into
it.
When
you
bring
up
the
url
what'll
happen
is
get
presented
with
a
screen
to
say
that
you
should
sign
in
as
the
moderator
and
then
there's
a
link
underneath
that
and
like
kind
of
a
fairly
small
font
that
that's,
where
you're
supposed
to
click
to
actually
go
into
the
meeting.
And
so
it's
really
easy
to
miss
that
nice.
D
A
A
Okay,
well
great
job
on
my
part
in
setting
this
all
up
hello,
hello,
hey
mike
how's,
it
going.
A
Sorry
about
that,
I
must
have
oh,
I
see
I
see
interesting
okay.
Well,
hopefully,
that
new
link
solves
the
problem
for
everyone
not
sure
what
happened
with
the
whole
one.
A
So
we
were
actually
we
just
kind
of
started
along
our
agenda
a
little
bit
and
apologies
for
the
difficulty
in
joining
here,
but
we
had
kind
of
gone
along
to
the
point
where
we
were
gonna
start
bringing
up
the
accelerator
interface.
I
wasn't
sure
if
you
wanted
to
give
a
brief
kind
of
overview
or
some
background
on
the
proposal.
A
I'm
also
happy
to
add
context
here
as
well.
Just
wanted
to
make
sure
that
I
just
wanted
to
see
if
you
wanted
to
kind
of
discuss
kind
of
rationale
and
and
kind
of
the
goal
and
all
that
and
go
from
there.
F
Absolutely
can
I
somehow
share
my
screen.
Yeah.
A
Sure,
let
me
let
me
unshare
mine,
sorry,
where
where's.
F
F
From
zero,
so
basically
a
group
of
people
which
are
mentioned
here
so
mostly
from
germany,
so
powell
kristoff
from
tubingen
and
myself
ingo
from
bosch,
philip
raphael,
daniel
from
munich
and
johannes
from
munich.
We
all
had
kind
of
the
same
goal
or
problem.
How
else
you
how
we
want
to
how
we
want
to
bring
it,
so
we
wanted
to
integrate
an
accelerator
into
tvm
and
we
saw
so
yeah.
There
are
a
couple
of
ways
how
this
has
been
done
in
the
past,
like
the
esos.
F
U
is
a
really
good
example
of
it.
Vita,
of
course,
is
really
cool
and
we
thought
yeah.
How
can
we
somehow
share
synergies?
How
can
we
save
some
of
the
workload
and
because
we
are
quite
a
people,
a
number
of
people
here
we
thought
why?
Don't
we
put
our
efforts
together
and
try
to
define
something
that
we
can
use
in
common
and
that's
how
we
came
up
with
a
first
version
or
the
idea
of
uma,
which
is
a
universal
modular
accelerator
interface?
F
So
the
idea,
basically
is:
how
can
I
bring
an
accelerator
easily
into
tvm,
so
the
goals
here
are,
as
I
said,
easy
integration
and,
in
our
case,
first
of
external
hardware
accelerators.
So
what
do
we
mean
by
external
accelerators
like
everything
that
is
not
in?
That
is
not
directly
in
the
processor
pipeline?
F
Sorry,
and
what
does
this
include?
This
includes
a
couple
of
apis
to
hook
into
tvm
glass
infrastructures
and
finance
infrastructures,
because
we
saw
for
the
previous
approaches
of
x
accelerated
integration.
This
was
done
different
from
one
accelerator
to
the
next
and
the
motivation
behind
this
is,
I
mean
we
see.
F
F
So
in
our
previous
discussions
I
mean
you
mentioned
in
the
post
as
well.
We
so
with
andrew
and
mark
together
with
the
other
people
mentioned
before.
We
already
had
a
high
bandwidth
discussion
on
how
this
could
be
done,
based
on
the
first
posts,
and
we
came
up
with-
let's
say
an
intermediate
idea
on
how
this
could
be
done,
and
this
is
what
we
also
want
to
discuss
with
the
community
today.
F
F
F
So
a
short
learning
period
should
be
together
with
such
an
easy
and
stable
api,
so
the
second
layer,
then
it
would
be
plumbing
layer,
so
maybe
andrew
you
can
help
me
here
a
little
bit
from
my
understanding.
This
was
a
collage
like
api.
That
will
will
is
still
to
be
integrated
into
tvm
plus
other
tvm
apis,
and
this
is
therefore
way
more
powerful
api
connected
to
the
core
compiler
and
the
target
audience
is
really.
It
was
it's
really
experienced
users
and
it
is
c
plus
plus
and
python
yeah.
Maybe.
A
Yeah
yeah,
I
mean
that's,
that's
that's
kind
of
what
we're
talking
about,
but
maybe
I
can
just
add
a
little
bit
more
detail
here.
There
are
a
couple
different
pieces
of
this
of
this
proposal
and
some
of
them
involve
code
generation,
and
some
of
them
involve
graph
partitioning
and
some
of
them
involve
middle
compiler,
passes
and,
and
the
proposal
essentially
is
to
unify.
Oh,
you
can
keep
your
screen
share.
If
you
want
mike,
I
sorry
about
that.
A
The
proposal
essentially
was
to
to
unify
all
of
these
different
pieces,
which
are
kind
of
the
common
touch
points
that
you
have
when
you're
trying
to
integrate
an
accelerator
behind
some
some
porcelain
and
so
kind
of
the
idea,
then,
is
to
kind
of
look
at
what
the
common
kind
of
lower
level
apis
or
interfaces
are
that
people
exploit
there
at
the
compiler
level
and
then
make
the
porcelain
wrap
those
essentially,
and
so,
when
it
comes
to
the
topic
of
kind
of
graph
prediction,
we
were
kind
of
discussing
about
trying
to
make
sure
that
at
least
the
way
that
things
are
recorded
on
the
ir
module
here
is
is
similar
to
what
we're
doing.
A
Today,
and
in
fact,
actually,
we
one
of
the
questions
we
had
raised
at
the
beginning
of
the
proposal
was:
are
you
guys
proposing
to
do
to
introduce
yet
another
partitioning
flow?
And
the
answer
is
no.
A
We
just
want
to
sort
of
wrap
the
existing
partitioner
in
an
api
and
and
so
then,
as
efforts
like
collage
get
further
along
to
the
point
that
they're
sort
of
rfc
to
the
community
level,
you
know
the
the
migration
path
will
be
the
same
for
accelerators
integrated
using
luma
as
they
are
for
most
of
the
accelerators
in
the
codebase
today
that
use
kind
of
the
existing
the
existing
partitioning
flow.
So
I
would
say
collage-like,
but
really
it's
more
like
for
for
all
practical
intensive
purposes.
A
Today,
it's
more
like
using
the
same
partitioning
flow,
that's
currently
using
the
compiler
now
so,
hopefully
that
clarifies
a
little
bit
there.
F
Yep
totally
makes
sense,
so
basically
I
mean
this
is
what
andrew
just
mentioned,
so
this
is
top
level
chart
where
uma
would
hook
into
the
tvm
pipeline.
So
basically,
all
that
is
yellow
or
orange
here
is
where
it
will
hook
in
so
uma.
Partitioner
is
basically
just
using
the
existing
partitioner
and
wrap
it
into
a
nice
porcelain
api.
This
is
what
andrew
just
mentioned,
and
uma
pipeline
is.
I
will
show
in
the
next
slide,
is
basically
the
steps
to
go
for.
F
To
my
pipeline,
my
pipeline
has
a
couple
of
I
mean
this
is
a
proposal
how
it
could
be
done.
So
the
idea
is
going
from
the
composite
patterns
through
uma,
lowering
step,
which
is
basically
an
implementation
of
the
relay
to
tier
paths
with
that
has
already
been
proposed
in
our
rc10.
So
it's
one
special
implementation
of
it,
and
it
has
the
components
that
you
can
register
your
own
primitives
here.
You
can
also
use
topi
primitives,
so
it
is
similar
to
what
the
ethos
you
rfc
has
been
done.
F
It's
just
a,
I
would
say
a
generalized
and
formalized
way
how
it
could
be
done
for
a
bigger
number
of
accelerators
going
here.
The
first
step
is
to
go
to
execute
the
tvm
lowering
steps
resulting
in
stir,
and
here
it
will
be
possible
to
have
a
hook
for
executing
uma
schedules,
so
accelerator
specific
schedules
and
accelerator
specific
passes
that
can
be
registered
specific
for
the
user's
accelerator.
F
All
of
this,
then,
is
resulting
in
nstir.
That
includes
also
tr
extern
calls
and
can
be
called
into
a
default
library
of
an
accelerator
and
last
it
would
be
cojon
or
the
last
part
of
the
proposal
would
be
a
cojon
part.
F
So
here
it
could
be
possible
to
have
a
specialty
of
the
c
code
gen
in
particularly
so
in
particular,
we
think
of
a
python
interface
into
c
code
gen,
so
that
yeah
also
from
the
user
level,
modifications
to
visitors
and
to
and
small
notifications
to
c
code
can
be
made,
and
I
mean
in
our
discussion
with
andrew
and
mark
and
the
cogent.
The
coaching
part
was
already
a
bit
controversial
whether
we
should
keep
it
in
here.
So
this.
I
think
this
is
what
we
should
have
up
for
discussion.
A
Yeah
definitely,
I
think
I
wanted
to
talk
a
little
bit
about
kind
of
the
the
hooks
that
we
should
make
available,
essentially
kind
of
in
the
orange
boxes
that
would
hook
into
the
orange
boxes.
I
wanted
to
solicit
like
feedback
and
and
thoughts
from
the
community
about
yeah.
Just
I
mean
there
are
lots
of
options
in
tbm.
As
far
as
we
can
add
an
accelerator,
but
you
know
presuming,
we
add
kind
of
a
you
know,
a
higher
level
accelerator
porcelain
here.
A
What
are
the
kinds
of
things
that
you'd
like
to
what
kinds
of
passes
you'd
be
able
you'd
like
to
be
able
to
run?
What
are
the
kinds
of
schedules
you'd
like
to
be
able
to
define-
and
you
know
essentially
just
I
think
the
cogen
part?
Actually
I
don't.
I
don't
know
if
that's
like,
I
think,
there's
maybe
some
question
about
how
we
should
implement
that,
but
I
think
that
might
be
just
be
a
straightforward
wrapping
of
tier
to
runtime.
A
Just
so
long
as
the
the
first
two
things
are
are
not
are
kind
of
resolved
in
a
non-controversial
way.
So
that's
something
I
wanted
to
talk
about
for
discussion,
but
should
we
do
do
you
want
to
finish
your
presentation
here
and
then
we
can
open.
F
I'm
also,
I
just
have
two
snippets
as
an
example,
and
maybe
if
paul
is
in
the
call,
maybe
he
want
to
take
over
here.
G
Yes,
I'm
here
yeah
yeah.
I
can
just
give
a
quick
overview
here.
We
updated
on
the
feedback
we
already
received
in
the
discussion
a
little
bit
of
a
code
and
then
the
the
top
level
api,
basically
and
wrapped
it
all
into
the
human
back
end.
Basically,
you
were
back
in
this.
Our
parent
class
here
which
we
need
to
inherit,
and
then
we
can
just
use,
for
example,
ultra
trail
back
end,
which
is
our
accelerator,
which
we
are
using.
G
Yes,
as
a
proof
of
concept
to
to
try
this
things
out
at
the
moment,
and
what
we
can
see
here
is
that
we
have
these
these
different
levels
of
of
registration,
of
different
things
and
the
first
one
would
be
relate
relay
function,
registrations
which
is
basically
registering
patterns
for
the
pattern
matching
and
registering
passes,
which
are
then
executed
in
in
a
relay
to
relay
pass.
G
G
G
Maybe
I
want
to
do
these
passes
before
there
has
been
the
partitioning
or
after
the
partitioning,
for
example,
and
those
are
the
things
for
the
for
the
relay
to
relay
parts
or
pattern
registration
and
passes,
and
then
there
comes
the
relay
to
tir
register
registrations
where
we
have
operator
strategies
which
can
be
registered,
for
example,
if
at
the
moment
someone
has
a
custom,
tensor
expression
and
wants
to
integrate
this
into
the
flow,
this
can
be
done
on
this
level,
and
then
there
are
the
schedules
and
tir
passes
similar
to
what
was
shown
in
the
picture
before
so
we
can
have
custom
tlr
schedules
which
I
applied
and
we
can
register
multiple
of
them
and
then
there
are
dir
passes
again
with
different
stages
in
the
lowering
process
where
they
are
hooked
in
and
in
the
end,
this
is
currently
highly
under
development.
G
This
is
currently
the
the
idea
we
are
coming
from
yeah
and
that
this
is
all
basically
you
have
to
do,
and
then
this
is
a
little
snippet
how
it
can
be
used.
The
idea
is,
basically,
you
have
your
front
end.
G
You
insert
a
module
in
tbm
and
then
you
have
one
or
multiple
back
ends
and
you
can
register
them
using
using
this
code
in
line
three
and
four
and
use
the
partitioning
currently
which
calls
the
the
standard
tvm
partitioning
and
then
it's
just
a
relay
build
and
everything
was
registered
by
the
back
end
or
by
yuma
in
this
case,
and
it
hooks
into
the
relay
build
using
the
normal
tvm
api
to
finally
generate
a
in
this
case
c.
Runtime
code.
A
Yes,
okay,
it
seems
like
my
zoom
client
has
froze,
but
I
can
still
use
spacebar
to
talk
to
you
guys,
so
I
can't
see
what
anyone's
doing,
but
I
can
at
least
talk
great
thanks
for
the
great
overview
so
yeah.
A
What
I
wanted
to
do
was
just
I
mean
I
I
don't
mean
to
take
away
the
mic
from
from
you
guys
if
you
were,
I
have
some
more
to
say,
but
I
just
wanted
to
discuss
a
little
bit
about
kind
of
the
different
scheduling
hooks
that
you
guys
wanted
to
to
be
able
to
provide.
I
think,
there's
kind
of
a
question
of
whether
or
not
we
provide
scheduling,
hooks
sort
of
prior
or
sorry.
A
Sorry,
I
want
to
talk
about
the
different
compiler
passcodes
that
you
want
to
provide.
So
I
think
there's
you
guys
have
already
motivated
having
kind
of
relay
passes
here.
You've
motivated
having
tr
passes,
and
then
I
think,
if
I
recall
correctly
from
the
call
there
was
maybe
some
desire
to
have
some
like
communication
between
the
two
different
passes.
A
But
I
didn't
know
if
you
guys
wanted
to
elaborate
between
that
and
then
I
kind
of
wanted
to
open
it
up
and
see
what
the
community
thought
as
far
as
like.
If
there
are
other
things
that
might
be
missing
here
or
if
this
seems
like
sufficient
as
a
kind
of
a
v1,
and
we
should
try
to
implement
it
or
you
know
this
seems
to
be
a
good
idea
or
a
bad
idea
just
to
get
generally
gather
everyone's
thoughts.
F
Okay,
maybe
first
on
the
motivation
that
you
mentioned
between
the
schedules.
So,
basically,
what
we
see
is
that
the
primitive
that
is
implemented
as
a
as
a
custom,
primitive
always
or
can
often
have
a
relation
to
accelerator,
specific
schedules
or
accelerator
specific
passes
and
also
relation
to
the
code
gen.
So
these
are
the
things
that
we
see
that
are
tightly
related
and
can
interact
with
each
other
in
this
pipeline
here
and
that's
why
we
think
that
these
three
hooks
are
needed.
A
Yeah,
sorry,
I
think
that
makes
sense
to
me
remember
to
hold
spacebar
now
yeah.
I
wanted
to
gather
some
feedback
from
everyone
else
and
see.
I
don't
know
if
the
arm
folks
have
any
thoughts,
having
kind
of
blazed
this
trail
before
or
if
there's
you
know
things
that
seem
like
they
might
be
missing
or
misplaced
here
or
if
anyone
else
has
any
thing
they
want
to
contribute
here.
E
Yeah,
I
can.
I
have
a
few
questions.
I
think
overall
work
looks
good.
Anything
is
going
in
the
right
direction
by
structuring
the
registration
of
the
passes
to
support
an
accelerator.
E
So
the
first
question
I
had
would
be:
would
the
v1
of
this
would
support
a
tensor
expression?
Te
that
is
obtained
from
topi
or
is
it
harvey,
is
keeping
that.
F
G
Yeah,
maybe
I
can
add
to
this
yeah
we
we
are
from
our
side,
had
a
big
interest
in
going
directly
to
to
tir,
but
we
realized
that,
but
we
are
using
basically
topi
and
lowering
this
one
at
the
moment
through
the
standard
lowering
similar
to
what
is
also
done
in
the
ethers.
U
and
lowering
this
to
schedulable
tir,
and
at
this
point
we
also
are
supporting
the
injection
of
custom,
tensor
expression,
so
custom
te
in
the
flow
as
long
as
this
is
still
part
of
the
the
main
lowering
in
tbm.
A
Yeah,
so
I
guess
one
question
is,
then:
are
you
guys
sort
of
invoking
this
te
compiler
from
from
your
flow,
or
is
that
is
the
idea
that
you
run
a
pass
and
kind
of
submit
the
te
into
ir
module
and
then
let
the
standard
flow
invoke
it
from
there.
I
guess.
G
E
Yes,
yeah,
I
kind
of
follow
up
on
that
so
see
the
proposal.
There
is
the
explicit
differentiation
between
sto
and
nstr.
Would
they
appear
as
different
hooks
in
this
design?.
E
So
I
guess
my
question
is:
will
this
particular
pass
the
accelerator
specific
lowering
contribute
back
next
year
to
the
call
compiler
or
will
it
is
their
ambition
to
contribute
the
sta
back
also
to
the
compiler
for
some
reason
sometimes
you'll
see
meta?
Should
you
well.
G
Yeah,
it
was
from
your
from
your
question
as
well
in
the
yes
discussion
yeah.
I
think
it's
at
the
moment
a
bit
misleading
how
it's
drawn
here.
In
our
you
know
our
graph,
so
s
tier
will
be
worked
on
by
by
schedules,
and
this,
of
course
returns
st
as
well,
and
these
passes,
which
are
currently
like
in
the
box
behind
the
schedules,
are
passes
that
are
injected
into
the
tvm
lowering
through
the
past
context,
and
so
it's
so
these
passes
do
not
return
as
tier.
G
They
are
part
of
the
basically
part
of
the
lowering
from
st
to
nsd.
We
are
calling
at
the
moment,
tbm
lower
and
are
injecting
like
the
passes
that
are
registered
on
this
level
into
this
tvm
lower.
E
E
I
think
that's
not
not
likely
to
going
to
happen.
I
have
another
question,
but
I
would
want
to
cure
some
others
in
order
to
have
a
chance.
A
Yeah,
I
mean
go
for
it.
I
think
I
think
that's
not
useful.
Just
to
clarify
the
last
point.
You
know
you
just
wanted
to
ask
like
it
seems
like.
A
Currently
it's
focused
around
just
working
on
standard
tier
now
and
perhaps
as
the
tensor
ir
kind
of
matures.
Sorry,
if
I
got
that
last
explanation
wrong,
but
as
the
sensory
arm
matures,
then
perhaps
we
could
think
about
injecting
that
instead
of
te
or
something
like
that
further
up
the
pipe,
but
does
is
that
kind
of
does
that
kind
of
match
what
you
guys
were
saying
and
and
is
that
what
manuka
was
asking
for.
E
Yeah,
I
I
think
in
a
sense
yes,
so
I
guess
I
was
looking
so
sorry.
You
know.
There's
your
pipeline.
We
currently
leverage
g
e
and
t
share
deliberatives.
I
was
trying
to
see
whether
we
could,
I
don't
know,
not
commit
into
anything
but
extra
the
possibility
of
using
this
interface
yeah.
That's
that's!
That's
the
reason
for
the
question,
but
it
seems
like
the
first
step
in
this
flowering
flow
is
to
get
away,
get
rid
of
te
and
get
to
st
as
soon
as
possible.
A
I
see
so
it
would
be
more
helpful
for
like
ethos
to
if
we
were
going
to
explore
essentially
using
that
would
do
have
a
way
essentially
to
emit
te
and
and
then
operate
on
that
as
a
pass.
There
right.
A
So
I
think
that
could
maybe
be
added
as
just
a
separate
pass
registration
is
that
does
that
seem
right.
G
I
mean
te
is
currently
supported,
so
so
this
is
the
the
custom
primitives
that
are
showing
here
at
the
execution
lower.
So
you
can
inject
your
own
custom,
tee.
G
But
yes,
and
as
long
as
this
is
a
valid
step
in
tvm
and
it's
not
replaced
by
by
the
tir
or
the
the
relax
ambitions
here,
this
will
be
part
of
yuma
as
well.
G
E
Yeah,
okay,
so
so
the
last
question
I
think
hopefully
last
was
the
one
that
I
had
to
ask
was
something
that
we
already
dealing
with
related
tier
hooks
in
rfc
10,
here,
it's
kind
of
figuring
out
a
lowering
order,
especially
when
it
goes
from
related
here
and
which
might
not
necessarily
match
with
the
partitioning
order.
E
So
the
reasoning
for
this
comes
from
the
fact,
for
example,
in
datasheet
world
we
would
like
to
see
memory
available
after
cpu
functions
have
been
compiled
before
we
compile
it
as
u
so
it
kind
of
we
are
kind
of
exploring
the
possibility
of.
Can
we
lower
the
c
functions
first
before
those
two
functions
are
lowered,
any
any
thoughts
on
that,
whether
this
interface
could
help
with
that.
E
E
F
E
G
Anybody
I
mean
at
the
moment
we
are
once
everything
is
partitioned.
We
are
calling
relay
build,
so
there
is
no
ordering
anymore
there
just,
but
what's
done
in
the
build,
so
yeah.
E
Why
do
you
need
this
monopod?
Why
would
you
need
this
so
says?
As
far
as
I
understand,
related
tf
hooks
takes
the
full
ir
module,
which
not
only
includes
accelerator
functions.
It
also
includes
the
default
c
target
functions
in
this
case.
So
when
we're
doing
the
mutation,
the
ordering
kind
of
matters,
because
the
latter
one
has
more
information
than
what
goes
in
first.
A
Okay,
yeah,
could
you
sorry
could
you
clarify
a
little
bit
more
there
you're
saying
like
when
you're
mutating
the
when
you're,
when
you're
creating
this
ethos
use
schedules
you
want
to
what's
the
reason
you
guys
need
to
know
the
exact
memory
requirements
from
the
rest
of
the
graph.
E
A
I
see
okay
makes
sense,
yeah,
okay,
so
yeah.
So
one
of
the
things
that
we
kind
of
encouraged
with
this
proposal
to
start
with
was
using
sort
of
target
hooks
as
a
way
to
register
sorry
using
the
target
registry.
I
think
that
was
kind
of
proposed
in
the
related
tier
hook
as
a
way
to
kind
of
register.
A
The
register,
like
the
the
various
hooks
here,
and
so
maybe
we
could
explore
whether
there's
a
way
to
encode
some
kind
of
priorities
at
the
target
level
as
well,
maybe
a
little
bit
tricky
because
it
might
make
composition
a
little
bit
trickier,
but
on
the
other
hand,
if
it's
kind
of
a
flow
design
for
a
specific
like
hardware
accelerator
that
would
be
used
in
a
particular
soc.
A
With
this
you
know,
kind
of
the
back
ends
are
kind
of
all
pretty
well
established
for
that
soc
it
might
mean
that,
like
the
priority
levels
amongst
the
the
back
ends,
that
would
be
enabled
at
any
given
time
wouldn't
be
likely
to
conflict
or
or
wouldn't
have
that
problem.
Would
that
maybe
be
a
way
of
resolving
this.
E
Yeah
yeah,
I
guess,
if
we
can
take
it,
take
chat
a
bit
on
the
forum
yeah.
It's
not
that
simple,
because
this
order
can
so
it
has
a
degree
of
freedom
that
order
can
be
interpreted.
I
mean
the
optimal
lowering
flow.
The
orders
need
to
be
interpreted
differently
at
different
hoops.
That's
the
complexity.
A
Maybe
we
can
follow
up
with
that
part
on
the
forum
with
some
more
detailed
kind
of
overview
and
all
that.
A
Okay,
are
there
any
other
questions
about
this,
or
does
anyone
want
to
propose
any
other?
I
was
just
curious
if
there's
any
other
folks
in
the
community
that
might
have
explored
accelerator
integration
before
and
kind
of
wanted
to
ask
if
there
was
any
missing
features
or
or
how
can
we
fit
this
in
with
our
efforts
or
anything
like
that,
give
a
second
here
if
anyone
wants
to
bring
anything
up.
H
Can
I
ask
a
question
sure
I
think
yeah,
first
of
all,
yeah
thank
you
for
the
exciting
proposal.
This
is
very
interesting.
H
Personally,
I'm
not
very
familiar
with
the
accelerator
passes
so
like
this
can
be
like
a
very,
very
basic
question,
but
like
does
every
isolator
go
through
the
same
sequence
of
passes
or
is
there
any
like
you
know,
specific
special
passage
can?
Can
there
be
a
special
path
for
certain
accelerators.
A
Yeah,
so
I
mean
I
can
kind
of
take
this
and
and
folks
who
have
also
worked
on
this
feel
free
to
chime
in
here
as
well
yeah
in
general,
we
we
don't
have
a
specific
set
of
registered
passes
and,
and
also
this
proposal
isn't
necessarily
trying
to
like
box
everyone
into
to
using
a
particular
like,
like
one
particular
flow.
A
But
what
is
challenging
with
tvm
is
that
there
is
a
lot
of
choice
in
in
the
way
that
you
might
want
to
go
about
implementing
well,
almost
any
sort
of
processing,
pipeline
or
compilation
pipeline
on
top
of
a
relay
graph,
and
there
are
some
common
touch
points
that
are
actually
helpful.
If
you
kind
of
can
can
reuse,
they're,
actually
kind
of
the
the
common
touch
points
that
are
mentioned
as
the
the
sort
of
the
plumbing.
I
guess
of
the
apis
here.
A
One
of
them
is
the
the
part
that
divides
or
partitions
the
graph
between
an
offloaded
portion
and
sort
of
a
portion.
That's
compiled
using
kind
of
a
target
host
flow
or
essentially
compiled
for
a
cpu.
A
The
goal
with
this
proposal
is
basically
to
collect
all
of
those
common
touch
points
together
into
a
single
api
so
that
at
least
it's
you
know,
it's
not
going.
It's
not
attempting
to
sort
of
box
people
in
here,
but
the
idea
is
that
it
at
least
kind
of
provides
a
path
that
that's
kind
of
like
a
way
to
get
started
and
and
then,
as
you
need
to
deviate.
Obviously
you
can
then
dive
deeper
beyond
the
porcelain
into
the
plumbing.
A
If
you
need
to
maybe
I'm
missing
some
other
parts
that
others
want
to
chime
in
here
as
well,.
F
I
think
it
was
a
pretty
good
summary
of
the
intention
here
so
yeah
I
mean
I
wouldn't
see
that
there
is
one
or
two
really
special
schedules
or
primitives
for
accelerators,
but
rather
I
mean
I'm
coming
from
the
hardware
side.
As
a
hardware
engineer,
you
think
how?
How
would
I
want
the
software
to
use
my
accelerator
and
that's
how
you
build
your
passes?
A
Right,
yeah
yeah,
that
makes
sense
cool,
okay,
any
other
questions
from
the
community
or
things
that
anyone
wants
to
raise
here.
I
Yeah
good
question:
yes,
hi
hi
everyone
here
federico
also
from
from
germany.
I
am
also
right
now
fairly
new
to
tvm.
So
this
also
might
be
a
simple
question,
but
I
have
been
working
on
integrating
an
accelerator
of
my
own
and
I
noticed
the
vta
uses
this
kind
of
memory,
information
regions
to
declare
scopes
for
buffers
for
buffers
that
are
not
in
the
main
memory
that
are
inside
the
accelerators
internal
memory.
I
Let's
say
block
rams
or
scratch
pads
or
so
on,
and
I
have
been
wondering
if
you
have
thought
about
implementing
these
kind
of
apis
to
register
this
memory
regions
in
the
uma.
F
Yep
thanks
for
the
question,
so
I
mean
this
would
be.
Let
me
try
to
share
again,
so
this
would
be
exactly
the
hooks,
for
I
mean
where
the
schedules
and
passes
can
be
brought
in,
I
mean
for
the
vta.
You
have
pretty
specific
schedules:
how
layout
how
internal
scopes
are
handled,
and
I
think
where
you
could
bring
this
in,
would
be
by
writing
schedules
and
passes
together
with
if
you
need
custom
primitives
for
your
accelerator.
E
A
E
Yeah,
so
I
think,
adding
on
to
what
kyle
said,
I
think
that's
right.
So
if,
when
you
have
the
freedom
to
get
get
your
own
scheduling
passes,
I
think
the
storage
scope
is
the
way
we
kind
of
use
that
so
local
tech
storage
scope
usually
indicates
that
the
target
primitive
function
has
this
internal
memory
so
use
simply
the
infrastructure
memory.
E
Planner
plays
a
role
if,
if
the
accelerator
shot,
you
have
a
shared
memory
model
where
certain
memories
can
both
be
accessible
by
cpu
and
accelerator,
in
which
case
you
can
decline
to
be
still
global.
However,
usmp
has
the
feature
of
specified
access
which
targets
can
access
which
pulls
so
in
the
end,
there
would
be
a
workflow
workspace,
full
generator
that
you're
supposed
to
place
it
in
the
accessible
memory
by
both
cpu
and
the
accelerator.
If
that's
something
the
accelerator
loves.
A
Yeah,
if
not,
we
can,
I
think
we
probably
just
have
eight
minutes
left
before
the
top
of
the
hour,
and
so
I
won't
dive
into
the
code
owner's
thing
with
with
that.
Only
eight
minutes
left,
I
think
so
perhaps
we
can
wrap
up
then,
if,
if
that's
that's
all
the
discussion
to
be
had
going
once.
J
Going
twice,
I
will
just
say
about
the
code
owners
that
the
rfc
is
on
the
tdm
rfc's
repo.
If
anyone
wants
to
look
at
it
in
the
meantime,.
A
Yeah,
maybe
we
could
give
a
brief
like
one
minute
plug
for
it,
or
something
like
that.
I
had
a
couple
tabs
if
I
was
going
to
show,
but
I
can
now
no
longer
use
zoom
for
my
computer,
so
I
will
not
do
that
somehow.
I
seem
to
still
be
able
to
talk
to
you.
A
So
one
of
the
problems
we
have
right
now
with
reviewing
prs
is
that
we
adopted
this
code
owner's
mechanism
from
github
last
year
and
that
sort
of
automatically
requests
reviews
from
from
folks,
depending
on
the
sort
of
code
paths
that
are
touched
in
the
tdm
repo.
Unfortunately,
what
that
does,
though,
is
because
of
the
way
tbm
is
organized.
It
means
that
the
same
set
of
core
committers
get
blasted
for
every
single
pr.
A
That's
not
every
single
pr,
but
many
of
the
pr's
that
are
raised
even
quite
simple
pr's
and
it
becomes
very
difficult
to
figure
out
who's
who's,
owning.
What
and,
and
who
is
sort
of
should
be
following
up
on
on
which
pr,
as
well
as
kind
of
sort
through
the
the
github
review
spam
that's
coming
into
to
your
inbox.
And
so
we
want
to
get
away
from
this
to
make
it
more
possible
for
for
folks
to
to
review
prs
and
so.
A
I
know
sorry,
I
think
it
times
me
out
after
a
little
while
anyway
there's
a
proposal
up
that
basically
explains
sort
of
motivates
a
new
way
to
sort
of
assign
reviewers
via
mentioning
them
in
the
pr,
by
using
cc's
and
kind
of
a
way
to
ping
those
pr's
if
they
become
stale
like
if
there's
no
traffic
for
a
week,
for
example,
so
I'd
encourage
everyone
in
the
community
to
take
a
look
at
that
it
can
might
influence
kind
of
how
we
all
review
code.
A
But
I
think
overall,
a
lot
of
the
core
committers
are
pretty
positive
on
this
proposal,
so
I
think
it's
likely
we'll
accept
it
and
if
there's
any
discussion,
it'd
be
great
to
have
that
discussion
on
the
rfc
or
the
discuss
forum.
So
how
about
we'll
we'll
give
a
plug
for
that
and,
as
always,
we're
recording
everything
or
taking
notes
and
everything
and
we'll
post
notes
on
the
discuss
forum
there
so
great
yeah.
A
If
that's
all,
I
think
we
might
call
this
meeting
a
wrap
and
again
we
kind
of
have
this
standing
time
slot
weekly.
We
may
not
meet
every
single
week,
but
if
there's
more
that
wants
to,
if
there's
anything
you
want
to
discuss,
please
post
it
up
in
the
agenda
doc.