►
From YouTube: Silk.NET Coffee & Code Catchups
Description
Join the Silk.NET team for a quick catchup. This is a more informal stream wherein we'll be discussing what we've been doing on the Silk.NET project, what we've been doing outside of Silk.NET, bouncing ideas off each-other, and (most importantly!) provides us an opportunity to answer any questions the community may have.
These streams are impromptu and the VOD will be unlisted as a result.
GitHub: https://github.com/dotnet/Silk.NET
Discord: https://discord.gg/DTHHXRt
Background music by HOME.
A
A
A
A
A
A
C
B
C
B
D
D
C
B
B
B
B
But
basically
this
is
just
an
opportunity
to
sit
down
and
have
a
chat
for
between
the
salt
team,
the
community
that
should
whether
that
be
silk
related
or
Not
Silk
related
generally.
We
do
try
to
keep
it
at
least
a
little
bit
on
topic,
but
graphics
and
the
programming,
but
other
than
that
yeah
and
it's
good
opportunity
to
match
up,
but
seeing
as
the
only
people
in
the
school
are
silk
people.
What's
everyone
be
doing
silkwise.
C
And
since
then
we
have
there's
been
a
PR
coming
in
for
more
tutorials
I
opened
a
PR
to
add
bindings
for
the
various
spear
V
related
libraries
and
tools
and
we're
also
working
on
redoing,
our
native
Library
building
to
be
a
bit
more
robust
and
or
platforms.
Hopefully,
and
the
Linux
libraries
should
work
on
more
distributions.
B
Suppose
I'm
working
on
well
yeah
today
is
it
is
what
usually
would
be
update
Friday,
but
we
stopped
the
monthly
updates
well
up
on
my
resignation
to
try
to
try
and
not
overload
the
few
remaining
maintainers,
so
I
guess
whenever,
but
it's
not
really
no
rush.
It
doesn't
even
have
to
be
on
a
Friday.
You
should
do
it
whenever.
D
D
B
B
C
B
Yeah
well
I
mean,
as
I
repeatedly
say,
build
tools
predates
silk.net
itself,
so
it's
been
passed
around
a
lot
of
people.
I
think
there
are
still
so
yeah
there's
some
bits
of
code
that
were
that
was
written
by
Jax
that
is
still
floating
around
in
there
somewhere
and
he's
never
worked
on
something
like
that,
so
other
than
the
opening
hours.
D
A
D
Think
they
plan
on
contributing
anything
or
you
know,
but
it's
still
nice
to
see
that
the
Kobe
is
apparently
usable
in
some
like
usable,
for
a
developer
to
like
work
with
and
which
is
I
mean
the
main
goal
of
people
know
right:
yeah
and
I
mean
I.
I
haven't
worked
much
in
it.
I
I
do
like
a
little
bit
of
a
you
know
like
a
few
changes
here
and
there
when
I
have
like
some
time
but
yeah
I
mean
I.
D
E
B
D
B
Yeah
yeah
yeah;
no,
it
is,
it
is
really
cool.
It
feels
like
we
do,
have
a
very
active
Community
as
well
right.
So
it's
certainly
more
than
when
I
first
started
working
on
silk
I
mean
silk,
had
a
lot
of
followers
from
open,
take
in
previous
iterations
of
the
library,
but
it
was
never
like.
Oh
yeah
lots
of
people
come
and
go
and
either
use
the
library
or
try
to
contribute
to
it.
I
mean
it.
B
D
Yeah
yeah
and
I
mean
like
for
for,
like
if
you're
like
you,
look
at
the
C
sharp
stack
of
like
a
silk
based
application.
Basically,
it
like
most
likely
it's
like
all
the
way
at
the
bottom
of
the
site,
there's
nothing
really
below
so
in
terms
of
C
sharp.
So
it's
really
awesome
to
like
see
that
there's
actually
quite
a
few
people
that,
like
care
about
this.
B
B
E
E
A
A
B
B
E
C
D
C
B
A
D
B
Strike
was
a
big.
There
are
a
few
projects
that
I'm
really
Keen
to
get
on
silk,
and
that
was
certainly
in
the
initial
days
of
silk
that
I
used
to
actively
push
for
that,
like
stride,
was
one
that
I
blocks
in
basically
immediately
because
well,
certainly
now
that
we're
both
in
the.net
Foundation
makes
for
all.
It
makes
sense
for
all
of
the.net
foundation
projects
to
talk
to
each
other.
D
B
A
C
D
D
B
C
C
D
D
D
B
Oh
yeah,
because
the
features
of
the
language
and
runtime
that
we're
using
seem
pretty
stable
now
because,
whereas,
if
you
look
at
the
2.0
we're
making
that
we're
making
the
first
previews
of
that
as.net
Source
generators
were
being
themselves
being
worked
and
function,
points
as
being
works
on
themselves.
So
we
were
very
much
bleeding
edge
and
it
did
hurt
us
a
bit.
B
D
C
C
C
D
B
D
B
A
B
Taken
the
AST
and
show
that
open,
then
it's
got
to
figure
out.
You
know
how,
because
no
one
will
make
a
perfect
AST
and
a
source
generator.
So
of
course
it's
got
to
try
and
figure
out
all
the
context
and
whatnot,
but
that's
that
would
still
be
better
than
just
just
pure
straight
up
with
the
sources
yeah
yeah
we've
got
to
oh
convert
it
to
a
string
and
then
parse
it
again
to
get
all
the
content
like.
B
A
D
C
D
C
C
E
C
D
C
B
E
C
B
D
C
C
One
of
their
examples
also
has
an
lovm
sub
module.
So
we
have
like
two
copies
of
lovm
the
entire
git
tree
and,
like
the
80
other
sub
modules,
with
tons
of
git
history,
too
angle
is
a
big
one.
Dawn
we
have
Dawn
as
a
sub
module
now
too,
which
is
massive,
so
like
kind
of
full
recursive,
I
I
think
it
would
help
a
lot
if
we
set
up
the
CI
to
only
clone
a
depth
of
one.
C
C
B
A
A
C
B
I
think
it's
I
think
it's
a
dual
core
machine,
because
I
remember
when
I
tried
to
paralyze
the
compilation
for
some
of
the
Native
binaries
and
silk
itself
to
be
fair,
it
actually
starved
the
thread
that
was
talking
to
GitHub
actions.
So
that's
that's
the
main
reason
why
we
need
the
self-hosted
runner.
C
C
A
C
D
I'm
assuming
I'm
using
the
wrong
table,
because
this
really
can't
be
I
mean
this
is
probably
wrong.
I
I
hope
that
this
is
wrong,
but
if
I'm
like,
if
I
understand
the
table
right
which
I
hopefully
don't
then
would
mean
that
running
it
once
for
90
minutes
and
capping
out
the
storage
costs
you
like
80
dollars
every
time.
Oh.
C
C
D
C
D
D
A
B
D
B
C
C
B
C
C
I
tried
it
recently
and
it
made
Ryder
suck
up
like
24
gigs
of
RAM
yeah
I'm,
not
surprised.
It's
Visual,
Studio
I
tried
it
on
my
dev
kit.
I
tried
to
do
Visual
Studio
on
the
full
Solution
on
my
dev
kit,
Visual
Studio
sucked
up
like
18
gigs
of
RAM,
then
crashed
yeah.
It's
bad
like
you'd
think
that
a
machine
with
32
gigs
of
RAM
and,
like
you
know,
a
decently
powerful
arm
CPU,
should
be
able
to
handle
at
least
opening
the
solution,
but
no
visual
studio,
just
flat
out
crashes,
Visual.
D
C
C
C
C
B
B
A
B
C
C
C
C
Probably,
however,
oh
wait:
okay,
wait,
yeah,
okay,
okay,
so
the
200
megabytes
is
mysqld
thanks,
calendar
reminders.
So
no
it's
not
shared
memory.
It's
literally
just
it
has
the
full
copy
of
MySQL
running
in
the
background
right.
Why
did
why
they
didn't
use
like
anything
else
like
sqlite,
for
you
know
for
like
a
reminder
system
I,
don't
see
any
other
calendar?
Okay,
it's
probably
just
something:
I
installed,
I
think
I
have
the
full
K
Suite,
but
yeah.
It
literally
just
has
a
MySQL
running
as
a
sub
process.
A
B
So
I
guess,
on
the
on
the
3.0
front,
I
mean
I'm
still
trying
to
play
around
with
my
generator
experiments,
I
mean
I
actually
trying
to
focus
on.
It
is
difficult,
but
I
I,
suppose
my
aim.
There
is
like
I'm
not
trying
to
I'm,
not
trying
to
rotate
development
or
anything
I'm,
literally
just
trying
to
experiment
with
okay.
Well,
what?
If
we?
B
What
if
we
made
a
3.0
generator
that
is
still
user
usable,
but
try
to
do
it
without
all
of
the
plugable
flexibility
stuff
the
3.0
like,
but
really
needs,
but
at
the
same
time
it
doesn't
lose
that
much
if
we
don't
have
it,
especially
if
we're
not
gonna
have
Source
generator
we've
gotten.
If
we're
going
to
have
a
source
generator,
then
yeah
we
kind
of
need
it,
but
yeah.
Really,
it's
just
for
me
to
get
my
ideas
of
what
3.0
should
be
off
out
of
my
head
and
onto
paper.
B
We
end
up
making
and
and
just
apply
our
morphs,
our
our
modifications
to
it
to
make
them
silky,
because
that
way,
this
is
something
that
Tanner
and
I
have
talked
about.
A
bunch
internet
well,
silt.net
and
terafx
have
very
different
goals,
but
right
now
the
apis
that
each
project
exposes
themselves
different
and
it'll
be
nice.
If
it
were
clear-cut
which
Library
you
should
probably
use
with
no
compromise
going
between
the
two
so
and
terrafx
is
very
proven
on
the
Windows
front,
so
well,
yeah.
B
If
we
can
throw
all
of
our
win
all
of
their
Windows
generator
properties
through
our
generator
and
thereby
feed
it
down
to
Clan,
sharp
and
then
just
apply
our
modifications
like
we
would
as
usual,
it
means
that
there's
no
there's
no
real
downside
to
using
silk
or
using
terafx
it's
just
whichever
binding
style.
You
prefer.
D
Yeah
I
mean
I
really
like
this
is
I
I.
Think
terrify
is
great.
You
know,
but
I
think
I'd
really
like
to
get
to
the
point
where
Circus
like
a
strict
superset
of
therapist,
because
I
think
like
I
I'm,
just
I,
just
think
that,
like
the
wall
Styles
like
my
name,
is
like
good
for
some
cases
but
I
think
there's
so
many
opportunities
to
just
have
like
easy,
safe
variants
that
cost
nothing
that
like
I'm,
not
a
fan
of
like
saying.
Oh,
we
only
do
raw
bindings.
It's
like
that's!
D
B
Yeah
I
mean
yeah,
that's
what
I
want
to
get
to
as
well
to
be
fair
because
I
I,
don't
obviously
so
self-drivener
should
be
very
usable
like
if
you,
if
you
want
to
avoid
a
pointer.
Well,
okay,
it
might
be
a
struggle,
but
we
can
probably
make
that
work,
but
it's
it's.
It
should
be
a
case
of
well
yeah,
it's
it.
It
still
feels
C
sharp
like
and
you
can
still
use
the
raw.
You
can
still
use
pointers
and
everything
if
you
want,
but
fundamentally
you
have
no
cost.
B
C
E
C
E
C
C
But
if
you
could
still
get
the
original
pointer
back,
if
you
dereference
a
pointer
and
call
a
method
on
the
dereferenced
object,
if
you
can
still
get
the
original
pointer
back,
then
it
should
be
possible
to
just
like.
Have
the
user
specify
a
global
static
web
GPU
somewhere
and
then
you
can
then
do
I'll
put
it
in
the
text.
Chat
for
this
channel
it'll
be
something
like
device
create
buffer.
C
If
I
can
still
get
back
the
original
pointer
for
device
inside
the
create
buffer
function,
then
it
would
be
possible
to
then
redirect
that
to
just
wgpu
device
create
buffer
and
then
pass
in
the
device.
So
it
ideally
having
a
way
to
have
those
two
things
be
the
same.
Things
would
be
really
good.
It
would
improve
usability
a
lot,
but
if
that's
not
possible,
then
I
can
have
something
yeah.
D
This
is
pretty
much
exactly
a
feature
that
I've
been
talking
about
slightly
different,
like
I
would
match
it
slightly
differently,
because
Vulcan
does
the
same
thing
right
like
it's.
The
exact
same
thing
with
like
most
woken
things
are
like
very,
like
object
oriented
where
you
have
like
a
make
object
that
I
creates
like
more
in
them
like
you
have
functions
that
operated
those
Etc
I,
don't
think
you
can
do
it
using
like
The
Arrow
syntax,
but
the
way
I
like
think
we
should
implement.
D
D
That
don't
have
a
specific
value,
but
I
guess
for
web
GPU.
It
would
just
be
a
pointer
I
guess
it
doesn't
really
matter
what
the
inner
type
is
and
then
you
can
just
like
make
a
class
or
make
like
a
extension
methods
on
top
of,
like
that
say,
General,
and
that
those
do
exactly
this
and
yeah
I
guess
with
webp
we
can
yeah
exactly
that's
basically
what
it
would
look
like
but
like
it
then
it
can
also
do
I'm.
Not
sure.
Do
you
have
to
stream
on
the
chat
right
now.
D
D
Amazingly
I
have
I
had
like
a
smallish
prototype
of
this,
like
it's,
it's
amazing
to
use
because
you
can
like
you,
can
make
them
implement
the
suppose
to
like
free
them,
like
you
can
do
all
the
like
c-sharpiness
that
you
would
expect
from
like
an
object,
oriented
API
and
it's
amazing
and
you
don't
have
like
to
provide
the
same
handles
everywhere.
It's
great
to
use,
but
I
pretty
much
found
this
to
be
like
more
or
less
impossible
to
generate
right
now,
because
there's
no
in
I
I
mean
it's.
D
A
C
D
D
C
Yeah,
the
reason
why
is
because
wgp
returns,
pointers
to
objects
like
a
star
buffer
or
I
guess
would
be
a
c
would
be
a
buffer
star
or
an
instant
star,
and
you
I,
don't
think
you
can
add
extension
methods
for
a
pointer
to
an
object.
I
think
you
could
only
add
them
as
the
object
itself.
I
I'm,
not
sure
on
that,
but
I
believe
that's
how
it
works.
Yeah,
but
yeah
I.
Don't
think
you
can
add
an
extension
method
like
you
can't
do
this
instance
star
and
like
I
mean.
D
D
D
C
My
my
thoughts
for
that
were
to
for
that
the
user
is
in
most
cases,
I
say
most.
The
user
is
discouraged
from
creating
multiple
API
objects,
because
in
web
GPU
and
Vulcan
I
I
think
so
too.
You
have
instances
device
and
instances
adapters
and
devices
and
generally
you'll
have
one
instance,
sometimes
multiple
adapters
and
sometimes
multiple
devices.
It's
very
rare
that
you'll
have
multiple
instances,
let
alone
multiple
copies
of
the
Native
Library,
like
you're,
never
going
to
be
calling
into
both
John
and
wgpu
at
the
same
time.
C
So
my
thoughts
were
to
just
at
setup
time.
When
you
create
the
web
GPU
object,
there
will
be
an
option
to
basically
store
that
object
in
global
state
somewhere,
like,
for
example,
in
the
web
GPU
class.
There
could
be
a
static
web
GPU
instance
that
we
can
call
probably
not
instances
of
diffusing.
But
if
we
store
a
static
copy
of
it,
then
we
wouldn't
need
to
store
another
copy.
C
So
we
wouldn't
need
the
wrapper
class
and
it
would
be
if
we
wouldn't
have
to
create,
like
a
separate
method
where
you
wouldn't
have
to
do,
for
example,
instance:
wrapper
equals,
like
instance,
wrapper
instance,
equals
new
instance
wrapper,
VK,
dot,
create
instance.
You
wouldn't
have
to
do
something
like
that.
It
would
just
you
would
just
directly
dereference
the
pointers
you
get
from
the
normal
API
things
and
you'll
be
able
to
call
the
methods,
presuming
that
you
have
set
that
Global
static.
State
yourself.
C
B
E
C
Yeah,
but
if
there's
anything
missing
with
our
quaternity
and
like
apis
and
such
feel
free
to
open
proposal,
we
are
still
open
to
them
for
two
ducks
and
most
of
the
math
stuff
that
is
in
2.x
is
probably
going
to
be
reevaluated
and
probably
push
into
3.2
yeah.
We
should
have
most
of
the
methods
for
quaternion,
yes,
I.
Think
numerix
also
has
one
all
right:
kitara.
A
C
B
Yeah
the
thing
is
it's.
It
would
be
great,
however,
I
don't
want
to
lock
people
in
into
using
that,
because
I
know,
that's
a
that's.
Actually
one
thing
that
Thomas
really
hates
is
those
rappers
that
are
just
a
rap
Rover,
the
API
objects
and
the
handle
ones.
Basically,
you
just
play
say
GL
something
do
this
with
something
dot.
Do
this.
A
C
The
the
good
thing
about
the
one
like
if
it
does
work
this
way,
if
you
can
in
fact
get
to
the
original
pointer
when
you
dereference
a
call
method
on
it.
If
it
does
work
that
way,
then
it
would
be
completely
optional.
You
could
just
do
wgpu
dot
device,
great
buffer
or
you
could
do
device.
Do
you
reference
create
buffer
and
they
would
both
work
exact
same
way.
C
If
you
didn't
want
to
use
the
because
it
wouldn't
be
a
wrapper
object,
it
would
just
be
the
exact
same
pointer,
but
when
you
do
reference,
the
pointer
you
get
back
or
you
get
an
object
with
a
bunch
of
methods
on
it
because
they're
all
just
all
the
web,
GPU
objects
are
just
opaque
types,
pointers,
dual
pink
types.
So
if
you
can
still
get
the
original
pointer
back
out,
this
would
be
a
completely
optional
way
of
doing
this.
C
And
if
you
can
pass
a
reference
to
a
static
object,
and
then
we
store
that
reference
to
your
static
object,
we
wouldn't
even
need
to
have
like
a
static
web
GPU.
We
would
just
store
a
reference
to
another
to
to
the
users
static
web.
Gpu
because
then
they
could
handle
their
static
objects.
However,
they
need
I,
don't
know
how
feasible
that
is
not.
D
A
C
C
It
would
be
slightly
on
a
special
case
basis
like
how
exactly
it
interacts
with
the
functions,
because
we
can't
just
assume
for
if
there's
a
shared
prefix
on
a
bunch
of
types
and
the
first
parameter
of
those
shared
prefix
functions
is
the
same
name
as
that
prefix.
We
can't
just
assume
that
is.
We
should
turn
that
to
API
wrapper
I
think
for
it
to
not
be
annoying.
It
should
be
like
manually,
you
have
to
say
all
functions
that
start
with
device
and
have
a
device
Stars
first
parameter.
C
D
C
Yeah
I,
don't
think
for
opengl
would
work.
I
I
feel
like
unfortunately,
opengl
just
would
not
be
possible
because
nothing
strongly
typed
into
mgl.
It's
all
events,
but
for
for
something
like
Vulcan
or
web
GPU
I
believe
metal
too.
Although
metal
is
a
bit
of
a
different
case,
because
it's
Objective
C.
B
C
C
With
the
ones
that
are
in
two
decks,
yes,
yeah
I
think
they're
a
little
clunky
to
use
mostly
because
functions,
don't
return
them
directly,
yes,
wrap
it
in
the
new.
That's
my
main
problem.
If,
if
it,
if
it
did
return
the
object
directly,
it's
a
double-edged
sword,
it
forces
you
to
use
it.
So
you
can't
use
all
units
and
then
it's
it's
basically
just
object.
Oriented
opengl
at
that
point
which
yeah
I
I.
C
Personally,
whenever
I'm
working
with
opengl
and
silk
I,
always
use
UNS
directly,
but
yeah
I
can
understand
the
need
for
the
stronger
type
handles
because
yeah
my
solution
is
just
I,
don't
use
opengl
anymore
I.
Everything
I
do
is
web
GPU
or
direct311
through
the
xbk
native
that
my
solution
is
just
I:
don't
I
don't
mess
it
up
in
jail
anymore.
C
I'm
sure
I'm
sure
someone's
come
up
with
some
genius
way
to
have
it
all
be
context.
Surface
dependent
and
clean
wrapper
objects
that
correspect
to
humans
and
such,
but
it's
a
lot
of
work
for
what
is
essentially
a
feature
that
a
fair
amount
of
people
are
going
to
opt
out
of
because
not
Everyone
likes
the
wrapper
objects.
Everyone.
Some
people
just
want
to
work
directly
with
the
units
and
do
not
care,
which
is
fair.
That's
how
I
work
with
it
yeah
for
something
like
opengl.
C
It
is
something
I
want
to
see.
I
want
to
make
web
GPU
As
Nice
of
the
experience
to
use
from
C
sharp
as
possible,
because
even
from
using
it
just
in
C,
it
is
not
the
best
experience
working
with
the
multiple
different
headers
that
argue
with
functions.
They're,
not
even
being
a
single
dispose
mechanism
Universal
it's
it's
quite
a
mess
and
I've
been
able
to
wrap
around
some
of
that
mess
with
the
extensions
that
we
provide.
C
But
my
goal
is
to
make
it
just
a
good
experience
and
better
than
everything
else,
because
from
what
I've
seen
at
least
the
average
in
web
GPU
bindings
are
no
offense
but
they're
bad.
It's
just
rapper
strucks
over
inputer
and
their
bindings
are
their
separate
bindings
depending
on
whether
you're
targeting
Dawn
or
the
browser.
C
A
C
B
A
C
M
scripton
provides
just
like
with
sdl
and
glfw
and
a
few
other
things
they
provide.
They.
Let
you
we're
able
to
pee
invoke
into
a
web
GPU
header
that
is
supposedly
the
same
as
the
main
ones.
However,
it's
based
on
Dawn
and
it's
10
months
old
and
no
one's
touched
it,
but
you
theoretically,
if
we
were
to
try,
we
could
have
our
web
GPU
bindings
work
on
encryptum,
just
out
of
the
box.
C
All
the
existing
web
GPU
code
could
just
work,
but
in
practicality,
that's
not
going
to
work
because
the
the
header
is
Dawn
based
and
it's
old,
so
the
function
signatures
haven't
been
changed
like
not
even
that
long
ago
they
change
a
bunch
of
function,
signatures
and
the
types
of
some
enums
added
some
values.
So
it's
just
not
not
really
doable
right
now,
maybe
I'll
try
to
fix
that
myself.
C
A
C
B
C
D
Just
tell
me
if
I
started
lagging
okay,
because
I
can
hear
you
perfectly
your
whole
time.
It
just
needed,
like
I,
don't
know
yeah,
so
I
just
wanted
to
like
search
back
to
the
like
wrapper
thing,
because
I
know
we
had
like
a
decision
with
Thomas
about
this
before
that.
Like,
oh,
you
know,
GL
has
this
thing,
but
it's
just
like
a
unit,
and
we
all
just
pretend
this
makes
it
safer,
but
it
really
doesn't
but
I
think
for
apparently
web
GPU,
but
especially
for
Vulcan
I.
D
You
just
like
have
a
mirror
of
all
the
things,
and
it's
like
you
know
it
just
like
it's
a
bit
of
a
cost
and
like
a
bit
of
a
Trader
versus
like
the
static
State
thing,
but
I
think
it
could
work
really
nicely
and
I
think
they
fall
like
woken,
which
is
inherently
very
weak.
Oriented
I
think
we
would
get
a
lot
of
value
out
of
it.
I
just
think
that
matching
these
functions
like
finding
the
right
functions
to
add,
is
very
difficult.
C
D
This
is
like
super
common
to
have
like
a
device
function.
Numbers,
like
takes
the
instance,
the
first
perimeter,
and
then
the
device
is
like
after
those
two,
so
you
could
like
all
smash
that
and
it's
like,
but
that
way
it's
really
like
get
useful,
not
just
like
in
basically
you
and
drop
it
basically,
but.
D
C
For
web
GPU,
it's
a
lot
easier
because
they
don't
have
like
you,
don't
pass
instance
for
every
method.
The
instance
is
tied
inherently
to
the
device
object
itself.
It's
it's
its
internal
state
that
the
implementation
takes
care
of.
So
instead
of
passing
an
instance
then
device
you
just
pass
in
device
and
then
the
implementation
will
internally
take
care
of
finding
the
instance
of
doing
everything
to
see.
E
C
C
B
C
C
C
You
don't
have
to
create
a
wrapper
object.
You
don't
have
to
have
extra
methods
to
return,
exact
objects
or
you
don't
have
to
have
the
user
constructed
your
apologies
below
it.
Just
quote:
unquote
works.
You
can
directly
dereference
it
and
call
a
method
on
it.
You
don't
have
to
worry
about.
Oh,
is
this
object,
keeping
a
copy
of
my
w
of
my
web
GPU?
C
C
You
forgot
to
clear,
holding
your
web
GPU
object
hostage
from
the
garbage
collector
I
think
having
it
as
a
single
static
object
that
the
user
has
to
explicitly
set
themselves
before
using
these
methods
would
mean
that
the
user
is
fully
aware
that
there
is
a
static
reference
to
this
object
and
it
will
not
get
cleared
by
the
garbage
collector
until
they
clear
the
static
reference.
I
think
that.
A
C
D
D
C
C
B
Yeah
I
think
I
think
the
way
I
feel
about
static
and
not
having
static
functions
was
something
that
where
silk
has
gone
against
pretty
much
every
other
binding
Library
out
there,
but
we
did
so
in
the
name
of
correctness.
For
example,
opengl
has
no
like
it.
The
the
function
addresses
are
dependent
on
the
context
in
which
the
GL
objects
is
created,
so
it
made
sense
for
it
to
be
an
instance
and
with
Vulcan
as
well.
B
We
have
the
VK
get
instance
process
address
and
the
get
device
proc
address,
which
obviously
you
think
the
for
Vulcan.
We
could
have,
like
the
create
instance,
function
as
a
static,
because
that
is
in
theory,
constant,
like
you
can't
you
can't
get
it.
You
can't
think
I
get
into
this
proc
address
of
VK,
create
instance,
because
in
order-
or
rather
you
can,
but
you
can't
having
an
instance
handle,
because
you
would
have
already
created
an
instance
at
that
point,
so
I
think
Vulcan.
C
C
B
C
D
It's
so
there's
so
little
benefit,
which
is
just
like
having
an
extra
type
like
you
get
this
like
extra,
like
confusing
error
when
you
initialize
it
wrongly,
like
this,
the
likelihood
of
someone
calling
this
function
not
realizing
they
have
to
like
set
the
instances.
So
big
and
I
mean
like
I.
Just
don't
really
see
it.
I
think
I.
Think
that,
like
having
a
proper
like
managed
object,
gives
us
this
and
like
and
more
I
mean
we
can
then
like
also
handle
like
destroying
your
object
again
using
this
pose.
D
We
can
like
there's
so
much
more.
We
can
do
if
we
make
like
a
proper
managed
object
and
like
having
the
static.
I.
Don't
know,
I
feel
like
having
a
static
field
is
like
already
pretty
bad
and
like
it
doesn't
really
give
us
anything.
So
I
feel
like
making
like
making
it
like.
A
proper
object
is
just
better.
C
A
lot
of
it
for
me
is
just
not
having
to
deal
with
the
proper
object,
because
that
that
has
to
come
with
some
compromise
either
we
double
the
amount
of
overloads
for
those
methods
which
overload
overload.
Explosion
is
already
a
quite
a
big
problem
with
silk,
like
I've
spent
like
an
hour
just
trying
to
get
a
single
method
to
be
happy
because
there's
like
50,
overloads
and
I
have
no
idea
what
it
wants.
C
Having
a
double
set
of
overloads,
not
probably
not
overloads
but
like
a
different
set
of
functions
with
a
different
name,
would
just
be
confusing,
but
we
can.
We
can
make
the
enre
a
bit
nicer
by
just
checking
at
the
start
of
the
method,
if
instance
is
null,
then
do
something
else
like
like
say:
Throw
exception.
C
You
cannot
use
the
dereference
overloads
unless
you
set
the
static
state
which
would
make
it
very
clear
what
you
have
to
do,
and
it
would.
It
would
remove
the
need
for
that
second
set
of
methods
that
Returns
the
wrapped
object
and
but
yeah
the
options
are
returning.
The
wrapped
object
directly
using
a
second
set
of
methods
or
having
the
user
construct
themselves,
so
we're
either
doubling
the
amount
of
functions
for
a
lot
of
a
lot
of
things
or
we're
having
the
user
Constructor
stuff,
which
is
the
main
thing
that
I
was
thinking
of.
D
I
I,
don't
know
how
bad
this
is
in
in
web
GPU,
but
I
would
so
for
me,
it's
like
in
in
Vulcan.
You
have
this
like
sort
of
tree
of
objects.
Anyways,
it's
like
you,
get
like
the
root
API
in
the
from
the
API.
You
make
an
instance
from
the
instance
you
maybe
make
like
a
couple
physical
devices.
Then
you
use
a
physical
device
to
make
like
a
logical
device
or
maybe
use
a
couple
to
make
with.
D
From
that,
you
like,
create
your
shaders
and
whatever
so
like
it's
just
sort
of
Trio
like
objects
right,
and
so
what
I
would
do
is
when
you
make
one
managed
object,
all
the
apis
that
you
call
Via.
This
managed
object
will,
in
turn,
automatically
return
more
managed
objects
that,
like
keep
the
references,
so
you
would
only
have
to
create
the
you
only
have
to
have
like
a
single
overload
wins
for
like
creating
the
instance
that
like
to
say
so.
D
It's
like,
oh
give
me
like
a
managed
instance,
this
time
or
like,
or
maybe
to
use
that
to
construct
themselves
like
once
and
then
all
the
API
usage
is
like,
after
that,
after,
like
the
point
where
they
created
themselves
or
like
they
get
it
from
like
it's
like
one
extra
function,
everything
after
that
is
like
automatically
managed
it's
like
that
also
well.
This
applies
to
work
here,
but.
C
C
See
what
we're
talking
about
that
would
also
apply
to
web
GPU,
but
one
thing
about
that
is
that
it's
not
the
the
two
sets
of
like
methods,
don't
really
interrupt
too
well.
Like
say
you
have
an
existing
web
GPU
code
base
and
you
want
to
migrate
from
the
old
non
non-special
overloads
way,
and
you
want
to
move
to
the
new
way
if
you
you
would
have
to.
If
you
want
to
properly
take
advantage
of
the
code.
Readability
Improvement
of
the
wrapper
objects.
C
D
You
can
do
some
of
the
readability
because
you
have
to
construct
objects,
but
while
you
like,
pull
it
to
like
a
new
API
and
you
like
started
using
more
of
the
new
API
that,
like
boiler,
moves
up
more
and
more
until
eventually
that
I
put,
it
will
be
like
right
at
the
instance
where
it's
like
you
create
like
one
object
once
and
like
that's.
It's
right,
like
so
I
think
like
while
porting
it.
D
C
Yeah
having
to
be
static
is
like
a
big
downside,
because
then
the
user
isn't
in
full,
like
it
isn't
in
clear
full
control
of
the
the
view
of
the
object.
As
it's
now
I
I
checked
on
Sharp
lab
if
you
can
store
a
static
reference
to
an
object
instead,
but
it's
like
a
static
ref
on
a
reference
like
a
oh
yeah.
Yes
like
if
you
store
a
static
ref
like
inside
of
a
class,
can
you
store
a
public
static,
ref
of
a
class?
And
you
can't
unless
the
ref
struct.
E
C
D
C
D
A
D
C
D
Also
seen
quite
a
few
people
that
and
I
find
this
way.
Every
time
is,
do
you
have
like
your
engine
object
or
whatever,
like
I,
think
very
few
people
make
like
their
injured,
State
static,
I,
think
most
people
make
like
an
engine
object
or
something,
and
then
like
I,
always
just
stored
everything
in
there
and
then
passed
it
as
appropriate,
which.
C
Yeah,
it's
it
it's
tough
to
do
this
in
a
clean
in
like
a
in
a
truly
silky
smooth
way.
Both
ways
has
some
drawing,
but
yeah
I,
think
I.
Think
if
you
I
think
the
tree
approach
would
actually
be
better.
Yes,
I
I
feel
like.
Instead
of
storing
the
static
state
is
ugly
but
yeah.
I
I
feel
like
just
having
objects
and
just
that
that
transition
point
being
more
painful,
I
feel
like
yeah,
I
I
do
agree.
You
know
that
that
having
that
transition
point
be
more
painful
temporarily,
but
yeah.
D
C
Have
the
I
I
I've
looked
around
and
build
tools,
we
have
the
framework
in
place
to
make
this
relatively
simply
in
webview,
I
I'm,
not
versed
in
Vulcan.
It's
the
same.
It's
really
I'm
really
not
versed
in
Vulcan.
It's
there's
a
lot
more
stuff
to
take
into
account
because
it's
a
much
bigger,
API
too
web
GPU
is
like
I.
Think
it's
like
50
functions
or
something
it's
a
lot
simpler.
C
D
C
Not
sure
it
does,
but
it
handles
it
slightly
differently.
Web
GPU
itself
does
not
have
the
same
concept
of
extensions,
there's
unofficial
Extensions
by
both
the
implementers
of
web
GPU,
but
those
aren't
true
standards,
but
there's
also
the
chaining
mechanism,
which
is
how
you're
supposed
to
do
extensions
in
web
GPU
by
chaining.
Multiple
objects
together
like,
for
example,
the
the
best
example
of
how
training
works
is
the
Shader
creation.
You
have
a
Shader
module
descriptor
and
that
points
to
either
a
wgsl
descriptor
or
it
can
also
point
to
a
sphere
V
descriptor.
C
Let's
see,
and
those
are
both
just
cast
down,
it's
like
S-Type
those
trucks
have
an
S-Type
and
the
main
Shader
module
scripter
points
to
one
of
those
chain.
Structs.
That's
how
you're
supposed
to
do
extensions
in
web
GPU,
but
that
only
but
in
the
in
the
in
context
of
native
that,
that's
not
how
most
people
do
it
most.
D
B
D
B
D
C
I
I
think
I
think
for
web
GPU
it'd
be
a
relatively
simple
change,
relatively
I
mean,
but
for
Vulcan
it's
gonna
be
a
lot
more
work
because
I'm
assuming
there's
also
a
lot
more
different
types
of
things
in
Vulcan,
and
that
tree
is
probably
a
lot
more
complex
because
I
think
in
web
GPU.
The
tree
only
gets
like
four
objects:
deep
Max
I
think
the
deepest.
It
goes
with
texture
view,
texture
device,
adapter
instance,
I
think
I
think
that's
the
deepest.
It
goes
in
web
GPU,
but
I'm
assuming
in
Vulcan.
C
It
can
go
a
lot
deeper.
So
it's
going
to
be
a
lot
more,
a
lot
more
to
take
into
account,
but
yeah
I
think
I.
Think
as
like
a
first
pilot
implementation,
it's
gonna,
I'm
gonna,
do
it
as
just
web
GPU
just
to
get
something
down
and
something
functional
and
yeah.
When
I
do
try.
This
I
am
going
to
attempt
to
have
just
a
an
extra
function,
for
instance,
which
are
terms
of
managed
instance,
and
that's
a
wrapper
object.
C
E
C
C
Bad
yeah
web
GPU
how
how
at
least
have
wgpu
or
no
no
but
both
Google
and
Mozilla,
do
it.
When
you
delete
an
object,
it
does
not
actually
delete
the
object
until
everything's
done.
You
cannot
delete
an
object
and
cause
a
problem
of
it's
still
in
use
in
the
frame.
If
you
draw
with
the
texture
and
then
delete
the
texture,
it
doesn't
actually
remove
the
texture
from
memory
until
after
the
frame
is
not
rendering
so
I
think
I
think
it's
less
of
a
problem
with
web
GPU,
but
I.
C
C
C
Because
if
it
doesn't
shoot
you
in
the
foot-
and
it
does
just
keep
it
internally
until
it's
done
being
used,
I
believe
that's
a
failure.
Okay,
in
that
case,
yeah
other
undefined
yeah.
In
that
case,
we
probably
shouldn't.
Have
it
automatically
disposed
for
web
GPU
would
be
fine,
but
not
for
Vulcan
and
I'd,
rather
keep
the
logic
or
I
I
keep
I
want
to
keep
the
behavior
the
same
between
web
GPU
and
Vulcan
for
this
because
I'd,
rather
it
not
be
okay,
it
disposes
automatically
on
webjp,
but
not
on
open
I'd,
rather
not
do.
E
B
C
E
C
C
Gpu
wrap
the
wrapper
object
itself
will
in
the
destructor,
we'll
call
suppose
if
it's
not
already
been
called
writer.
Has
this
like
remove
unmanaged
resources
thing
or
whatever
that
it
does,
when
you
like,
generate
High
disposable
patterns
but
yeah
that
that
that
that's
what
I?
Since
it
says
it's
undefined
in
Vulcan,
I,
I,
I'm
gonna,
avoid
that
and
just
have
disposal
is
manually.
But
you
have
a
knife:
stop
dispose
function,
honest
random
images,
as
there
is
a
values
of
API
if
all
commands
are
for
them
exactly.
Okay,
yeah!
C
Thank
you.
So
in
that
case
it
will
not
be
automatic
because
it
is
too
easy
to
accidentally
shoot
yourself
in
the
foot
by
just
pulling
a
method
of
them
up
then
letting
the
object
die
too
soon,
because
if
the
garbage
collector
calls
at
the
wrong
time,
then
you're
screwed
up
possibly
the
manage
chain
apis
kind
of
Vulcan
you'd,
have
to
ask
perks
your
Kai
I,
don't
actually
know.
B
So
we
given
that
at
the
time
it
was
only
Vulcan
and
open
XR
that
would
ever
have
chaining
it.
We
just
decided
yeah
if
we
want
it
we'll
copy
and
paste
it,
and
we
couldn't
Dairy
copy
and
paste
it
into
web
GPU,
although
I
don't
think
they're
enough.
In
fact,
no
we
couldn't,
because
we
don't
have
any
information
as
to
what
change
to
what
like
we
do
in
the
Vulcan
spec.
You
don't
work,
pixel
specs.
B
C
Just
a
pointer
cast,
there's
no
information,
no,
like
Don,
has
a
file
which
generates
their
header.
It's
a
it's
a
big
old
Json
blob,
but
that
doesn't
impressive
information.
It's
literally
just
the
structs
the
names
and
you
even
have
to
mingle
the
names
yourself
into
the
proper
like
names.
It's
so
that's
it's!
Sadly,
there
just
isn't
enough
information
provided
to
us
by
the
header
to
know
what
chains
go
where
there's
not
like:
it's,
not
even
a
naming
convention
for
it
I,
don't
think
I
believe
I've
seen
naming
so
it's
it's
a
nightmare.
C
It's
a
nightmare,
see
I
I,
don't
think
it'd
be
possible
to
move
the
trucks.
The
Struck
Chuck
struck
chaining
mechanism
into
a
GPU,
but
chaining
is
in
the
average
application
you're
going
to
use
chaining
once
and
it's
going
to
be
when
you
create
your
shaders
and
you're,
going
to
write
that
code
once
and
never
touch
it
again.
So
it's
not
without
a
real
problem,
but
in
Vulcan
I'm
assuming
chaining
is
a
common
thing.
C
Yes,
yes,
web
gpus,
like
that
too,
everything
starts
with
the
pnext.
However,
we
don't
know
at
at
generation
time,
which
ones
are
valid
like
we
like
like
for
an
example
of
the
Shader
module.
We
don't
know
a
generation
time
that
the
only
chains
that
are
valid
are
WG
cell
descriptor
or
spear
V
descriptor.
All
we
know
is
that
any
void
star
object
can
go
there.
I
guess
I
think
it's
actually
a
wgpu
like
chain,
Struck
it
or
something
I,
don't
think
it's
actually
avoid
starting.
It's
a
chain
struck
star,
but
yeah
I.
C
B
Yeah
all
right,
well,
I,
think
there's
been
a
lot
of
great
discussion
after
all
the
off-topicness
at
the
start,
but
should
probably
wrap
this
up.
We've
been
well,
we've
been
live
for
over
100
minutes
now
so
yeah.
Thank
you.
Thank
you
both
for
coming.
It's
it's
good.
As
always,
it
is
very
nice
to
do
these
streams.
Whatever
you've
got.