Permalink
Browse files

Merge branch 'master' of github.com:pxf/derp

  • Loading branch information...
2 parents 884aeaa + 02940bc commit 90d6de886ece3c7ae11c43c5ea6f2f99f51bae12 Jhonnyg committed May 10, 2011
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@@ -1,8 +1,16 @@
-\chapter{Previous work}
-There has been some development in JHONNYS STJÄRT
+\chapter{Previous Work}
+The field of distributed computing is a well developed field in computer
+science. One of the most well known systems is the Berkeley Open Infrastructure
+for Grid Network Computing (BOINC)\footnote{http://boinc.berkeley.edu/}.
+
+
+
\section{BOINC}
-%- BOINC - http://boinc.berkeley.edu/
+Initially developed by Berkeley for the SETI@home project, BOINC is now used in
+a wide range of projects, currently operating worldwide at 5,581.790
+TeraFLOPS\footnote{http://boincstats.com/stats/project\_graph.php?pr=bo
+fetched 2011-05-11}.
Differences with BOINC and the proposed project:
\begin{itemize}
@@ -11,6 +11,5 @@ \chapter{Description}
The second part of the project consists of a naïve ray tracer that can subdivide a scene into smaller jobs (for example screen regions / blocks), and then process them with little to none dependence on each other or the rest of the scene. Each job is automatically distributed over the network, and the results should be sent back to the job initiator as soon each job finishes.
-The general purpose of this project is to examine if distributed ray tracing calculations, over a P2P network, is able to reduce the render time of an arbitrarily complex 3D scene, compared to a regular local ray tracing solution.
+The general purpose of this project is to examine if distributed ray tracing calculations, over a P2P network, is able to reduce the render time of an arbitrarily complex 3D scene, compared to a regular local ray tracing solution. A secondary purpose is to briefly explore different ray tracing methods aimed specifically for distributed calculations. Implementing a new ray tracing application gives a deeper knowledge on ray tracing as a topic but also a greater freedom when incorporating it into the rest of the project, compared to existing ray tracing solutions.
-
@@ -8,26 +8,28 @@ \chapter{Results}
16x16 & 14 & 8-12s \\ \hline
32x32 & 14 & 1m 40s \\ \hline
\end{tabular}
- % caption?
+
+ \emph{Total render time} is the time it takes between the job initiator from sending the job to the network and having received all the resulting tasks.
\end{center}
-\emph{Total render time} is the time it takes between the job initiator from sending the job to the network and having received all the resulting tasks.
+\section{Discussion}
-We can clearly see that the rendering time is spread out and varies wildly. There are
-some known problems with our task distribution algorithm that can cause an uneven distribution
-of jobs across all nodes. For our test case, optimal distribution was achieved with a region of size 16x16, yielding a render time of only a couple of seconds.
+% -- cant see shit from that table :c
+%We can clearly see that the rendering time is spread out and varies wildly. There are
+%some known problems with our task distribution algorithm that can cause an uneven distribution
+%of jobs across all nodes. For our test case, optimal distribution was achieved with a region of size 16x16, yielding a render time of only a couple of seconds.
+
+% TODO: reword the part below when we have new test data
+%Increasing the region size to 32x32 quadruples the number of jobs, and shows how severe the performance hit is
+%when the distribution algorithm woes. Even if the number of jobs increases, the jobs finish not much later than before on the job processor side, but instead the bottleneck seems to be on the receiving end. This has to do with the massive increase of connections the receiving application has to open and handle, one for each result it will receive.
+
+The shading and ray tracing algorithms implemented are very simple in comparison to modern commercial solutions, and can not compete in either graphical results or speed at its current state. However, the Lightning prototype is still relevant and interesting for future developments in its field, as it tackles the problem in a new and potentially more efficient way. Currently the most relevant user groups for Lightning are hobby and 3D enthusiasts, instead of the current solutions which aim more on companies and commercial development. As hobbyists tend to have a lower budget than said companies, Lightning could become an affordable alternative. And bridge the gap in available processing power between the hobbyists and companies, as it would spread out the processing on large Lightning networks aimed just for hobbyists, by utilizing the idle processing power available by all the P2P connected hardware. Which in turn, with its combined power, could potentially compete with the commercial solutions in both quality and speed.
+
+\section{Conclusion}
+\pic[1.0]{img/conclusion.jpg}{this is not my fridge?}
-Increasing the region size to 32x32 quadruples the number of jobs, and shows how severe the performance hit is
-when the distribution algorithm woes. Even if the number of jobs increases, the jobs finish not much later than before on the job processor side, but instead the bottleneck seems to be on the receiving end. This has to do with the massive increase of connections the receiving application has to open and handle, one for each result it will receive.
-The shading and raytracing algorithms implemented are very simple in comparison to modern commercial solutions, and can not compete in either graphical results or speed at its current state. However, the Lightning prototype is still relevant and interesting for future developments in its field, as it tackles the problem in a new and potentially more efficient way. Currently the most relevant user groups for Lightning are hobby and 3D enthusiasts, instead of the current solutions which aim more on companies and commercial development. As hobbyists tend to have a lower budget than said companies, Lightning could become an affordable alternative. And bridge the gap in available processing power between the hobbyists and companies, as it would spread out the processing on large Lightning networks aimed just for hobbyists, by utilizing the idle processing power available by all the P2P connected hardware. Which in turn, with its combined power, could potentially compete with the commercial solutions in both quality and speed.
-% very simple shading and raytracing algorithms
-% not comparable to modern commercial solutions
-% gain still relevant
-% prototype
-% problems with task distribution, cause of "spread-out" results
-%
\chapter{Future Work}
\section{Ray tracing algorithm}

0 comments on commit 90d6de8

Please sign in to comment.