WEBVTT

00:00:00.040 --> 00:00:02.480
The following content is
provided under a Creative

00:00:02.480 --> 00:00:04.000
Commons license.

00:00:04.000 --> 00:00:06.340
Your support will help
MIT OpenCourseWare

00:00:06.340 --> 00:00:10.710
continue to offer high quality
educational resources for free.

00:00:10.710 --> 00:00:13.320
To make a donation or
view additional materials

00:00:13.320 --> 00:00:17.190
from hundreds of MIT courses,
visit MIT OpenCourseWare

00:00:17.190 --> 00:00:17.815
at ocw.mit.edu.

00:00:22.000 --> 00:00:24.000
PRAMOOK KHUNGUM: Hi, my
name is Pramook Khungum.

00:00:24.000 --> 00:00:26.100
I'm supposed to be one
of four, but it remains

00:00:26.100 --> 00:00:29.200
that I am the only one now.

00:00:29.200 --> 00:00:33.100
So my project was about
global illumination.

00:00:33.100 --> 00:00:37.230
And it's about
rendering 3D scenes.

00:00:37.230 --> 00:00:40.700
So first, let me tell you about
the direct illumination model.

00:00:40.700 --> 00:00:45.020
This is something you can
achieve with ray tracing.

00:00:45.020 --> 00:00:47.760
As you can see,
the image above is

00:00:47.760 --> 00:00:51.310
rendered by shooting
a ray from your eyes,

00:00:51.310 --> 00:00:54.780
and then taking
the local lighting

00:00:54.780 --> 00:00:57.270
properties of the
materials, and then

00:00:57.270 --> 00:01:00.020
see whether there's a light
coming to that point or not,

00:01:00.020 --> 00:01:01.990
and then figure out the color.

00:01:01.990 --> 00:01:05.290
So in this model, there's a lot
things unnatural about this.

00:01:05.290 --> 00:01:08.090
Because as we can see, the
light is an area light,

00:01:08.090 --> 00:01:11.650
but then the shadow
is very solid shadow

00:01:11.650 --> 00:01:14.960
as if it's lit by a point
light or something like that.

00:01:14.960 --> 00:01:19.260
And you can see that the
ceiling is not lit at all.

00:01:19.260 --> 00:01:21.980
This means that this
model of lighting

00:01:21.980 --> 00:01:23.850
doesn't take into
account the light that

00:01:23.850 --> 00:01:26.630
bounces between the
walls and lighting

00:01:26.630 --> 00:01:35.830
parts that should have been
lit in the real life scene,

00:01:35.830 --> 00:01:36.740
as you can see.

00:01:36.740 --> 00:01:41.460
So global illumination
basically tries to fix that.

00:01:41.460 --> 00:01:45.340
And the effects you can achieve
with global illumination

00:01:45.340 --> 00:01:50.850
algorithms are
basically soft shadows,

00:01:50.850 --> 00:01:53.240
color bleeding-- you
can see that there's

00:01:53.240 --> 00:01:57.110
a very pale shades
of blue here--

00:01:57.110 --> 00:02:00.200
and caustics, which means
that light from here

00:02:00.200 --> 00:02:05.180
goes through the glasses
and then focus on here.

00:02:05.180 --> 00:02:09.750
So at first when I
started the project,

00:02:09.750 --> 00:02:12.440
I wanted to globally illuminate
a very simple scene, which

00:02:12.440 --> 00:02:14.090
is the Cornell Box.

00:02:14.090 --> 00:02:18.920
So it's basically this box, and
you replace these two spheres

00:02:18.920 --> 00:02:20.634
with two white boxes.

00:02:20.634 --> 00:02:22.800
And then you can observe
color bleeding in something

00:02:22.800 --> 00:02:25.360
like that.

00:02:25.360 --> 00:02:30.090
And I wanted to do it in
real time with caustics.

00:02:30.090 --> 00:02:35.980
However, the things I
accomplished are-- well,

00:02:35.980 --> 00:02:39.620
I globally illuminated the
Cornell Box as I promised.

00:02:39.620 --> 00:02:42.560
In real time--
no, it's too slow.

00:02:42.560 --> 00:02:46.580
With caustic, didn't
implement photon mapping.

