hi I'm Ellen hooks you may have seen
some news about Intel's upcoming
discrete GPUs I've gotten some questions
about what happens if I put one of these
Intel discrete GPUs in a system that
already has Intel integrated graphics my
answer is it would be a lot like
existing systems with discrete graphics
many systems with an Intel CPU also have
integrated graphics but most games only
use discrete GPU in this video I show
how we can use standard D 312 api's to
add the performance of the integrated
GPU and a system that also has a
discrete GPU here are a couple typical
gaming platforms the desktop pairs an
Intel CPU with integrated graphics and a
discrete GPU the notebook also contains
Intel integrated graphics and a discrete
GPU they integrated in here is about 50%
of the performance of the discrete GPU
that's a lot of performance who really
like to tap into let's look at an
example that shows the two GPUs working
together this is a particle simulation
based on Microsoft's d3 d12 embody
particle sample originally it used a
sink compute to run simulation and
rendering in parallel on one GPU I've
modified it to put compute and render on
different GPUs and added a copy step
that also runs in parallel I can choose
which GPU is rendering particles in
which GPUs computing particle positions
let me show you how this works then I'll
explain how it's implemented there are
three things happening in parallel new
particle positions are computed on the
integrated GPU the previous results are
being copied to the discrete GPU and the
discrete GPU as rendering results that
are another frame older when vsync is
off the frame time is just whichever of
these three stages takes the longest by
adjusting the number of particles
rendered frame time roughly equals the
render time the rendering art effects
are because it's rendering particles
that are currently animating by
adjusting the number of particles
simulated I can adjust the compute time
now frame time is limited by compute
time and by adjusting a number of
particles copied we can see the time to
copy over the PCIe bus as long as either
the render or compute takes more time we
can hide the overhead of copying when
one GPU is the bottleneck we can see the
others power policy slow it down to save
power there's an Intel extension that
effects this and our online sample shows
more details right now I can see that
the simulation time is taking a little
over 14 milliseconds because we're
bottleneck on renders
if I reduce render time so it is below
14 milliseconds will see the power
policy speed up the simulation time
because it's speeding up the integrated
graphics takeaway here is if your game
has already bought an electron during
you can offload work to the integrated
GPU with little overhead the first step
is to enumerate adapters then create a D
3d device for each adapter while doing
this you can figure out which GPU is
integrated we know one to share data
between the devices but d 3d won't let
us just copy resources between them we
need to create cross adapter shared
resources those resources reside in a
cross adapter shared heap cross adapter
shared heaps reside in system memory
that's interesting because integrated
GPU street system memory as local memory
here I create a cross adapter shared
heap first determine the align size of
our shared resources create the heap on
one device it doesn't matter which set
both the shared and cross adapter shared
flags and use a handle to open the heap
on the other noise now we can create
placed resources on each device using
the align data size note we can create
the memory with an initial state that
matches each GPUs usage model the
discrete adapter will use the resources
as srvs while the compute adapter will
use them as UAVs depending on the format
of the data and your GPUs capabilities
shaders might be able to directly read
from shared memory but the performance
may not be acceptable
the key to performance is for GPU
shaders to always access physically
local memory by creating a copy queue on
the discrete adapter I can copy from
shared memory to local memory and be
sure that copy happens in parallel with
everything else now we can look at the
final recipe for particles of multi-gpu
a three stage pipeline of compute copy
and render the integrated GPU simulates
positions within its local memory using
cross adapter shared resources the
discrete adapter renders an older
version of the particle positions from
its local memory the key ingredient is
the copy queue on the discrete GPU it
explicitly copies from shared system
memory to local memory that way the copy
can run in parallel and everyone gets to
use a local memory all the Q's ping-pong
between buffers per frame
cross adapter shared fences synchronized
these per frame operations there aren't
many cross adapter fences and didn't
find them to be very expensive relative
to all the other work in GPU view we can
see the command by first four three twos
are all synchronized following this
recipe many similar algorithms could be
moved to the integrated device like
physics aru shadows the main feature of
this recipe is the producer-consumer
pattern integrated graphics treats
shared resources as physically local and
data flows one way from system memory to
discrete memory D 312 api's work well
for this pattern and it applies to any
situation where there's both an
integrated GPU and a discrete GPU even
from different vendors many async
compute applications already use this
pattern to learn more follow the links
provided thanks for watching
[Music]