►
From YouTube: ONNX Edge WG meeting 20191016
Description
Description
A
Thank
you.
I
was
just
saying
that
on
the
previous
meeting,
I
think
the
agenda
that
Megan
says
to
this
meeting
was
the
need
to
of
you.
They
stated
to
fork
because
the
current
statement
of
walk
were
already
sleeping
in
terms
of
deliveries
in
timelines,
so
we
should
probably
review
that
any
other
agenda
items.
A
Okay,
so
the
main
statement
of
walk
talked
about
describing
or
fangs.
Basically,
this
technical
fork
of
their
walking
goal
is
to
was
to
identify
to
classify
what
we
mean
by
edge
and
to
create
or
fangs
and
right
now,
look
I'm,
showing
the
part
that
talks
about
deliveries
and
those
underway
to
his
goals
and
milestones.
So
in
the
deliveries,
we
said
that
we
want
to
have
a
document
that
describes
the
edge.
A
C
A
A
A
A
Document
number
three
in
q3
of
2019
document
number
three:
was
they
defying
of
specific
offense?
So
we
definitely
off
track
here.
We
need
to
set
new
goals
to
define
a
poll,
facts
and
I.
Think
the
ring
issue
here
is
that
we
probably
don't
have
enough
people
attending
so
that
they
would
able
to
take
upon
themselves
to
define
profiles.
A
A
A
One
of
the
thing
that
they
saw
up
from
intern
suggested
was
that
these
profiles
can
only
also
be
used
to
set
execution
mode.
If
you
have
a
device
that
supports
a
wide
range
of
profile
may
say
this
device
says
that
it's
able
to
support
no
high,
so
I
need
high
profiles
of
video
classification.
Then
there
will
be
an
API
which
is
right
now
outside
the
scope
of
this
working
group.
That
would
allow
at
runtime
to
set
the
execution
mode
for
specific
model.
A
I
think
Minaj,
one
of
the
things
that
we
talked
on
over
the
workshop
is
defining
the
mechanism
to
query
which
profiles
are
supported
by
a
device,
so
all
of
it
can
go
like
the
original
scope
of
the
Vulcan
group
was
to
describe
profiles,
because
this
is
the
starting
point
from
this
definition
of
profiles.
Now
we
can
have
an
API
that
queries
profiles,
and
now
we
can
have
an
API
that
sets
a
profile
for
a
specific
modern
for
execution,
but
unless
we
describe
the
grouping
into
poor
finds,
the
subsequent
activities
cannot
happen.
B
So
as
as
the
device
evolve
or
as
Becky
walls
and
a
device
for
wearables,
there
is
opportunity
for
the
two
to
not
stay
in
sync,
so
the
latest
spec
and
the
data
types
and
changes
may
not
be
also
ordered
in
the
device
former
so
having
the
ability
to
identify
which
specific
profile
that
device
supports
will
provide
consistency
or
for
a
model
to
be
a
look
at.
You
know,
executed
or
a
graph
for
an
OP
to
be
executed.
On
that
note
versus
executing
it
only
on
the
CPU
in
software.
A
Yeah
I
go,
and
this
was
also
to
the
same
point.
This
is
an
issue
of
intuitive
ability.
If
you
talk
to
distribute
different
devices,
the
same
modern
and
you
won't
know
that
this
modern
works,
so
the
basic
building,
the
work
of
the
modern,
which
is
the
operators
inside
you
have
to
know
that
these
subtitles
are
supported
by
this
device.
C
B
A
So
now
the
question
becomes:
what
do
we
put
as
part
of
the
soul?
Why
do
we
put
this
part
of
the
working
group,
a
statement
of
work,
because
initially
the
statement
of
work
was
just
the
profiles
and
not
talking
about
any
subsequent
api's
that
use
the
poll
funds?
We
say
this
can
come
as
a
another
working
group
and
you
know.
A
A
Agree
it
can
be.
This
is
why
it's
a
good
idea
to
separate
between
the
two
porphyrins
our
profiles,
and
they
are
something
that
is
part
of
the
Onyx
specification
and
the
way
that
you
use
profiles
onyx
can
standardize
one
way.
For
example,
if
you
look
at
on
exif
I
that
can
be
one
way,
but
it's
the
same
way
that
the
onyx
file
format
is
not
dependent
on
the
index.
If
I
API
onyx
profiles
shouldn't
be
dependent
on
the
API
that
uses
them,
that's
my
opinion.
A
C
Think
what
I
would
like
to
better
understand
this?
How
these
static
profiles
would
apply
on
a
scalable
computing
device?
I
fully
agree
with
you
that
the
need
of
profiles
or
fixed-function
hardware,
like
security
cameras
or
speakers,
how
would
we
apply
and
make
it
relevant
or
scalable
computing
device
applies
personal
computers
which,
in
the
current
definition
of
the
edge
device,
is
describing
it
right.
How
would
we
make
it
relevant
for
those.
B
C
It's
a
little
thing
right,
so
I
can
say
that
a
PC
can
support
profile,
X
in
condition
Y
and
then
the
condition
changes
right.
Many
apps
running
simultaneously
a
lot
of
things
that's
going
on
in
that
environment
and
by
the
time
I
am
done,
saying
that
I
support
this
profile,
maybe
now
I,
don't
suppose
that
what
I
like
and
that's,
why?
Probably,
in
my
opinion
and
probably
need
some
form
of
profile
which
is
dynamically
and
having
the
runtime
better
understand,
you
know
this
is
what
are
the
needs
of
the
model,
so
it
doesn't.
A
C
A
So
that
can
happen
in
one
of
two
ways:
either
way
profile
is
part
of
the
modern
description
which
means
in
the
container
in
the
photograph
of
the
modern.
We
we
give
a
suggestion
to
extend
it,
so
there
will
be
an
optional
field
describing
the
profile,
the
newest
minimum
profile
required
to
earn
this
model.
A
That
would
be
one
way
in
the
other
way
is
by
an
accompanying
API.
When
you
load
the
modern,
you
also
describe
to
the
runtime.
What's
the
minimum
profile
required
and
then
the
rantin
can
say
yes
or
no,
but
I
think
again
will
we
need
to
decide
what
we
are
defining,
what
forms
into
definition,
which
is
part
of
the
UNIX
specification
and
what's
not
and
and
if
we
define
an
API,
the
Varnum
way
to
define
an
API.
Is
that
you're
actually
forcing
people
who
want
to
use
this
capability
to
do
it
in
one
specific
way?
A
A
B
It's
a
format
of
representing
that
graph.
So
are
we
saying
that
specific
graph
would
fit
into
one
or
many
profiles,
or
are
we
saying
the
box
that,
but
that
are
contained
in
the
graph,
would
would
fit
into
a
a
profile
one
or
mini
the
the
reason
I
ask
this
is
if
we
make
the
profile
data
part
of
the
onyx
model,
the
protobufs?
That
means
the
converters
will
have
to
be
aware
of
this
notion
of
profiles
and
be
able
to
identify
which
specific
profile
the
model
belongs
to.
A
B
A
A
A
A
This
thing
is
beyond
operators.
It's
looking
at
what
the
memory
consumption
that
executed
this
network
requires
too,
because
this
is
another
parameter
in
knowing
if
you
can
run
the
network.
So
to
your
question,
if
say,
one
of
the
ways
that
I
mentioned
earlier
was
to
come
with
a
suggestion
to
extend
the
port
or
the
basic
bottle
to
have
an
optional
field
which
describes
the
faux
fur
and
it's
optional.
You
don't
have
to
do
that
so
converters.
A
So,
even
if
we
do
this
suggestion-
and
we
extend
the
container
to
be
possibly
aware
of
what's
the
profile-
it
wouldn't
be
a
mandatory
thing,
I,
don't
think
it
would
be.
A
good
idea
to
put
is
mandatory
to
improbably
create
a
lot
of
resistance
from
people
who
are
trying
to
create
converters
because,
as
you
said,
what,
if
you
put
it
there
and
converters,
would
have
to
fill
it
there
now.
Converters
would
have
to
be
aware
of
the
different
profiles,
so
I
want
to
put
it
as
an
optional
fiend
and
not
as
a
mandatory
thing.
A
And
I'm
saying
it's
not
the
only
way
we
can
say
that
profiles
are
not
added
into
the
container
and
there
is
a
side
channel
that
implementation
needs
to
avoid
profile
information.
So
it's
not
part
of
the
container
definition.
I
think
both
options
are
on
the
table
and
to
me
it's
kind
of
a
second
level
of
details.
A
A
A
C
A
Yes,
yep,
and
the
idea
is
if
we
talk
about
the
terms
that
you
mentioned.
So
these
are
the
static
profiles
and
at
one
time
you
can
select
two
one,
the
modem
in
each
one
of
them
now,
I
think
what
you
described
is
a
dynamic
of
is
the
ability,
instead
of
a
set
of
discrete
values,
to
kind
of
have
a
continuous
scale
of
possible.
Let's
say
I
want
to
know
well,
no
latency,
so
to
be
able
to
specify
exactly
what
the
agency
that
you
want
or
to
be
able
to
specify.
A
And
the
idea
was,
let's
say:
if
you
choose
a
set
of
discrete
definite
sets,
you
may
end
up
with
something
like
just
following
a
number
20
profiles
or
fatally
filthy
profiles.
If
you
start
saying
that
each
one
of
these
vectors
can
be
described
separately
by
a
number
or
something
like
that
now
you
just
extended
the
possible
range
of
profiles
to
be
much
much
value.
A
Correct
it
would
describe
data
types
and
execution.
A
set
of
a
set
of
operators
is
driven
from
set
of
models
that
we
have
targets
this
profile
to
support,
but
yeah
I
agree
with
you
that
doing
compliance.
You
want
to
come
to
to
test
a
set
of
poor
files
which
are
static
and
discrete
in
their
attributes.
A
A
A
A
The
only
thing
that
is
governed
actually
those
two
things,
one
thing
which
is
governed
by
onyx
is
the
container
and
everything
all
of
the
tools
around
the
container
converters
validation.
All
of
these
things-
and
the
other
thing
is
the
modern
zoo
of
moderns,
which
are
combined
to
known
more
networks
and
our
kind
of
approved,
ratified
by
their
own
exposure
to.
A
There
was
an
attempt
to
standardize
an
API,
it's
called
alexa
phi,
some
implementations
use
it
some
don't
we
can
do
the
same.
You
know
we
can
it
is
it.
It
is
a
subsequent
working
group.
We
can
define
an
API
that
uses
the
profiles,
queries
the
profiles
able
to
set
attributes
based
on
the
attributes
of
the
profile
to
try
and
meet
higher
latency
sorry,
lower,
latency
or
higher
accuracy,
but
that
would
be
only
kind
of
an
example
code
or
recommendation.
A
B
A
B
How
is
one
thing,
but
today
we
do
not
even
like
I,
think
there
is
a
gap
that
that
we
do
not
have
a
defined
subset
of
opps,
that
a
hardware
is
optimized
to
write
and
that
that
can
be.
You
know
that
I
could
put
a
finger
on
and
say:
okay
once
the
hardware
is
complained
of
this
profile.
I
know
the
kind
of
kind
of
models
it
will
be
able
to
run
or
or
the
kind
of
the
nature
or
the
characteristics
of
the
hardware.
A
A
So
I'm
just
saying
that,
let's
say
that
you
have
a
mechanism,
that's
a
toe
on.
We
try
to
find
out
what
is
mechanism,
but
let's
say
that
you
have
a
mechanism
that,
if
your
implementation,
if
your
firmware
so
if
you
know
framework,
is
talking
with
the
device
X
some
type
of
a
CPU,
you
can
know
which
profiles
this
CPU
suppose
it
can
happen
in
one
of
two
ways:
either
there
is
some.
B
Yeah
I,
like
the
I'll,
the
query
mechanism
I
think,
is
going
to
be
an
option
or
a
choice
the
runtime
can
make.
But
the
idea,
then,
is
that
the
hardware
has
a
well-defined
boundary
right.
They
can
make
pincers
to
be.
You
know
optimized
for
a
set
of
set
of
profiles,
and
that
then
becomes
a
well-defined.
B
A
A
This
is
exactly
what
we
wanted
to
say.
We
wanted
to
say:
okay,
what's
inside
the
profile,
so
we
created
a
document
that
describes
what's
inside
a
profile
definition
and
then
the
next
step
would
was
to
try
and
create
a
template
or
an
example
of
a
profile
and
to
see
that
ever
they
are
good
with
this
definition
of
a
profile
and
then
go
and
start
creating
more
of
these.
That
was
supposed
to
happen.
That
was,
we
were
already
supposed
to
be
after
this
point,
and
so
far
we
haven't
got
there,
because
people
just.
A
B
B
A
A
A
So
initially,
when
we
talked
about
four
files,
we
thought
about
describing
a
functionality
of
a
device.
For
example,
it's
a
small
speaker:
oh
it's
an
IP
camera
and
then
say:
maybe
there
was
a
device
that
wants
to
be
both
a
smart
speaker
and
camera.
So
he
supposed
these
two
profiles.
But
then
we
came
in
to
kind
of
realization
that
these
definitions
are
not
good,
because
in
a
sense
what
happens
it
creates
too
much
combinations.
Basically,
it
doesn't
only
captures
the
edge
devices
are
not
that
clear-cut
of
functionalities.
A
B
A
A
A
So
maybe
this
is
something
that
we
want
to
do
is
one
maybe
come
up
with
kind
of
a
white
paper
describing
they
set
different
ways
to
describe
profiles
and
put
it
out
for
to
a
survey
for
people
to
see
what
people
fulfill
the
foundation
walking
group
got.
25
companies
answering
on
the
survey
I
will
be
happy
forgets
ten
to
answer.
A
A
A
So,
just
to
clarify
what
we
said:
you're
saying
that
document
number
four
about
collaboration
with
quantization
working
group
is
not
an
event
anymore
because
it
needs
to
be
they
operate
all
see
and
about
the
milestones
so
right
now.
Maybe
we
can
create
a
new
milestone
for
2019
q4
to
finalize
a
set
of
it
did
a
list
of
profiles,
and
then
we
can
say
that
we
can
start
describing
each
one
of
the
boffins.