00:02:46.580 --> 00:02:49.380
And sadly, there's still a
lot of room for optimization.

00:02:49.380 --> 00:02:54.740
So kind of disappointed
myself a little bit, but yeah,

00:02:54.740 --> 00:02:56.910
that's fine.

00:02:56.910 --> 00:03:03.080
So the algorithm I used
for global illumination

00:03:03.080 --> 00:03:04.820
is called Instant Radiosity.

00:03:04.820 --> 00:03:08.500
It's by some German guy
called Alexander Keller.

00:03:08.500 --> 00:03:11.260
It's good for scenes with
diffuse objects, which

00:03:11.260 --> 00:03:13.860
means that scenes
that doesn't have

00:03:13.860 --> 00:03:18.630
objects that reflect light or
lets light transmit through.

00:03:18.630 --> 00:03:23.360
Diffuse objects can be just this
table and something like that.

00:03:23.360 --> 00:03:25.620
Basically, it means that
when light strikes it,

00:03:25.620 --> 00:03:29.220
it just bounces off randomly.

00:03:29.220 --> 00:03:32.520
As such, it can't do
caustics, although it

00:03:32.520 --> 00:03:35.900
is very simple to implement
once you have the core.

00:03:35.900 --> 00:03:37.740
So let me describe
the algorithm.

00:03:37.740 --> 00:03:39.640
You start with the
light source, and then

00:03:39.640 --> 00:03:43.260
you emit artificial
light particles

00:03:43.260 --> 00:03:46.860
and let them bounce
around the scene.

00:03:46.860 --> 00:03:49.650
And then you will have
some more light source.

00:03:49.650 --> 00:03:52.490
And then you ray trace
using those light sources

00:03:52.490 --> 00:03:55.830
in the scene basically.

00:03:55.830 --> 00:03:58.600
So this is the illustration
of the algorithm.

00:03:58.600 --> 00:04:01.730
First, you have the
light, which goes off

00:04:01.730 --> 00:04:05.570
from this square light.

00:04:05.570 --> 00:04:08.330
And then you illuminate
the scene with it.

00:04:08.330 --> 00:04:09.830
And then you bounce
some lights off,

00:04:09.830 --> 00:04:11.500
and then illuminate the scene.

00:04:11.500 --> 00:04:13.610
Then you combine the
results, basically.

00:04:16.380 --> 00:04:21.200
So in my implementation,
at the beginning,

00:04:21.200 --> 00:04:24.410
I have one SPU scatter
all the light particles.

00:04:24.410 --> 00:04:29.080
The number of light particles
I scattered is about 128.

00:04:29.080 --> 00:04:31.510
And as they bounce
around, it ends up

00:04:31.510 --> 00:04:35.850
to be about 250 light
sources in total.

00:04:35.850 --> 00:04:40.510
And then I rendered a scene
by splitting the scene

00:04:40.510 --> 00:04:46.780
into horizontal slabs, and then
just give the slabs to each SPU

00:04:46.780 --> 00:04:48.050
to render.

00:04:48.050 --> 00:04:51.340
In this way, since the
scene is very small,

00:04:51.340 --> 00:04:55.080
it can just preload
them to every SPU.

00:04:55.080 --> 00:04:57.060
And they all can
work independently.

00:04:57.060 --> 00:05:02.360
So there's minimal
communication going around.

00:05:02.360 --> 00:05:08.479
And since I didn't implement
any other smart data structure

00:05:08.479 --> 00:05:10.020
to take care of the
geometry, it just

00:05:10.020 --> 00:05:11.620
used bruteforce ray tracing.

00:05:11.620 --> 00:05:14.752
My scenes have only
eight objects anyway.

00:05:14.752 --> 00:05:16.766
I wasn't maybe it
might be a good point

00:05:16.766 --> 00:05:18.224
to see if there's
[? a question. ?]

00:05:21.210 --> 00:05:24.376
AUDIENCE: So the SPUs are
doing rendering or ray tracing?

00:05:24.376 --> 00:05:26.250
PRAMOOK KHUNGUM: Ray
tracing, yes, basically.

00:05:26.250 --> 00:05:29.480
AUDIENCE: But I mean, can a ray
move from one slab to another

00:05:29.480 --> 00:05:32.390
depending on reflection
or something?

