Difference between revisions of "User:Todor nikolov/proposal"

From BRL-CAD
m (...)
(almost done)
Line 24: Line 24:
  
 
=== Brief project summary ===  
 
=== Brief project summary ===  
:Analyze, profile, benchmark, speedup, report results. Do this a couple of times and a slow program becomes less slow. So that is my plan.
+
 
  
 
=== Detailed project summary ===
 
=== Detailed project summary ===
Line 33: Line 33:
  
 
:There are endless possibilities for the scope of the optimization, but the most promising are:
 
:There are endless possibilities for the scope of the optimization, but the most promising are:
*Bundling rays in groups to reuse static data
+
:*Bundling rays in groups to reuse static data
*Split raytracing routine to enable pipeilining and paralelisation
+
:*Split raytracing routine to enable pipelining and parallelization
*Locating pipeline hotspots and tighten their execution
+
:*Locating pipeline hotspots and tighten their execution
*Research algorithms used in said hotspots and try to find unnecessary computations
+
:*Research algorithms used in said hotspots and try to find unnecessary computations
 +
 
 +
:Basic principles that I will follow during this project:
 +
:*Steer based on intuition, Do based on numbers.
 +
:*10% increased code complexity defeats 10 times speedup
 +
:*Document before doing, report after doing
 +
 
 +
Deliverables:
 +
:* Graphical analysis and paper of the current state of the project with additional scripts meant for testing and benchmarking separate parts of the library
 +
:* Coding several optimization in the raytracer or object intersection functions
 +
:* or preparing the pipeline for the purposes of further optimization and possible porting to GPGPU
  
:Main
+
===  Why me ===
 +
I have deep and intuitive knowledge of current CPU-SIMD and GPU architecture, as well as their memory subsystems and their influence on code execution speed. I also know how to identify code structures that can be barriers to parallelization and speed even if they seem like improvements at the time.
  
:Current raytracing flow in BRLCAD is: Get scene> Get objects> Convert to internal representation > partition space >> shoot rays >> check for intersections > execute hit/miss function
+
=== Why you ===
 +
You have a complex and promising software that gives me a chance to learn more about graphics, and programming than anything I have encountered before. Also you have a good documentation and structure I feel will help me fit it fast.

Revision as of 21:10, 16 March 2014

Personal Information


Name: Todor Nikolov
Email: tosemkd@gmail.com
IRC name:todor_nikolov

About Me

I am a student in my 3-rd year in computer science and engineering, at the faculty of Computer Science and Engineering in Skopje, Macedonia.
The focus of my studies is parallel programming and high performance computing, also I have a fondness for embedded systems and low power computing.
Along side this I also take classes in computer graphics and animation, partly because it is connected to the previous fields, but mostly because it is fun and quite challenging.
My hobbies include gaming and learning new ways to torture all the processors in my PC. :D

Previous Experience

  • 2 months working on a social network as part of an internship, february-march 2013 , in this project I used php with the codeigniter framework, my tasks were implementing the messaging system and configuring sphinxsearch to match the requirements of the design.
  • A small project in android as part of a teamwork class, its still work in progress.

Project Proposal


Project Title

Raytracing pipeline optimization

Brief project summary

Detailed project summary

The raytracer in brlcad hits around 1M rays/sec meaning a render on a current screen (1920x1080) takes 1 - 15 seconds. The new archer editor supports much quicker edits, meaning having a quicker response by the renderer will improve the feel and workflow of the application.
The other use of the raytracer is queuing multiple traces in a script file for the purpose of either animation or multi-view rendering can take minutes to hours depending on the complexity of the scene and the amount of frames taken.
There are endless possibilities for the scope of the optimization, but the most promising are:
  • Bundling rays in groups to reuse static data
  • Split raytracing routine to enable pipelining and parallelization
  • Locating pipeline hotspots and tighten their execution
  • Research algorithms used in said hotspots and try to find unnecessary computations
Basic principles that I will follow during this project:
  • Steer based on intuition, Do based on numbers.
  • 10% increased code complexity defeats 10 times speedup
  • Document before doing, report after doing

Deliverables:

  • Graphical analysis and paper of the current state of the project with additional scripts meant for testing and benchmarking separate parts of the library
  • Coding several optimization in the raytracer or object intersection functions
  • or preparing the pipeline for the purposes of further optimization and possible porting to GPGPU

Why me

I have deep and intuitive knowledge of current CPU-SIMD and GPU architecture, as well as their memory subsystems and their influence on code execution speed. I also know how to identify code structures that can be barriers to parallelization and speed even if they seem like improvements at the time.

Why you

You have a complex and promising software that gives me a chance to learn more about graphics, and programming than anything I have encountered before. Also you have a good documentation and structure I feel will help me fit it fast.