►
Description
Bringing Vulkan everywhere with gfx-rs
Graphics abstraction is an important part of maturing Rust ecosystem. gfx-rs has been the basis of many graphics applications since 2013, but as of this year it undergoes a total rewrite with the new vision, set of goals, and talented contributors. In this talk, I want to explain what this means to existing users, Mozilla, and the world.
Intended audience: people interested in Rust ecosystem foundational libraries, graphics and game development, Vulkan.
Dzmitry Malyshau
Lots of computing and gaming in childhood. Graduated with math and computer science in Belarus, then migrated to Canada to work in game development. Now working with Rust on graphics at Mozilla.
Markus Siglreithmaier
I'm a Computer Science student focusing on Computer Graphics (including Real-time rendering and physically-based animations). I'm mainly working on gfx-rs and associated projects in my spare time at the moment among other smaller Rust projects.
Rust devroom @ FOSDEM 2018
https://fosdem.org/2018/schedule/event/rust_vulkan_gfx_rs/
These talks have been recorded at FOSDEM (https://fosdem.org/)
This work is licensed under the Creative Commons Attribution 2.0 Belgium Licence.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/2.0/be/deed.en
A
B
The
idea
is
to
have
a
single
abstraction
layer
to
run
on
all
the
platforms
that
we
have.
Unfortunately,
the
graphics
API
have
been
branched
out.
We
have
Microsoft
pushing
the
DirectX
12
in
the
windows
ecosystem
and
we
have
Apple
pushing
for
metal.
Everything
else
is
adopting
Vulcan
quite
successfully,
including
the
Android.
The
most
popular
ability
system
and
OpenGL
is
still
alive
as
well,
and
we
want
all
of
those
to
be
available
through
a
single
interface
in
rust.
That
is
hopefully
safe
and
fast.
B
We
started
in
2014
and
the
legend
is
we
had
three
threats
at
the
beginning
and
then
we
were
fast
tracking
through
the
evolution
of
the
api's,
as
the
native
API
did
so.
First
we
got
cumin
buffers,
we
got
rid
of
threads
and
then
we
followed
with
resource
fews
pipeline
States,
eventually
getting
this
VD,
11
and
metal
back
ends
and
then
somewhere
around
2017.
B
When
we
started
first
talks
about
integrating
into
web
render,
it
appeared
to
us
that,
even
though
we
already
had
the
core
layer
split
out
of
the
higher-level
rendering
we
still
weren't
zero-cost
enough,
so
we
decided
to
go
lower
level.
We
decided
to
implement
the
core
to
be
completely
zero
cost
and
that's
where
Marcus
comes
in.
B
This
is
the
main
road
map
of
our
work
and
if
you
are
taking
one
thing
from
our
top-
and
that
should
be
this
slide,
I
believe
at
the
center
you
see
hardware,
abstraction
layer,
that's
our
new
core,
that's
the
name
of
the
new
core.
It's
Vulcan
like
rust,
API,
very
low
level,
quite
unsafe,
that
different
graphics,
backends
implement,
including
Vulcan
metal,
d3,
12
and
OpenGL.
These
are
the
backends
that
we
already
have
now
and
we
are
getting
this
VG
11
soon
enough
as
well.
B
The
clients
of
the
hardware
abstraction
layer
are
many
aside
from
the
user
apps.
We
have
the
Vulcan
portability
layer
which
we
are
talking
about
a
little
bit
later.
We
have
the
warden
test
framework
to
ensure
no
regressions
in
the
graphics
tests
and
we
have
a
web
GPU
prototype
based
on
servo.
That's
using
that.
B
Little
bit
more
about
the
warden
test
framework,
it
consists
of
three
parts.
First,
one
is:
we
are
able
to
describe
graphics
resources
and
passes
in
readable
source,
which
we
use.
The
raster
object
notation
for
it
says
here's
my
images,
buffers,
here's,
what
I'm
going
to
do
this
with
them
in
the
following
passes,
and
then
we
have,
we
can
load
it
all
with
a
particular
graphics
back-end,
so
that
it
instant
she
eats
the
resources
on
the
GPU
and
creates
the
common
buffers
to
implement
passes.
B
And
then
we
have
a
brief
test
framework
which
has
very
simple
ref.
That's
defined
and
it
runs
the
graphics
passes
on
the
specific
backends
compares
the
expectations
with
the
tests.
This
is
an
example
of
the
resources.
We
have
an
image
with
the
specified
format
and
dimensions.
We
have
a
render
pass
with
one
attachment
and
once
a
pass,
just
as
an
example
of
roughly
how
it
looks.
B
C
Okay,
so
then
why
we
want
to
actually
use
rust
instead
of,
for
example,
C++.
There
are
a
few
nice
bits
of
rust
and
compared
to
the
basic
concurrency,
all
Const
new
features
like
pattern
matching
and
they're
sensing,
which
basically
tells
you
that
every
object
in
our
API
is
sensing.
So
you
can
access
it
from
all
threats
and
concurrently
and
there's
also
immutability,
which
we
use
to
say.
C
For
example,
you
can
change
this
object
or
you
can't,
and
it
also
encodes,
if
you
need
to
externally,
enforce
single
access
because,
for
example,
some
objects
can
only
be
accessed
on
one
thread
at
one
time.
So,
if
you
have,
if
you
see
mutable
access,
you
usually
indicates
that
you
need
to
externally
synchronize
your
object,
then
traits
and
associated
types
which
we
use
quite
heavily,
which
is
which
you
will
see
later
on,
and
we
split
all
the
things
into
multiple
repositories.
C
C
Fixed
sized
errors
would
help
quite
a
lot
for
the
user
side
to
looks
a
bit
better
and
exclusive
cargo
futures,
and
at
the
moment
you
could
something
could
do
something
like
I
want
X,
12
and
Wilkin
to
run
at
the
same
time
somehow.
But
it
usually
will
mess
up
here
and
you
usually
only
want
and
TX
12
or
Vulcan.
C
So
the
packet
right
is
our
main
interface.
It's
one
large
right.
You
have
to
have
to
implement.
If
you
want
to
implement
a
back-end,
we
basically
divided
into
the
special
objects
like
the
device
or
a
command
Q,
which
you
can
call
functions
on,
and
the
basic
resources
like
shaders
above
image,
which
you
usually
just
pass
around
and
create
and
delete
so
for
the
roadmap
2018,
and
we
would
like
to
become
Mozilla
project
because
we
want
to
integrate
into
web,
render
and
also
into
the
web
chip.
C
You
part
which
will
Dimitri
will
talk
about
and
one
side
project
is
working
portability.
It's
an
initiative
from
Vulcan
from
Kronos,
where
they
try
to
do
all
the
3
3
backends
Vulcan
digs
12
and
metal
and
provide
one
RP
Eve
subset
from
the
work
and
a
PE
which
can
map
to
all
these
three
backends
and
our
goal
is
to
implement
the
vole
compatibility
layer
using
our
hardware,
abstraction
layer,
and
we
currently
can
already
pass
a
few
examples.
C
C
That's
how
it
looks
from
our
side.
We
basically
have
our
hardware
abstraction
layer
on
the
bottom,
which
is
to
DFARS
side
and
on
the
top.
We
have
the
portability
layer
and
you
can
interface
it
using
driver
in
the
implementation
or
using
a
static
library.
And
if
you
don't
want
to
directly
link
it
link
it
from
C
library.
C
B
It's
a
w3c
working
group
which
Microsoft
Apple,
Mozilla
and
Google
are
part
of
and
as
well
as
a
lot
of
independent
actors
that
is
trying
to
design
a
new
API
to
provide
newer,
lower
level
concepts
onto
the
web
for
faster
interactive
applications
on
the
web,
and
there's
been
a
lot
of
discussions
over
what
the
next-gen
API
is
gonna,
be
in.
We
I'm
a
part
of
the
group,
and
we
don't
seem
to
have
a
lot
to
agree
on
so
far.
Everyone
is
sort
of
pushing
in
a
different
direction.
B
B
Now,
a
little
bit
more
about
the
ecosystem
that
we
have
when
it's
history
seems
to
have
a
lot
more
time
left
that
we're
gonna
start
on
each
of
them
closely.
There
is
a
few
engines
in
rust
at
the
moment.
None
of
them
is
major
enough,
but
they're
very
promising,
namely
good
game,
easy
amethyst
and
three
RS.
B
You
just
say:
oh
I
want
this
buffer
and
the
library
handles
the
actual
heat
management
and
allocation
of
the
memory
from
the
driver
for
you
or
a
frame
graph
sort
of
thing
which
allows
you
to
describe
all
your
graphics
workload
as
one
big
graph,
which
is
then
automatically
deriving
the
dependencies.
The
memory
barriers
for
you
and
possibly
schedules
it
to
run
on
multiple
Hardware
queues.
For
execution
in
parallel,
so
this
is
what
amethyst
folks
are
bringing
on
the
table
and
I'm
sure
a
good,
be
museum.
B
Vrs
will
follow
and
use
hardware
abstraction
layer
in
2018
other
than
that.
We
have
a
very
interesting
plans
with
volcano
as
a
project
that
we
are
often
being
compared
to.
In
fact
now.
The
comparison
doesn't
make
much
sense,
because
we
are
lower
level.
We
are
implementing
Vulcan
and
volcano
is
based
on
Vulcan.
So
what
we
want
to
do
is
to
let
users
use
volcano
on
top
of
GFX
hardware,
abstraction
layer,
so
in
a
sense
it's
a
drop-in
replacement.
B
So
that's
something
that
we
are
working
on
right
now
and
finally,
web
render
is
Mozilla
research
project
that
is
currently
being
integrated
into
Firefox.
It
is
in
need
of
better
control
of
the
latency
resources
and
more
direct
access
on
Windows
platforms
for,
for
example,
playing
a
video
efficiently.
So
our
volcán
portability
or
graphic
abstraction
layer
makes
perfect
sense
to
be
a
part
of
web
render
and
we
are
already
working
on
that.
B
B
B
It's
zero
cost
in
a
sense
that,
if
you
want
to
it
to
be
backed
by
Vulcan,
then
we
don't
do
any
hippo
locations
and
we
don't
do
any
smart
pointers
management
for
you.
It
has
explicit,
like
allocation
at
free
calls
for
resources.
Of
course,
there
is
certain
parts
that
we
have
to
do
in
order
for
the
same
API
to
run
on
d3,
12
and
metal.
So
this
is
not
exactly
zero
cost.
B
In
that
sense,
this
is
as
low
cost
as
we
can
afford,
but
this
is
this
goes
in
line
not
in
our
own
reasoning,
but
more
in
line
of
the
Vulcan
portability,
technical
subgroup
and
the
design
that
we're
doing
as
a
part
of
the
group.
So
it's
very
little
minimum
overhead.
We
can't
afford
any
extra
GPU
work
for
whatever
we're
doing.
B
Okay,
so
the
question
is:
how
do
we
deal
with
the
performance
loss
from
not
being
able
to
reuse
common
buffers
in
metal?
That
is
very
unfortunate
and
what
molten
vicki
is
doing
as
one
of
our
competitors
technically
is
having
a
like
a
software.
A
list
of
commands
build
up
independent
of
the
hardware
list,
so
I
don't
think
we
have
that
included
right
now,
but
that's
the
plan
right
now.
B
Other
any
plans
for
the
graphical
UI
toolkit.
We
are
extremely
busy
with
making
sure
that
the
hardware
abstraction
layer
like
the
lowest
level
of
abstraction
works
and
our
next
steps
are
more
in
terms
of
getting
the
like
frame
graph,
sort
of
libraries
or
the
memory
management
libraries
solid
before
we
can
think
about
the
UI.
However,
I
expect
Conrad
to
be
able
to
report
it
on
GFX
Hall.
Eventually,
it's
a
graphical
UI
toolkit
for
rust,
as
well
as
our
friendly
amethyst
folks,
are
likely
to
come
up
with
something
too.
So
we
hope
for
your
help.
A
B
B
Historically,
we
required
the
users
to
provide
all
the
shaders
for
the
backends
that
they
use
like
separate
shaders
for
metal,
OpenGL
and
d3
at
11:00.
After
the
rewrite,
as
we
are
going
for
the
Vulcan
portability
goal,
we
only
accepts
PRV
and
from
spare
v
we
generate
all
the
backend
specific
shaders.
B
B
So
the
question
the
question
is,
how
does
web
GPU
is
going
to
expose
Volk
and
even
the
WebGL
is
way
higher
level?
So
yes,
it's
a
hard
question
and
volcán
is
a
hard
sell
for
multiple
reasons
on
the
web,
not
only
because
it's
low
level,
but
all
the
consequences
from
it
is
like
it's
easy
to
build
a
user
signature
based
on
what
you
worry
about
what
device
can
do
and
on
the
web.
B
It's
not
safe
and
there's
a
whole
lot
of
concerns
that
not
only
make
not
only
Valken
but
in
general,
go
in
any
low
level
on
the
graphic
side
to
slightly
start
breaking
the
rules
of
the
web.
So
we're
trying
to
find
our
philosophy
there
and
our
priority
is
getting
like
the
maximum
performance
of
the
web.