00:05:32.390 --> 00:05:34.030
PRAMOOK KHUNGUM: No.

00:05:34.030 --> 00:05:36.690
Basically, if you
trace the light there,

00:05:36.690 --> 00:05:38.730
the SPU has all the
ascription of the scene,

00:05:38.730 --> 00:05:41.110
so it can trace the ray
throughout the scene.

00:05:41.110 --> 00:05:44.405
But it's responsible for
only the pixels in the slab.

00:05:44.405 --> 00:05:45.214
AUDIENCE: Oh, OK.

00:05:47.940 --> 00:05:50.280
PRAMOOK KHUNGUM: The
complexity is kind of bad

00:05:50.280 --> 00:05:56.580
because the time is
you have your image

00:05:56.580 --> 00:06:00.200
size, the number of pixels times
the number of light particles,

00:06:00.200 --> 00:06:01.570
which is about 200.

00:06:01.570 --> 00:06:04.720
And then since I used
bruteforce ray shooting,

00:06:04.720 --> 00:06:07.750
you have to times by
the size of objects.

00:06:07.750 --> 00:06:10.710
But at first, I thought
I have only eight objects

00:06:10.710 --> 00:06:15.350
anyway so it's not going to
be a big performance rack.

00:06:15.350 --> 00:06:17.200
But then I came
to the realization

00:06:17.200 --> 00:06:20.660
that this algorithm
initially was conceived

00:06:20.660 --> 00:06:25.740
for using with programmable
graphics hardware, which

00:06:25.740 --> 00:06:29.260
can do really dumb tasks like
taking a point light source

00:06:29.260 --> 00:06:32.910
and illuminating a scene
with shadows very fast.

00:06:32.910 --> 00:06:36.250
So it turns out that this
algorithm is not really suited

00:06:36.250 --> 00:06:37.730
for the [? Cell, ?] basically.

00:06:40.750 --> 00:06:43.476
I wish I could have
done better on this.

00:06:43.476 --> 00:06:51.180
This 512 times 512 scene
took 20 seconds to render

00:06:51.180 --> 00:06:55.300
on the [? Cell. ?] But
the original paper, they

00:06:55.300 --> 00:06:57.270
rendered something
a little bigger

00:06:57.270 --> 00:07:00.981
than this in 24 seconds
with GPU basically,

00:07:00.981 --> 00:07:02.230
so it's kind of disappointing.

00:07:02.230 --> 00:07:03.750
PROFESSOR SAMAN: [INAUDIBLE].

00:07:03.750 --> 00:07:05.460
PRAMOOK KHUNGUM: Hello?

00:07:05.460 --> 00:07:08.866
PROFESSOR SAMAN: 24 seconds
on what type of a machine?

00:07:08.866 --> 00:07:10.640
Can you hear me?

00:07:10.640 --> 00:07:12.830
PRAMOOK KHUNGUM: Yes,
but not very clearly.

00:07:12.830 --> 00:07:15.199
AUDIENCE: 24 seconds on
what kind of a machine?

00:07:15.199 --> 00:07:18.060
PROFESSOR SAMAN: The original
paper took 24 seconds?

00:07:18.060 --> 00:07:23.200
PRAMOOK KHUNGUM: 24 seconds on
a 75 megahertz something machine

00:07:23.200 --> 00:07:24.779
with a GPU.

00:07:24.779 --> 00:07:25.612
PROFESSOR SAMAN: OK.

00:07:25.612 --> 00:07:30.910
And did you try without using
any SPU, just using CPU?

00:07:30.910 --> 00:07:35.130
PRAMOOK KHUNGUM: Just using the
CPU and the GPU and that one.

00:07:35.130 --> 00:07:37.130
PROFESSOR: His question
was, did you try using--

00:07:37.130 --> 00:07:40.106
PROFESSOR SAMAN: If you just
use CPU without any parallelism,

00:07:40.106 --> 00:07:42.590
how much time does it take?

00:07:42.590 --> 00:07:44.285
PRAMOOK KHUNGUM:
Oh, times that by 6.

00:07:48.400 --> 00:07:52.650
However, the speedup is
proportional to the number

00:07:52.650 --> 00:07:54.580
of processors you used.

00:07:54.580 --> 00:07:58.492
I basically graphed the runtime
with the number of processors.

