finishing up report
git-svn-id: svn://anubis/gvsu@407 45c1a28c-8058-47b2-ae61-ca45b979098e
This commit is contained in:
parent
f8b570e06b
commit
fbe0691460
@ -114,8 +114,8 @@
|
|||||||
<p>
|
<p>
|
||||||
To create a scalable parser to read scene files according to
|
To create a scalable parser to read scene files according to
|
||||||
a grammar that I supplied, I used the bison parser generator.
|
a grammar that I supplied, I used the bison parser generator.
|
||||||
I chose bison because it is very portable and worked directly
|
I chose bison because it is very portable and has a C++
|
||||||
with my C++ code.
|
interface so I could interface it with the rest of my code.
|
||||||
The parser produces a hierarchy of <tt>Node</tt> objects.
|
The parser produces a hierarchy of <tt>Node</tt> objects.
|
||||||
Each <tt>Node</tt> object represents some part of the parse tree
|
Each <tt>Node</tt> object represents some part of the parse tree
|
||||||
obtained from the scene description file.
|
obtained from the scene description file.
|
||||||
@ -164,7 +164,8 @@
|
|||||||
I ran "netstat -taunp" and saw that the TCP connections had
|
I ran "netstat -taunp" and saw that the TCP connections had
|
||||||
data in their send queues.
|
data in their send queues.
|
||||||
This meant that the program had already processed what it was
|
This meant that the program had already processed what it was
|
||||||
asked to process and was simply waiting for the network.
|
asked to process and was simply waiting for the network traffic
|
||||||
|
to be processed.
|
||||||
I realized that the TCP implementation was waiting to accumulate
|
I realized that the TCP implementation was waiting to accumulate
|
||||||
data before sending it over the TCP connection.
|
data before sending it over the TCP connection.
|
||||||
In order to deal with this, I used the <tt>setsockopt()</tt>
|
In order to deal with this, I used the <tt>setsockopt()</tt>
|
||||||
@ -188,7 +189,7 @@
|
|||||||
I believe this did not work well because I was manually creating
|
I believe this did not work well because I was manually creating
|
||||||
and managing threads with the pthread system in addition to
|
and managing threads with the pthread system in addition to
|
||||||
trying to use OpenMP, which was probably implemented by the
|
trying to use OpenMP, which was probably implemented by the
|
||||||
compiler using pthreads.
|
compiler using pthreads as well.
|
||||||
</p>
|
</p>
|
||||||
<p>
|
<p>
|
||||||
Because OpenMP did not work to utilize every core on a worker
|
Because OpenMP did not work to utilize every core on a worker
|
||||||
@ -208,6 +209,35 @@
|
|||||||
|
|
||||||
<a name="evaluation" />
|
<a name="evaluation" />
|
||||||
<h4>Evaluation</h4>
|
<h4>Evaluation</h4>
|
||||||
|
<p>
|
||||||
|
I designed the raytracer itself in the first half of the semester
|
||||||
|
and got it working well using a sequential approach.
|
||||||
|
In the second half of the semester I added the task distribution
|
||||||
|
infrastructure which allowed the raytracer to break up the
|
||||||
|
work of rendering an entire scene into tasks of a small size.
|
||||||
|
These tasks were then dispersed among slave processes which
|
||||||
|
were launched using the distribution infrastructure.
|
||||||
|
One slave process was created for every processor on each host
|
||||||
|
involved in the render.
|
||||||
|
I tested this design in the Grand Valley EOS computer lab.
|
||||||
|
A serial render of a given scene on eos01 took 38 minutes.
|
||||||
|
When I rendered it using the distribution infrastructure on
|
||||||
|
all 24 nodes (64 cores), it took about 38 seconds.
|
||||||
|
This is a speedup of about 60 times.
|
||||||
|
</p>
|
||||||
|
<p>
|
||||||
|
I was able to implement my program very closely with my original
|
||||||
|
design.
|
||||||
|
There are some features related to the raytracer (not the
|
||||||
|
distribution part of it) that I was not able to implement, but
|
||||||
|
that I am planning to add at a later time.
|
||||||
|
Such features include other Light types such as a directional light,
|
||||||
|
a jitter parameter to lights that can be used to render soft shadows,
|
||||||
|
a scene pre-parser that would allow shape definitions and looping
|
||||||
|
with variables to create patterns of objects,
|
||||||
|
texture support on the surfaces of objects,
|
||||||
|
and light refraction through semi-transparent objects.
|
||||||
|
</p>
|
||||||
|
|
||||||
<a name="futurework" />
|
<a name="futurework" />
|
||||||
<h4>Future Work</h4>
|
<h4>Future Work</h4>
|
||||||
@ -218,10 +248,11 @@
|
|||||||
of processors detected
|
of processors detected
|
||||||
on the slave node.
|
on the slave node.
|
||||||
This has the disadvantage that the scene-file is parsed and
|
This has the disadvantage that the scene-file is parsed and
|
||||||
initialization is redone for each of these processes.
|
initialization is repeated for each of these processes.
|
||||||
This time could be saved by an implementation that instead
|
This time could be saved by an implementation that instead
|
||||||
created another thread with <tt>pthread_create()</tt> after
|
created more threads with <tt>pthread_create()</tt> after
|
||||||
parsing the scene file and building the scene.
|
parsing the scene file and building the scene, and then
|
||||||
|
used these threads to split up the work for a given task.
|
||||||
</p>
|
</p>
|
||||||
|
|
||||||
</body>
|
</body>
|
||||||
|
Loading…
x
Reference in New Issue
Block a user