Editing User:Michaljagielski/proposal

From BRL-CAD

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 13: Line 13:
  
 
==Brief Background==
 
==Brief Background==
I'm second year student in Computer Science from University of Wroclaw. What's about my knowledge... I know Linux and other UNIX-like systems quite good. Mainly I write in C/C++ but I also like functional languages (Haskell, OCaml). Lately I'm interested primarily in GPGPU and I have some experience with it ( for example, I'm writing Rubik Cube optimal solver on CUDA). I preferred CUDA but I had also some practice with OpenCL.
+
I'm second year student in Computer Science from University of Wroclaw. What's about my knowledge... I know Linux and other UNIX-like systems quite good. Mainly I write in C/C+ but I also like functional languages (Haskell, OCaml). Lately I'm interested primarily in GPGPU and I have some experience with it ( for example, I'm writing Rubik Cube optimal solver on CUDA). I preferred CUDA but I had also some practice with OpenCL.
  
 
=Project Information=
 
=Project Information=
Line 19: Line 19:
 
OpenCL GPGPU Raytracing
 
OpenCL GPGPU Raytracing
 
==Brief summary of Project==
 
==Brief summary of Project==
BRL-CAD objects are made from about two dozens of primitives. During work they are displayed usually as wireframes, but from time to time we want to get better image (more reallistic, bigger etc.) Raytracing for most of primitives is implemented only on CPU. GPU is definetely better for this task, because of parallel nature of this problem (there is a lot of rays shooted from camera). Shooted rays are checked to intersect with primitives from project. There is a lot of calls functions which check if a ray is intersecting with primitive and on witch direction it should be reflected. If there is a lot of same function calls with a little different input data, it's best place to use GPGPU, whitch offer great performance increase in this type of computations.
+
BRL-CAD objects are made from about two dozens of primitives. During work they are displayed only as some kind of net but there is moment, when we want get more precise and more realistic view of our project. Raytracing for most of primitives is implemented only on CPU. GPU is definetely better for this task, so in my project I will rewrite C code of raytracer to OpenCL. Also when GPU is not accessible on computer OpenCL will speed up raytracing, because it can be launched on multi-core CPU.
 
 
When GPU is not accessible on computer OpenCL also will be fast, because it can be launched on multi-core CPU.
 
  
 
==Project Description (Detailed)==
 
==Project Description (Detailed)==
 
===Primitives===
 
===Primitives===
Some of primitives have easy to compute intersection function, but some of them cam be really weird - for example bended pipe. I will start generally from easiest to implement primitives. Some of primitives is rarely used so I postpone implementing it. In my 12-week plan I also not mentioned 2d-derived primitives, because I can't risk that I won't finish my task on time. If I will manage to implement all of inscribed primitives before deadline I will start implementing also 2d-derived primitives, but if not - I will implement it after GSoC.
+
I divided large primitives set in five categories. Some of them in one group can be very similar (for example ellipsoids), but there is also a lot of individual shapes (dsp, ars). I will divide whole task on subtasks in respect of shapes similarity.
  