00:07:58.492 --> 00:07:59.700
This is in [INAUDIBLE] scale.

00:07:59.700 --> 00:08:03.270
So as you can see,
it-- so that's

00:08:03.270 --> 00:08:08.588
the best you can do about
parallelism there, basically.

00:08:08.588 --> 00:08:10.420
AUDIENCE: [INAUDIBLE].

00:08:10.420 --> 00:08:12.170
PRAMOOK KHUNGUM: Yes?

00:08:12.170 --> 00:08:16.594
AUDIENCE: So runtime is
normalized to just the PPU?

00:08:16.594 --> 00:08:17.885
PRAMOOK KHUNGUM: Using the SPU.

00:08:20.978 --> 00:08:23.620
AUDIENCE: So what are
the units for the y-axis?

00:08:23.620 --> 00:08:27.169
PRAMOOK KHUNGUM: The y-axis
is runtime in seconds.

00:08:27.169 --> 00:08:27.835
AUDIENCE: I see.

00:08:27.835 --> 00:08:31.840
So 3.7 seconds, 3.6
seconds for one SPU?

00:08:31.840 --> 00:08:32.760
PRAMOOK KHUNGUM: Yes.

00:08:32.760 --> 00:08:36.070
3.6 seconds per one SPU.

00:08:36.070 --> 00:08:39.990
And as you increase,
the times go down.

00:08:39.990 --> 00:08:42.980
You just divide that by that.

00:08:42.980 --> 00:08:45.265
Is that clear?

00:08:45.265 --> 00:08:48.280
AUDIENCE: And they're all
using the PPU as well?

00:08:48.280 --> 00:08:50.485
PRAMOOK KHUNGUM: No, the
PPU doesn't do anything.

00:08:50.485 --> 00:08:51.085
I just used--

00:08:51.085 --> 00:08:53.710
AUDIENCE: Sorry, did you say 20
seconds on your previous slide?

00:08:53.710 --> 00:08:55.959
PRAMOOK KHUNGUM: This is
different [? image ?] slides.

00:08:55.959 --> 00:08:56.834
AUDIENCE: 128 by 128.

00:08:56.834 --> 00:08:57.708
PRAMOOK KHUNGUM: Yes.

00:08:57.708 --> 00:08:58.525
AUDIENCE: Oh, OK.

00:08:58.525 --> 00:08:59.170
OK, different--

00:08:59.170 --> 00:09:01.211
PRAMOOK KHUNGUM: Sorry,
I didn't make that clear.

00:09:01.211 --> 00:09:02.392
AUDIENCE: Sure, OK.

00:09:02.392 --> 00:09:03.600
PRAMOOK KHUNGUM: This is 128.

00:09:03.600 --> 00:09:07.540
So it's about 16 times faster.

00:09:07.540 --> 00:09:08.945
I couldn't wait for llike--

00:09:08.945 --> 00:09:09.290
AUDIENCE: Sure.

00:09:09.290 --> 00:09:10.206
PRAMOOK KHUNGUM: Yeah.

00:09:13.340 --> 00:09:16.690
So here are some
images I rendered.

00:09:16.690 --> 00:09:19.622
There are eight objects in here.

00:09:19.622 --> 00:09:23.690
And it took like 20.5
seconds with six SPUs.

00:09:26.200 --> 00:09:32.430
Another image that I rendered
is a miniature of a Cornell Box.

00:09:32.430 --> 00:09:38.225
It took 20.2 seconds
and six SPUs.

00:09:38.225 --> 00:09:40.920
AUDIENCE: Why is the
ceiling still so in black?

00:09:40.920 --> 00:09:42.928
PRAMOOK KHUNGUM: Yes, I
don't know that as well.

00:09:46.540 --> 00:09:51.290
Maybe it's about
the distribution

00:09:51.290 --> 00:09:55.320
of the particle light source.

00:09:55.320 --> 00:10:01.980
Probably I think when it goes
to the wall or to the floor,

00:10:01.980 --> 00:10:08.290
it gets severely attenuated
that it cannot really light

00:10:08.290 --> 00:10:10.810
the ceiling basically.

00:10:10.810 --> 00:10:16.100
So there's a comparison
between my rendering

