Transcript
[ Music ]
[ Applause ]
>> Hi, everyone,
and welcome to WWDC.
I hope you're all
having a good time so far
and you've had some nice
sessions you've seen.
We've got a great
week for you guys.
It's going to be really fun.
I'm Matt Collins.
This is my colleague Jared
Marsau and we're here
to talk Adopting Metal, Part 2.
This is Section 603.
So if you're in the wrong place,
you get to see some graphics.
So let's recap.
We have two Adopting
Metal Sessions.
Hopefully you were here
for Warren's presentation a
little bit ago, where we talked
about the fundamental concepts:
Basic drawing, lighting,
about the fundamental concepts:
Basic drawing, lighting,
texturing, good stuff like that.
And in this presentation
we're going
to take it to the next level.
We're going to draw
many objects.
We're going to talk about
managing dynamic data,
large amounts of dynamic
data, GPU-CPU synchronization,
and we'll cap it off with
some multithreaded encoding.
Tomorrow we've got some
great presentations.
We'll talk about
what's new in Metal.
We'll have the first session,
tessellation, resource heaps,
memoryless frame
buffers, and some stuff
about our improved tools
to really help you guys get
the best out of your apps.
Part 2, we'll talk about
function specialization
and function resource
read-writes, wide color
and texture assets,
and additions
to Metal performance shaders.
And if you really
want to dig in heavy,
we'll have an awesome talk about
advanced shader optimization,
shader performance fundamentals,
tuning shader code,
more detailed about
how the hardware works.
It'll be great.
So if you're really interested
in tuning your shaders
to make them to best they can
be, check out that tomorrow.
to make them to best they can
be, check out that tomorrow.
So this is Part 2 of Adopting
Metal and we're going to build
on what we learned in Part 1.
We figured out how to
get up and running.
So let's take a look at
the concepts that you need
to get the most out of Metal
in a real-world situation.
We've got a demo that will draw
a ton of stuff in a simple scene
and we'll use that demo for
context during today's session
as we discuss and learn
a couple lessons from it.
We'll talk about the ideal
organization flow of your data,
how to manage large chunks of
dynamic data, the importance
of synchronization between
the CPU and the GPU, and,
like I said before, some
multithreaded encoding.
So hopefully you're familiar
with the fundamentals of Metal
because we won't be
going over them again.
So we expect that you understand
how to create a Metal queue,
a Metal command buffer, how to
encode commands, and we'll build
on that to go forward.
So let's start with
the demo itself
and see what we're
aiming towards.
So right now we've
got 10,000 cubes
So right now we've
got 10,000 cubes
and they're all spinning
around, loading in space.
It's an interesting scene.
Metal allows us to issue
a ton of draw calls
with very low overhead.
So here we have 10,000
cubes and 10,000 draw calls.
You can see on the bottom
there's a little shadow.
We're using a shadow map,
playing on the bottom,
some nice anti-aliased lines
give you some depth cues,
and of course all of our cubes.
So what goes into
rendering a scene like this?
As you can see, we've got
a lot of objects and each
of these objects has its own
associated piece of unique data.
We need the position,
rotation, and color.
And this has to update
every frame
because we're animating them.
So this is a bunch of data
that we're constantly changing,
constantly have to reinform
the GPU what we're drawing.
We can also draw a few more
objects, maybe a little more.
You can spin it around
a little bit and see
that we're actually
floating in space.
So we have a draw call for cube
and a bunch of data for cube
So we have a draw call for cube
and a bunch of data for cube
and we have to think about
the best way to think
about this data,
how to manage it,
and how to communicate
it to the GPU.
So let's dive right in.
Thanks, Jared.
Managing Dynamic Data:
This is a huge chunk
of data that's changing
every frame.
And as you can imagine in
a modern app like a game,
you also have a bunch of data
that every frame
needs to be updated.
So our draw basically
looks like this.
We want to go through all
the objects we're interested
in drawing and update them.
Then we want to encode
draw calls for every object
and then we have to submit
all these GPU commands.
We have a lot of objects.
We started at 10,000
and we were cranking it
up to up to 100, 200,000.
Each of these objects has its
own set of data and we have
to figure out the best
way to update this.
Now in the past, you might've
done something like this.
You push updated data to
the GPU, maybe uniforms
or something, you bind
a shader, some buffers,
some textures, and you draw.
And you push some more data up.
You bind shader,
buffers, textures.
You draw your next object.
In our scene we repeat
this 10,000, 20,000 times,
but we really want to get away
from this sort of paradigm
and try something new.
What if we could just
load all our data upfront
and have every command that
we issue reference the data
that was already there.
The GPU is a massively
powerful processer
and it does not like to wait.
So if all our data in already in
place, we can just point the GPU
to it and it will go
happily crunch away
and do all our rendering for us.
And each draw call we make then
references the appropriate data
that's already there.
In our sample, it's
very straightforward.
We have one draw that
references one chunk of data.
So the first draw call
references the first chunk
of data, the second, the
second chunk, and so on.
But it doesn't have
to be that way
and we can actually reuse data.
We have some data, like at
the front here, frame data,
that we can reference
from all our draw calls
that we can reference
from all our draw calls
or we could have a draw call
that references two pieces
of data in different places.
If you're familiar
with instancing,
it's a very similar idea.
All your data will be in place
before you start rendering.
So how do we do this in Metal?
In our application, we create
one single Metal buffer
and this is our constant buffer.
It holds all the data that
we need to render our frame.
We want to create this upfront,
outside of the rendering loop,
and reuse it every time we draw.
We don't duplicate any data.
Again, any draw call can
reference any piece of data,
so there's no need
for duplication.
Each draw call will reference
an offset into the buffer.
It'll do a little bit
of tracking to know
which draw represents
which offset.
And then you'll just
draw with everything
and everything will be in place.
Let's take a look at
the code for this.
Here's the code from the app.
You can think of us as
having two sets of data.
Like I mentioned before,
there's a set of frame data
that will update here
and there's a set of data
that will update here
and there's a set of data
that will change per object.
This is the unique rotation
position, et cetera.
So we need to put both
sets of data in place.
Now what do I mean
by per-frame data?
Well this is data
that is consistent
across every draw call we make.
For example, in our sample we
have a ViewProjection matrix.
It's a 4 by 4 matrix,
very straightforward,
if you're familiar
with graphics.
It represents the camera
transform and the projection.
This is not going to
change throughout our frame,
so we only need one copy of it.
And we'd like to reuse
data as much as we can
so we can create one copy
and put it into our buffer.
Let's start filling this out.
So here, we have
our constant buffer,
which is just a Metal
buffer we've created.
And with the Contents function,
we have a pointer to it.
Our app has a helper function,
which is GetFrameData,
Our app has a helper function,
which is GetFrameData,
and this returns that main pass
structure I just showed you
that has the view
transform in it,
the ViewProjection transform.
Excuse me.
And then we simply just
copy this into the start
of our buffer and
then we're in place.
So our buffer will
look like this.
We'll have a MainPass with the
appropriate data for our frame
and we'll put it at the start
of our giant constant buffer.
So now we have all this
empty space afterwards.
And like we saw, we need to
do 10,000, 20,000 draw calls,
so we need to start filling this
out with a ton of information.
So then we have a set
of per-object data
and this is the unique data we
need to draw a single object.
In our case, we have a single
LocalToWorld transform,
which is the concatenation of
the position and the rotation
and we have the color.
So this is the set of data
we need per draw call.
So we'll walk through every
object we want to render.
We'll keep track of the
offset into the buffer.
We'll keep track of the
offset into the buffer.
We have our updateData
utility function,
which will do our little
update for our rotation,
and then we'll update
the offset.
This will pack our data tightly
and we'll fill it
out as we go through.
Let's take a closer look at
what updateData looks like.
It's quite simple.
Now, animation is kind of out
of the scope of this talk,
so I have a little helper
function here that's
updateAnimation with
a deltaTime.
This could be whatever you
want in your own application
and indeed you should but
depending on what sort
of animation you need.
But it my case it returns
an objectData object
which has the LocalToWorld
transform and the color.
And just as I did before, I
copy it into my constant buffer.
So here's what that looks like.
I've got my frame data in place.
I have my other data, another
piece, and another piece.
I have my other data, another
piece, and another piece.
So all our data is in place
and we're ready for rendering.
But are we missing anything?
Turns out that we are and I want
to bring your attention to this.
We have one constant buffer.
I mentioned I created one Metal
buffer and I was reusing it.
Now there's a problem with this.
The CPU and the GPU are actually
two unique parallel processors.
They can read and write the
same memory at the same time.
So what happens when you have
something reading to a piece
of memory while something
else is writing to it?
Resource contention.
So it looks a little like this.
The CPU prepares a frame
and writes it to a buffer.
The GPU starts working on this
and reads from the buffer.
The CPU doesn't know
anything about this,
so it decides I'm going
to prepare the next frame
and it starts overwriting
the same data.
And now our results
are undefined.
And now our results
are undefined.
We don't actually know what
we're reading to, reading from,
or writing to or what
the data state will be.
So it's important
to realize in Metal,
this is not handled
for you implicitly.
The CPU and GPU can
write the same data
at the same time
however they'd like.
You must synchronize
access yourself.
It's just like writing CPU
code that's multithreaded.
You have to ensure you're
not stomping yourself.
And that brings us to
CPU-GPU synchronization.
Let's start simple.
The easiest way to do this
would to just be to wait
after you've submitted
commands to the GPU.
Your CPU draw function
does all of its work,
submits the commands,
and then just sits there
until it's ensured the
GPU is done working.
That way we know we
won't ever override it
because the GPU will be
idle by the time we try
to generate our next frame.
This won't be fast
but it's safe.
So we need some sort of
mechanism for the GPU
to let us know, hey, I'm done
with this, go do your thing.
to let us know, hey, I'm done
with this, go do your thing.
Metal provides this in
the form of callbacks.
We call them handlers
and there are two of them
that are interesting,
addScheduledHandler
and that executes when a command
buffer has been scheduled
to run on the GPU.
And for us, an even more
interesting one is the
completion handler
and this is called
when the GPU has finished
executing a command buffer.
The command buffer is completely
retired and we're ensured
at this point it's safe to
modify whatever resources
that we were using there.
So this is perfect.
We just need some way to
signal ourselves that, hey,
we're done, we can go forward.
Now how many of you are familiar
with the concept of a semaphore?
Anyone? Pretty good.
Quick background on semaphores.
They are synchronization
primitive and they're used
to control access to
a limited resource
and that fits us perfectly here.
We have one constant buffer
and that's a limited resource,
so we'll have a semaphore
and we'll create it
with a value of 1.
The count on a semaphore
represents how many resources
we're trying to protect.
So we'll create our semaphore.
And again, this is something
that should be created
outside of your render loop.
And the first thing
we do once we start
to draw is we wait
on the semaphore.
Now in Apple semaphore,
we call it waiting.
Some people call this taking.
Some people call it downing.
It doesn't really matter.
The idea is that you wait
on it and our timeout we set
to distant future,
which effectively means
we'll wait forever.
Our thread will go to sleep
if there's nothing available
and wait for something to do.
When we're done,
in our completion handler we
will signal the semaphore.
That'll tell us that it's safe
to modify the resources again.
We're completely done with
it and we can go forward.
So this is sort of a naive
approach to synchronization
but it looks a little like this.
Frame 0 we'll write
into the buffer.
And on the GPU, we'll
read from the buffer.
And on the GPU, we'll
read from the buffer.
The CPU will wait.
When the GPU is done
processing Fame 0,
it will send the completion
handler and frame 1 will work
and create another
frame on the CPU.
And that will process
on the GPU and so on.
So this works but,
as you can see here,
we have all these
waits and both the CPU
and GPU are actually
idle half the time.
It doesn't seem like a good
use of our computing resources.
What we'd like to do is overlap
the CPU and the GPU work.
That way we can actually
leverage the parallelism that's
inherent in this
system, but we still need
to somehow avoid
stomping our data.
So we'd like our ideal
workload to look like this.
Frame 0 would be prepared on
the CPU, pushed to the GPU.
While the GPU is processing
it, the CPU then gets
to work creating frame
1 and so on, and again.
So one thing to keep
in mind here is
that the CPU is actually getting
a little ahead of the GPU.
that the CPU is actually getting
a little ahead of the GPU.
If you notice where
frame 2 is on the CPU,
frame 0 is the only thing
that's done on the GPU.
So we're a little bit ahead
and I want you to keep
that in mind for a little later.
But first let's talk
about our solution
in the demo and what we do here.
We'd like to overlap our CPU and
GPU but we know we can't do it
with one constant buffer
without waiting a lot.
So our solution is to
create a pool of buffers.
So when we create a frame,
we write into one buffer
and then our CPU proceeds
to create the next frame while
writing into another buffer.
While it's doing this, the GPU
is free to read from the buffer
that was produced before.
Now we don't have an
infinite number of buffers
because we don't
have infinite memory.
So our pool has to have a limit.
On our application,
we've chosen three.
This is something that you
need to decide for yourself.
We can't tell you what to
do because there are a lot
of things that go into
the latency consideration,
how much memory you want to use.
So we recommend you experiment
with your app what fits for you.
So we recommend you experiment
with your app what fits for you.
For this example,
we've chosen three.
So here, you can see
we've exhausted our pool.
We have three frames
that have been prepared
but only one is finished
on the GPU.
So we need to wait a little bit.
But by now, frame 0 is done,
so we can reuse the buffer
from the pool and so on.
So let's look at this in code.
Here's synchronizing
access to constant buffers.
We've already got a
semaphore and they're great
for controlling access
to limited resources.
In this case our limit is three
but it can be whatever
you'd like.
So here we create our
semaphore with our count.
And instead of creating
one constant buffer,
we now create an array of them.
And lastly, we need an index
and we'll use this index
to represent the currently
available constant buffer
for us to use.
We can walk through the
array and wrap around
We can walk through the
array and wrap around
and the semaphore will control
our access and protect us.
So in our draw function,
we'll immediately wait
on the semaphore, and if
there's nothing available,
we'll go to sleep.
Once we've taken the semaphore
and proceeded, we know it's safe
for us to grab the
current constant buffer.
In our index, current
constant buffer is tracking
which one's available.
Then we fill out our frame as
normal, encode all our commands,
do all our updates, add
the completion handler,
and then we'll signal the
semaphore, saying, hey,
we're done with this frame.
You can go forward.
And the last thing we need
to do is update the index.
We'll add one.
We'll use modulo to wrap around.
And don't worry, we
don't have to worry
about overwriting ourselves
because the semaphore
will protect us.
So constant buffers in the demo.
The demo has an array
of three buffers
and I've seen some
applications track buffers
by marking them as,
oh, this is being read
from in frame number
7, this is written
to you in frame number 5.
But with this model you don't
actually have to do that.
The semaphore takes care of all
the synchronization for you.
And if you can take the
semaphore, you're guaranteed
that the last frame that
was using that was done,
otherwise you'd still be asleep.
So now all our data is in
place and it's protected.
And we'd like to start
issuing a bunch of draw calls
to get some stuff on the screen.
So here's the basic
rendering loop for our demo.
We have two passes: One
pass that draws a shadow map
and one pass that reads the
shadow map, and we've decided
to split these into two
separate command buffers.
There's a good reason for this.
It lets us have two
encoding functions
that are independent and unique.
They don't depend on each other.
You encode the shadow pass.
You pass that to command
buffer and the constant buffer
that you've already filled out
and it encodes all the commands
to render the shadow map.
And then you have a
separate encoding function
that encodes the main pass.
You pass it to mainCommandBuffer
and the other data you need
You pass it to mainCommandBuffer
and the other data you need
and it encodes all
those other commands.
When the encoding is all
done, you call commit
on your two command
buffers, push them off,
and then you've got your frame.
So what goes into actually
encoding drawing one
of our cubes?
We need a bunch of data and
not just the rotation data.
We need some geometric
data for the cubes,
which is quite simple, you know,
think about a cube is what,
eight vertices, maybe
an index buffer.
And in our sample, we don't
really have complex materials
or anything, just some very
simple Lambert shading.
So we could reuse that
pipeline state object
across all of our cubes.
We mentioned the
per-frame data earlier.
We need one copy of that.
So we'll update it.
Stick it in place.
And then of course we
need the per-object data,
that LocalToWorld and
the color information
that we're animating.
So when we issue our draw calls,
we want to make sure we
reference the correct data.
So our encoder will
produce commands,
put them into our
command buffer,
put them into our
command buffer,
draw call 0 will reference both
the frame data and the object
that we're interested in.
Draw call 1, similarly, will
reference the frame data
and the object 1 data and so on.
This way everything's in place.
We issue our calls and the
GPU will start crunching away.
Now we have a ton of
draw calls to issue.
You know, in our demo,
it was minimal, 10,000,
and we want to issue these
as efficiently as possible.
So we'd like to avoid
doing redundant work.
We don't want to reset
everything every draw.
Anything that's shared,
geometry, pipeline states,
we'd like to set that once
and leave that in place.
So avoid redundant state updates
and avoid redundant
argument table updates.
It's also worth keeping
in mind that the vertex
and fragment stage argument
tables are completely separate.
You can bind a buffer to
the vertex stage and not
to the fragment stage
or vice-versa.
But if you have to bind
everything to both stages,
this can potentially double
the calls you call the
this can potentially double
the calls you call the
setVertexBuffer,
setFragmentBuffer.
This is one reason we didn't use
set vertex bytes in our example.
You can imagine we have
50,000 objects and we had
to make a copy of all that data
twice, once for the vertex stage
and once for the fragment stage.
That would quickly
get really big.
But if we kept it all in one
buffer and just referenced it,
we wouldn't have to
worry about that.
And the last guideline
I want to point
out is using a new function,
setVertexBufferOffset/
setFragmentBufferOffset.
This merely changes the pointer
into one of your buffers.
So you can see here
when you call these,
they actually don't take a
reference to a Metal buffer.
They take an offset
and an index.
This is because you must
have already set the buffer
to that specific point and
this just changes the pointer
within it and that's
perfect for what we want.
We have one constant buffer and
we're just walking through it.
So we can set it
once in the beginning
and then every time we draw,
we call setVertexBufferOffset
and then every time we draw,
we call setVertexBufferOffset
and just point the
next draw call
to the current spot
in our buffer.
It looks a little
something like this.
We bind this constant buffer
and then we call
setVertexBufferOffset
with this offset.
Then we call it again
striding it forward
and again striding it forward.
We're not changing the buffer
that we've set to this index.
We're just changing the
offset within that buffer.
With these guidelines in mind,
our encoding is actually
pretty simple.
We have a bunch of data
we can set up front.
The per-frame constants
is pretty obvious
because we know we're
not going to change it.
So we'll set that.
We'll set the constant buffer
once because we know it has
to be in place for us to use the
setVertexBufferOffset function.
We'll set the geometry
buffer and the pipeline state
because we know they're shared
across all of our cubes.
Then finally we can
start looping
through all the objects
we want to draw.
We'll set the offset
into the constant buffer
We'll set the offset
into the constant buffer
for our current draw.
And then we'll actually
issue the draw.
And here's the code from the
encode main pass function
in the sample.
We'll start off by
setting the vertex buffer
that is our geometry and
the render pipeline state,
which is our
litShadowedPipeline.
We'll set the constant buffer
so we can use
setVertexBufferOffset later.
In this case we're setting
it to both the vertex
and the fragment stages.
And then we'll set
the per-frame data.
Now you'll notice here that
I've set the constant buffer
to two separate indices
with different offsets.
And Metal allows you to do
this as much as you want.
You could set the same
constant buffer to every index
at a different offset if you'd
like, completely up to you.
And then we dive
right into our loop.
We need to track the
offset because we know
that we're not starting
right at the beginning
of our constant buffer.
There's some frame
data in there.
So the offset will be pushed
back past the frame data.
Then we'll call
setVertexBufferOffset
and setFragmentBufferOffset
to point this draw
to the correct data that
we want to draw with.
We'll issue the draw call
and then we'll set the offset
again just striding one object
data struct at a time.
So our draws are in place.
This is still very linear.
And I promised you
some multithreading
and Warren mentioned that, hey,
you can actually encode a bunch
of stuff in parallel in Metal.
So how would you do this?
An ideal frame might
look like this.
Our render threat is chugging
along and it realizes, hey,
I need to render a
shadow map and I need
to render a main pass.
It'd be great if I could
code this in parallel.
I've got multiple CPUs.
So what if I dispatch this
work out, encoded some stuff,
then I rejoin back
to the render thread
and the render thread
pushed this over to the GPU
to do a bunch of work.
This would look great.
How many of you have used GCD?
This is a great fit for
Grand Central Dispatch.
If you're not familiar,
Grand Central Dispatch is
Apple's multiprocessing API.
This is an API that
lets you create queues
and these queues manage
computing resources
on your machine.
There are two types of
queues you can create.
There's a serial queue.
When you dispatch work through a
serial queue, you're guaranteed
that all that work
will happen in order.
But what's more interesting
for us is the concurrent queue.
When you dispatch work to the
concurrent queue, GCD will look
at your system and
figure out the best way
to schedule this for you.
And that's perfect.
We have two jobs we
need to do in parallel.
So if we created this one queue
and just pushed the work to it,
it would do that for us.
This is another object you
want to create once and reuse.
So here's some code to create
a concurrent dispatch queue.
You should always a
label on your queues.
I've used the very
creative label queue here
but you might want to
call it something else.
So we made some modifications
to the code.
We still create the command
buffers at the start.
But since we were smart enough
to use two command buffers
and separate our
encoding functions
into two unique things,
there isn't much else for us
to do other than
dispatch the work.
So dispatchQueue.async
is the main call you use
to dispatch work
to a queue in GCD.
This is an asynchronous call.
It'll push the work on and
your thread will keep going.
So here we dispatch
the shadow pass
and then we dispatch
the main pass.
We'll want to commit
this work somehow
so we call dispatch barrier
sync and this makes sure
that all the work is done by
the time we get to this point.
And then finally we've rejoined
and we can commit our work.
Now the ordering
is important here.
The shadow map has to be done
by the time we reference it.
So we have to commit the
shadow command buffer first
So we have to commit the
shadow command buffer first
and then the main
command buffer later.
There's something else
I want to bring up here.
How many of you are familiar
with the concept of a closure?
Great. How many of you
have ever had an issue
where closures captures self
and you thought you were
referencing something else?
You can be honest.
It's happened to all of us.
I just wanted to call this out.
Closures capture self.
So if you're referencing a
member variable or an iVar
within them and you're not
explicitly saying self.iVar,
it's still actually going
to reference that variable.
So if you want to
make sure you're going
to reference the correct
data, it's a good idea
to capture it outside and
I'll show you what I mean
in a second.
These two things don't
do the same thing.
So in the first one where
I encode the shadow pass,
you can see the constant buffer
I'm grabbing is dependent
on self.constantBufferSlot.
I don't actually know what that
will be at the time it executes.
This is really asynchronous
programming.
This is really asynchronous
programming.
So by the time my dispatch
is actually running,
this could've changed
behind my back.
It may be right but
it may not be.
I can't guarantee it.
So keep that in mind and
don't do it that way.
Instead, we'd like to
capture a reference
to the constant buffer
we're interested in.
So here we just say
let constant buffer
and grab it out of the array.
But then when we
issue our dispatch,
we reference the specific one
that we've already grabbed.
That makes sure we know exactly
what data we're reading from.
So this is some multithreading
fun.
The actual code in the
sample looks like this.
We capture the constant buffer.
And when we use it, we make sure
we're using the correct one,
the one that we've
captured already,
to know that we're using
this frame's constant buffer.
Now I had mentioned
the ordering earlier
and how this was important.
When you create a command buffer
and you commit it, the ordering
When you create a command buffer
and you commit it, the ordering
that this executes on
your GPU is implied
by the order you commit it in.
So if I commit the shadow
command buffer first
and the main command buffer
second, I'm guaranteed
that the shadow one will happen
first on the GPU followed
by the main command buffer.
Sometimes we refer to this
as implicit command
buffer ordering.
But you can be a little
more explicit about it.
Metal provides an
enqueue function
that enforces command
buffer ordering.
If you have a set of command
buffers, you can enqueue them
and you're guaranteed
that they will execute
in that order regardless
of how you commit them
or when you commit them.
This is something really
cool because it allows you
to commit command buffers from
multiple threads, in any order,
and you don't have
to worry about it.
The runtime will ensure you're
executing in the correct order.
So let's see how to
apply this to our code.
A couple new additions here.
Now when we create
our command buffers,
we immediately enqueue
them in the order.
Again, the order
matters, so we still have
to enqueue shadowCommandBuffer
first
to enqueue shadowCommandBuffer
first
and then mainCommandBuffer
second.
But now when we dispatch,
we can actually commit
from within our other thread.
Again, the runtime is going
to ensure the ordering.
So we don't actually
have to worry about it.
This actually lets us remove
that barrier we had before
because we have no
need to rejoin
and commit the command buffers.
They're already committed
for us.
But I seem to have
skipped over all
that synchronization stuff
I talked about a second ago
and we still need it
because we're still going
to be overriding ourselves
if we don't have it.
So can we apply these same
synchronization lessons
to this sort of multithreaded
world?
It turns out we can and it's
actually quite straightforward.
We bring back our
friendly semaphore
and our array of
constant buffers.
And again, don't forget to grab
the correct one that you want.
At the start, we'll wait
on the semaphore and sleep
if nothing's available.
We've enforced our ordering with
enqueue and we push it through.
We've enforced our ordering with
enqueue and we push it through.
Now we know
that mainCommandBuffer is
the final command buffer
in our frame.
And we know that we want to
signal that our frame is done.
So we should add our completion
handler to the mainCommandBuffer
and you could do this
from within the dispatch.
So the mainCommandBuffer is
the final command buffer.
We add the completion handler
to it, to signal our semaphore,
and we commit it from
within the dispatch,
just like we did before.
Now you may notice here that
I'm referencing self.semaphore
and a second ago I just told
you to watch out for that.
So what's going on?
Well it turns out a semaphore
is a synchronization primitive
and we do actually want to
be looking at the same one
as all of our other threads.
So we want the value
of the semaphore
at the time the thread
is executing.
So in this case, we
actually want self.semaphore,
something to keep aware of.
And here's the recipe
for our rendering.
At the start of our
render function,
At the start of our
render function,
we wait on the semaphore.
We select the current
constant buffer.
We write the data into
our constant buffer
that represents all
of our objects.
We encode the commands
into command buffers.
We can do the single-threaded,
multithreaded, however
you'd like.
We add a completion handler
onto our final command buffer
and we use it to signal the
semaphore to let us know
when we're done and we
commit our command buffers.
And the GPU takes all this
and starts chugging
away at our frame.
So let's look at the demo
again and see what this got us.
So here you can see
in the top left,
this is single-threaded
encode mode
and you can see how many
draws we're issuing, 10,000.
And the top right, you can
see the time it takes us
to encode a frame.
So here we've got 5 milliseconds
and we can crank the number
of draws up and see that
it starts costing more
and more as we draw things.
Now this is single-threaded
mode.
Now this is single-threaded
mode.
And when you think about it,
we're drawing a shadow map,
which means we have to issue
40,000 draws in the shadow map,
and then we're drawing the
main pass, which means we have
to issue another 40,000
draws to reference that.
But again, we can
do this in parallel,
so we've added a parallel
mode to this demo.
And you can see how it's
faster to go through.
Now take a look at
everything that's going on.
You can fly around a little bit.
So here we have 40,000
cubes, unique, independent.
They're all being updated.
We're using GCD to encode a
bunch of stuff in parallel.
We have two command buffers:
One to generate the shadow map
on the ground and one to render
all of the cubes in color.
The lighting is quite
simple, Lambert shadowing,
which is basically
what Warren talked
about earlier, the N.L lighting.
And that's our demo.
This will be available
as sample code
for you guys to take a look at.
Hopefully you can rip it
apart, take some of the ideas
and the thoughts in it and
apply them to your own code.
So what did we talk about today?
When you walked in
here, hopefully you came
to Warren's session earlier
and maybe you knew a little bit
about graphics or had done
some programming before,
but we took you through
everything in Metal.
The conceptual overview
of Metal, the reasoning
around it is to use an API
that is close to the hardware
and close to the driver.
We learned about the Metal
device, which is the root object
in Metal that everything
comes from.
We talked a bit about
loading data into Metal
and the different resource
types and how you use them,
the Metal shading language,
which is the C++ variant you use
to write programs on the GPU.
We talked about building
pipeline states,
prevalidated objects that
contain your two functions,
vertex and fragment
or a compute function,
vertex and fragment
or a compute function,
and a bunch of other
baked-in, prevalidated state
to save you time at runtime.
Then we went into
issuing GPU commands,
creating a Metal queue, creating
command buffers off that queue,
and creating encoders to
fill the command buffer in,
and then issuing that work and
sending it over to the GPU.
We walked you through
animation and texturing
and using set vertex bytes
to send small bits of data
to do your animation in.
Then when the small bits
of data weren't enough,
we talked about managing
large chunks of dynamic data
and using one big constant
buffer and referencing it
in multiple places to get some
data reuse out of the system.
We talked about CPU-GPU
synchronization, the importance
of making sure your CPU and your
GPU aren't overriding each other
and playing nicely.
And then lastly, we
talked a little bit
about multithreaded encoding,
how you can use GCD with Metal
to encode multiple
command buffers
on your queues at the same time.
And that's adopting Metal.
Hopefully you enjoyed the talk
and you can apply some of these
to your apps and make
your apps even better
than they already are.
If you'd like some more
information, you can check
out this website,
developer.apple.com/wwdc/603.
We have a few more
sessions tomorrow
that I recommend
you go check out.
At 11:00 o'clock, we
have What's New in Metal,
Part 1 and then a
little later at 1:40,
we have What's New
in Metal, Part 2.
That'll tell us everything
that's new in the world
of Metal, awesome
stuff you can add
to your applications
to make them better.
And then for you hardcore
shader heads out there,
we have Advanced Metal
Shader Optimization at 3:00.
So if you want to know
how to get the best
out of your shaders, I recommend
you go check out that talk.
It's really great.
Thanks for coming
to hear us talk.
Welcome to WWDC.
Have a good rest of the week.
Thanks again.