===Something about files===
+
===Actual state of raytracing===
In BRL-CAD each primitive have their own raytracing function.  There exist only one example of OpenCL raytracer in special OpenCL branch of BRL-CAD - sph primitive raytracing is written in OpenCL. It will be my starting point. So on first place I will write raytracer for all ell. Because CL-related functions will be used in every primitive, I will also use separate file with functions like device finding, kernel loading, parameters setting etc.
+
In BRL-CAD each primitive have their own raytracing function.  There exist only one example of OpenCL raytracer - in ellipsoids sph primitive raytracing is written in OpenCL. It will be my starting point (and it's great lesson of BRL-CAD coding style). So on first place I will write raytracer to ell (and next ellg, ell1, part), because it's more similar to sph than other primitive. Next category will be cylinders-like and cones-like primitives. Next will be torus-like (with one hole), polyhedra and last, most challenging in my opinion some of unique shapes.
  
 
I will work on branch available in http://svn.code.sf.net/p/brlcad/code/brlcad/branches/opencl/ there also is sph raytrace example: http://svn.code.sf.net/p/brlcad/code/brlcad/branches/opencl/src/librt/primitives/sph/ . After I complete a project every primitive should have file structure as sph.
 
I will work on branch available in http://svn.code.sf.net/p/brlcad/code/brlcad/branches/opencl/ there also is sph raytrace example: http://svn.code.sf.net/p/brlcad/code/brlcad/branches/opencl/src/librt/primitives/sph/ . After I complete a project every primitive should have file structure as sph.
  
===Algorithm===
+
===Algorithm===I think that there is no too much to talk about algorithm, I will try generally rewrite C algorithms in more efficient OpenCL algorithm. Algorithm for every primitive is described with desired amout of details in name_of_primitive.c almost on beginning. I think it's unnecessary to paste it here.
I think that there is no too much to talk about algorithm, I will try generally rewrite C algorithms in more efficient OpenCL algorithm. Algorithm for every primitive is described with desired amount of details in name_of_primitive.c almost on beginning. I think it's unnecessary to paste it here. Only thing that should be said is that in isolated GPU environment it may be not possible or simple not recommended to call other functions so I will try to oust this calls. What is more GPU kernels should be light, what may imply some next changes. It's not necessary, but it may have great impact on performance of raytracing.
 
  
===Computing device===
+
===Computing device===When all primitives have OpenCL raytracing during program execution I can check if GPU device is accessible and if not, lauch raytracer kernel on CPU.  
As I said OpenCL can also be launched on CPU so of course I will check if GPU device is accessible and if not, launch raytracer kernel on CPU. This task will be realized as I mentioned in files common to all primitives.
+
 
 +
===Documentation===
 +
As I realized in BRL-CAD is used doxygen system, so of course I will also document my work in this program.
  
 
===Deliverables===
 
===Deliverables===
Great speedup of scenes raytracing in BRL-CAD. For this moment it's not too fast (despite of using all threads).
+
Great speedup of scenes raytracing in BRL-CAD. For this moment it's very slow (I have quite fast computer but even for relatively simple scenes raytracing takes about second.)
 +
 
  
 
==Working Schedule==
 
==Working Schedule==
Line 47: Line 47:
 
*Fixing at least 1-2 bugs to get familiar with devlopment system.
 
*Fixing at least 1-2 bugs to get familiar with devlopment system.
 
*Deeper understanding of BRL-CAD usage (for example completing user tutorial)
 
*Deeper understanding of BRL-CAD usage (for example completing user tutorial)
*Preparing set of function used to kernel launching. I suppose, that should be new file with:
+
*First attemps of ell primitive OpenCL raytracing. I will get it done before main work start.
**CL device selecting
+
**Kernel reading and loading to memory
+
===May 19 - August 4  (Development)===
**context managment
+
====May 19 - June 2 [~2 Week] ====
 +
*Write raytracers to every primitive from ellipsoids group.
 +
*Test and benchmark these raytracers. Measure diffrence between CPU and GPU implementation.
 +
====June 2 - June 23 [~3 Week]====
 +
*Implementation cylinders and cones raytracing. I plan three weeks because it's 9 primitives.
 +
*Writing simple program/script to generating more challenging projects.
 +
====June 23 - July 7 [~2 Week]====
 +
*Raytracers for torus, ring and pipe should be done
 +
====July 7 - July 21 [~2 Week]====
 +
*Polyhedra raytracing in OpenCL. It contains a lot of primitives, but they are wery similar to each other.
 +
====July 21 - August 4 [~2 Week]====
 +
*Attempt to rest of primitives if I won't complete raytracer for any primitive I will end it after August 18 (but of course I will do my best to finish all raytracers befor August 4)
  
===May 19 - August 4 (Development)===
+
=== August 4 - August 18 === (Finalising)
# week - rt_ell_shot OpenCL kernel. Of course I will have library to handle OpenCL calls so it should be useful in same week.
 
# week - rhc and rpc ray shooting kernels.
 
# week - start of rt_tgc_shoot kernel (and 4 other primitives, that are special cases of tgc: rcc, rec,tec,trc). This primitive could be hard to implement (for example it contains some external functions)  so I think I should reserve more time to it. First of all I will implement external functions, then rest of algorithm.
 
# week - finishing rt_tgc_shoot.
 
# week - ehy and epa primitives (It should be relatively easy to write). In this week I will have final exams, so I must have a little more time.
 
# week - Raytracing of torus of two kinds: tor and eto primitive. I should also start arbn raytracing - it seems to be easy.
 
# week - finishing arbn and start of bot raytracing.
 
# week - Starting first of more complicated raytracing: part primitive. It's more complicated than earlier - for example it uses lists (implementation of lists on GPU is non-trivial problem).
 
# week - I will finish particle raytracing. As I said earlier, raytracing algorithm of part is much longer than others, but I'm hoping that I will end before end of week and I will start most complicated to raytracing primitive - pipe.
 
# week - Pipe raytracing - it should be most difficult in my project, because pipe have really complicated structure and lot of auxiliary functions. I Think I will end it in this week or on first few days of next week.
 
=== August 4 - August 18 (Finalising) ===
 
 
*During these two weeks I will test once more raytracers and benchmark it on some real examples.
 
*During these two weeks I will test once more raytracers and benchmark it on some real examples.
*Final code submission with Google.
+
*Final code submission with Google.
  
 
==Time Availability==
 
==Time Availability==
 
*During summer holidays (after about 21st June) I will be completly free
 
*During summer holidays (after about 21st June) I will be completly free
*Usually I will spend 40-45 hours/week on coding. In first month it *may* be little less (but over 32 hours). I can devote up to 60 hrs/week in special cases.
+
*I can devote up to 60 hrs/week. I can working in every time of day (or night)
*In 16th June - 19th June I have some final exams. Probably I will have little less time in this week, but I will make up for this time.
+
*In 16th June - 21st June I have final exams. It's possible that I have a little less time in this term, but I will make up for this time.
*Before 16th June I have university courses, but I specially take only three in this semester to participate in GSoC.
+
*Befor 16th June I have university courses, but I specially take only three in this semester to participate in GSoC
  
 
==Why BRL-CAD?==
 
==Why BRL-CAD?==
As I wrote before I like GPGPU and you need somebody to speedup some part of your program. What is more, I know how expensive can be CAD software and I think that this initiative (BRL-CAD) is really important - I'm definetely votary of Open Source. After I worked with mged and archer few times I've got a certainty that it's great program and I will help to develop it.
+
As I wrote before I like GPGPU and you need somebody to speedup some part of your program. What is more, I know how expensive can be CAD software and I think that this initiative (BRL-CAD) is really important.  
 
 
 
==Why you?==
 
==Why you?==
I'm good in C/C++ coding and GPU programming. Also I think that I have a quite good understanding of GPU architecture, what may be useful in rewriting algorithms. In addition to that I'm really hard working and stubborn when I want to reach some target. I think this project is quite mached to my skills and interest so BRL-CAD can be noticeable beter thanks to mine work.  
+
I'm good in C/C++ coding and GPU programming. What is more I'm really hard working and stubborn when I want to reach some target. I think This project is quite mached to my skills and interest so BRL-CAD can be noticeable beter thanks to mine work.  
Furthermore I always want to participate in any open source community so I will stay with you after GSoC ends.
+
What is more I always want to participate in any open source community so I will stay with you after GSoC ends.
=Patch=
 
Already I've written only one patch, about RHC volume calculating and integrating it with mged "analyze" command. Patch is aviable here:
 
http://sourceforge.net/p/brlcad/patches/266
 
I'm planning next patch to be related to OpenCL branch.
 

Please note that all contributions to BRL-CAD may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see BRL-CAD:Copyrights for details). Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel Editing help (opens in new window)