00:10:16.100 --> 00:10:18.540
and the real Cornell Box.

00:10:18.540 --> 00:10:22.250
Basically, yes, there are still
a lot of [? boxes ?] around.

00:10:22.250 --> 00:10:24.540
Basically, the
ceiling is not lit.

00:10:24.540 --> 00:10:30.250
And it's kind of strange that
I see some gray tinges here

00:10:30.250 --> 00:10:33.460
instead of green as in this one.

00:10:33.460 --> 00:10:35.570
So probably, I have
to fix that as well.

00:10:35.570 --> 00:10:39.460
But as you can see, we have
achieved soft shadows and then

00:10:39.460 --> 00:10:40.974
some color bleeding.

00:10:40.974 --> 00:10:42.970
AUDIENCE: How do you
determine the location

00:10:42.970 --> 00:10:45.440
of the light sources?

00:10:45.440 --> 00:10:47.170
PRAMOOK KHUNGUM: How
do I determine the--

00:10:47.170 --> 00:10:47.961
AUDIENCE: Are you--

00:10:50.114 --> 00:10:51.613
PROFESSOR: Are you
giving this input

00:10:51.613 --> 00:10:53.790
to the algorithm, the
location of the light source?

00:10:53.790 --> 00:10:54.700
PRAMOOK KHUNGUM: Yes, basically.

00:10:54.700 --> 00:10:56.420
AUDIENCE: And they
can be arbitrary

00:10:56.420 --> 00:10:58.980
positions within the box or?

00:10:58.980 --> 00:11:01.690
PRAMOOK KHUNGUM: Yes, basically.

00:11:01.690 --> 00:11:04.830
This one is just
a square object,

00:11:04.830 --> 00:11:07.640
which is written in the
scene description file.

00:11:07.640 --> 00:11:12.760
And I can locate them
wherever I want basically.

00:11:12.760 --> 00:11:15.610
And the light particles
goes down from here.

00:11:23.800 --> 00:11:27.250
So there are some things that
can be further optimized.

00:11:27.250 --> 00:11:30.320
Basically, if I had decided
to use accelerated data

00:11:30.320 --> 00:11:36.980
structure, the complexity of
that in that size times objects

00:11:36.980 --> 00:11:41.290
times the number
of light sources,

00:11:41.290 --> 00:11:43.390
this term will be
reduced to [? log. ?]

00:11:43.390 --> 00:11:47.520
And probably, you
see about 3x speedup.

00:11:47.520 --> 00:11:49.804
AUDIENCE: Can you give an
example of an accelerated

00:11:49.804 --> 00:11:50.470
[? structure? ?]

00:11:50.470 --> 00:11:54.400
PRAMOOK KHUNGUM:
Basically, the most popular

00:11:54.400 --> 00:12:00.914
one is probably the--
what's it called?

00:12:00.914 --> 00:12:02.747
For example,
[? the KD tree, ?] for example.

00:12:02.747 --> 00:12:03.997
AUDIENCE: Oh, is it? [? OK. ?]

00:12:06.560 --> 00:12:09.790
PRAMOOK KHUNGUM: And
actually, I learned in class

00:12:09.790 --> 00:12:14.550
that basically, you can
achieve about 2x or 3x speedup

00:12:14.550 --> 00:12:21.310
by rearranging the data so that
you can trace four rays or 16

00:12:21.310 --> 00:12:24.360
rays at a time instead of doing
one at a time in the approach

00:12:24.360 --> 00:12:26.040
I'm taking.

00:12:26.040 --> 00:12:30.470
And if you do that, it's faster.

00:12:33.880 --> 00:12:38.850
In the program, I
have a lot of objects.

00:12:38.850 --> 00:12:41.390
And each of them has a
transform associated to them

00:12:41.390 --> 00:12:45.620
so that I can locate them
wherever I want and the object

00:12:45.620 --> 00:12:46.690
can be anything.

00:12:46.690 --> 00:12:48.940
But there's another
approach which

00:12:48.940 --> 00:12:55.580
says I just take anything to
be a collection of triangles.

00:12:55.580 --> 00:12:58.360
And if you have
triangles, the description

00:12:58.360 --> 00:13:00.450
is just three points
in space and you

00:13:00.450 --> 00:13:04.700
don't need transform to
do location or something

