From fbe0691460fa28aaba07a2e89333521f95e1afdb Mon Sep 17 00:00:00 2001 From: josh Date: Thu, 16 Apr 2009 02:42:13 +0000 Subject: [PATCH] finishing up report git-svn-id: svn://anubis/gvsu@407 45c1a28c-8058-47b2-ae61-ca45b979098e --- cs658/html/report.html | 45 +++++++++++++++++++++++++++++++++++------- 1 file changed, 38 insertions(+), 7 deletions(-) diff --git a/cs658/html/report.html b/cs658/html/report.html index 22f0fac..be683a8 100644 --- a/cs658/html/report.html +++ b/cs658/html/report.html @@ -114,8 +114,8 @@

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 Node objects. Each Node 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 setsockopt() @@ -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.

Because OpenMP did not work to utilize every core on a worker @@ -208,6 +209,35 @@

Evaluation

+

+ 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. +

+

+ 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. +

Future Work

@@ -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 pthread_create() after - parsing the scene file and building the scene. + created more threads with pthread_create() after + parsing the scene file and building the scene, and then + used these threads to split up the work for a given task.