josh/gvsu
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

finishing up report

Browse Source 
git-svn-id: svn://anubis/gvsu@407 45c1a28c-8058-47b2-ae61-ca45b979098e
This commit is contained in:
josh 2009-04-16 02:42:13 +00:00
parent f8b570e06b
commit fbe0691460
1 changed files with 38 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
cs658/html/report.html
View File

@ -114,8 +114,8 @@
<p>
To create a scalable parser to read scene files according to
a grammar that I supplied, I used the bison parser generator.
I chose bison because it is very portable and worked directly
with my C++ code.
I chose bison because it is very portable and has a C++
interface so I could interface it with the rest of my code.
The parser produces a hierarchy of <tt>Node</tt> objects.
Each <tt>Node</tt> object represents some part of the parse tree
obtained from the scene description file.
@ -164,7 +164,8 @@
I ran "netstat -taunp" and saw that the TCP connections had
data in their send queues.
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
data before sending it over the TCP connection.
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
and managing threads with the pthread system in addition to
trying to use OpenMP, which was probably implemented by the
compiler using pthreads.
compiler using pthreads as well.
</p>
<p>
Because OpenMP did not work to utilize every core on a worker
@ -208,6 +209,35 @@
<a name="evaluation" />
<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" />
<h4>Future Work</h4>
@ -218,10 +248,11 @@
of processors detected
on the slave node.
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
created another thread with <tt>pthread_create()</tt> after
parsing the scene file and building the scene.
created more threads with <tt>pthread_create()</tt> after
parsing the scene file and building the scene, and then
used these threads to split up the work for a given task.
</p>
</body>