00:13:04.700 --> 00:13:05.380
like that.

00:13:05.380 --> 00:13:10.690
And basically, checking whether
a ray hits a triangle or not

00:13:10.690 --> 00:13:13.760
will be faster.

00:13:13.760 --> 00:13:16.443
So thank you very much.

00:13:16.443 --> 00:13:17.776
PROFESSOR: A few more questions?

00:13:21.046 --> 00:13:22.545
AUDIENCE: Do you
know that work that

00:13:22.545 --> 00:13:25.994
was done here by Julie
Dorsey in illumination?

00:13:25.994 --> 00:13:27.410
PRAMOOK KHUNGUM:
I have [? not. ?]

00:13:27.410 --> 00:13:31.150
AUDIENCE: She basically used
the trick of pre-computing,

00:13:31.150 --> 00:13:35.100
doing the ray tracing for
some fixed number of source

00:13:35.100 --> 00:13:39.990
locations and then just
rendering, in real time,

00:13:39.990 --> 00:13:46.110
by taking a linear superposition
of these ray-traced images.

00:13:46.110 --> 00:13:48.750
So long as you can
approximate your light source

00:13:48.750 --> 00:13:52.370
by a linear combination
of some fixed repertoire

00:13:52.370 --> 00:13:55.720
of light sources--
you didn't think

00:13:55.720 --> 00:13:59.904
about taking that
shortcut presumably.

00:13:59.904 --> 00:14:04.206
PRAMOOK KHUNGUM: I didn't think
about that shortcut basically.

00:14:04.206 --> 00:14:06.909
I [INAUDIBLE] know
something like that's--

00:14:06.909 --> 00:14:08.575
PROFESSOR: [INAUDIBLE]
few minutes left.

00:14:08.575 --> 00:14:10.440
AUDIENCE: Good.

00:14:10.440 --> 00:14:13.000
PRAMOOK KHUNGUM: Let's see.

00:14:13.000 --> 00:14:14.690
So [INAUDIBLE].

00:14:21.780 --> 00:14:24.071
AUDIENCE: So is it possible
to just connect it directly

00:14:24.071 --> 00:14:25.347
to a Playstation 3?

00:14:25.347 --> 00:14:26.930
PRAMOOK KHUNGUM: So
basically, there's

00:14:26.930 --> 00:14:30.730
this output.gga, which I'm
going to remove because I'm

00:14:30.730 --> 00:14:31.847
going to generate it.

00:14:31.847 --> 00:14:33.430
The scene I'm going
to render is going

00:14:33.430 --> 00:14:39.194
to be a Cornell Box with
a cube and a sphere in it.

00:14:39.194 --> 00:14:39.944
AUDIENCE: Pramook?

00:14:39.944 --> 00:14:40.819
PRAMOOK KHUNGUM: Yes?

00:14:40.819 --> 00:14:43.610
AUDIENCE: How easily could
you change the light sources?

00:14:43.610 --> 00:14:44.910
PRAMOOK KHUNGUM: I can
just move the object

00:14:44.910 --> 00:14:45.785
and the light source.

00:14:45.785 --> 00:14:48.250
AUDIENCE: OK, can you
do that [INAUDIBLE]?

00:14:48.250 --> 00:14:50.501
PRAMOOK KHUNGUM: Sure.

00:14:50.501 --> 00:14:52.250
Let's change it a point
light source then.

00:15:18.432 --> 00:15:20.480
[INAUDIBLE] relax.

00:15:20.480 --> 00:15:21.396
AUDIENCE: [INAUDIBLE].

00:15:26.319 --> 00:15:28.110
[? PROFESSOR: It just ?]
might be too slow.

00:15:28.110 --> 00:15:29.868
PRAMOOK KHUNGUM: I see.

00:15:29.868 --> 00:15:31.330
Here we go.

00:15:31.330 --> 00:15:34.730
So right now, the current
light source is this square.

00:15:34.730 --> 00:15:43.130
I'm going to comment it out and
change it to the point light

00:15:43.130 --> 00:15:43.962
source here.

00:15:47.898 --> 00:15:49.866
And then here we go.

00:15:55.759 --> 00:16:20.370
That's too quick, but--
basically, there's

00:16:20.370 --> 00:16:22.310
a point light source
located around here.

00:16:22.310 --> 00:16:25.050
So the scene is lit
with one point light.

00:16:25.050 --> 00:16:27.820
So as to expected,
the shadow is hard.

00:16:32.824 --> 00:16:33.990
AUDIENCE: One more question.

00:16:33.990 --> 00:16:34.430
PROFESSOR: One more question.

00:16:34.430 --> 00:16:35.550
PRAMOOK KHUNGUM: Sure.

00:16:35.550 --> 00:16:37.680
AUDIENCE: Just dividing
the scene equally

00:16:37.680 --> 00:16:39.360
seems like it give
good load balancing.

00:16:39.360 --> 00:16:41.764
If you had like roughly
equal complexity

00:16:41.764 --> 00:16:43.180
across different
sections-- if you

00:16:43.180 --> 00:16:46.920
have a really complex object
or if you have reflections that

00:16:46.920 --> 00:16:49.540
go much deeper in
some places in others,

00:16:49.540 --> 00:16:52.330
couldn't an equal division
lead to bad load balancing?

00:16:52.330 --> 00:16:54.486
Did you think about
other divisions?

00:16:54.486 --> 00:16:55.610
PRAMOOK KHUNGUM: I suppose.

00:16:55.610 --> 00:16:58.090
But basically, other
approach that I think of,

00:16:58.090 --> 00:17:02.880
which basically probably
you can divide the scene

00:17:02.880 --> 00:17:04.386
in a really fine-grain manner.

00:17:04.386 --> 00:17:06.511
AUDIENCE: Oh, you just do
like [? that striping. ?]

00:17:06.511 --> 00:17:07.386
PRAMOOK KHUNGUM: Yes.

00:17:07.386 --> 00:17:08.339
AUDIENCE: Yeah, OK.

00:17:08.339 --> 00:17:10.748
So is there a reason that
you chose [INAUDIBLE]?

00:17:10.748 --> 00:17:11.226
PROFESSOR SAMAN:
The communication

00:17:11.226 --> 00:17:13.616
how hard was it to get
this communication working?

00:17:13.616 --> 00:17:15.050
So what [? you've ?]
communicated,

00:17:15.050 --> 00:17:16.484
how often do you communicate?

00:17:19.352 --> 00:17:20.790
PROFESSOR: Repeat the question.

00:17:20.790 --> 00:17:25.170
PRAMOOK KHUNGUM:
Professor Saman asked

00:17:25.170 --> 00:17:29.030
how often does the SPU
communicate with one another,

00:17:29.030 --> 00:17:33.028
and the PPU, and how
often do I do that?

00:17:33.028 --> 00:17:34.510
PROFESSOR SAMAN: Yes.

00:17:34.510 --> 00:17:37.340
PRAMOOK KHUNGUM:
Basically, well,

00:17:37.340 --> 00:17:41.200
before the SPU starts
running, the PPU

00:17:41.200 --> 00:17:43.320
sends it the scene description.

00:17:43.320 --> 00:17:47.930
And then it sends it
the task that says,

00:17:47.930 --> 00:17:51.140
I want you to render
this pixel to this pixel.

00:17:51.140 --> 00:17:52.770
And that's it.

00:17:52.770 --> 00:17:58.090
And then the SPU just streams
the pixels to the main memory.

00:17:58.090 --> 00:18:00.970
PROFESSOR SAMAN: OK, so
you do a static balance,

00:18:00.970 --> 00:18:02.900
static distribution
of work [? around? ?]

00:18:02.900 --> 00:18:03.230
PRAMOOK KHUNGUM: Yes.

00:18:03.230 --> 00:18:04.475
PROFESSOR SAMAN: And
then when they're done,

00:18:04.475 --> 00:18:06.720
everybody sends it back,
and then you synchronize?

00:18:06.720 --> 00:18:07.600
PRAMOOK KHUNGUM: Yes.

00:18:07.600 --> 00:18:08.433
PROFESSOR SAMAN: OK.

00:18:08.433 --> 00:18:10.720
PRAMOOK KHUNGUM: Basically.

00:18:10.720 --> 00:18:12.520
PROFESSOR: OK, let's
thank the speaker.

00:18:12.520 --> 00:18:14.970
[APPLAUSE]