Is parallelization worth it?
Author Message
g0moshb Offline
Wearer of the almighty neckbeard


Reputation: 0
Post: #11
RE: Is parallelization worth it?
It's too late to be useful, but I used pthread's thread-local-storage functions, specifically pthread_key_* and pthread_{get|set}specific, combined with a simple modification to the transform matrices.
2013-12-17 07:50
Visit this user's website Find all posts by this user Quote this message in a reply
g1snkz Offline
Student


Reputation: 0
Post: #12
RE: Is parallelization worth it?
(2013-12-17 07:50)g0moshb Wrote:  It's too late to be useful, but I used pthread's thread-local-storage functions, specifically pthread_key_* and pthread_{get|set}specific, combined with a simple modification to the transform matrices.

why did you end up modifiying the transform matricies? how much did you alter the render function?
2013-12-17 11:41
Find all posts by this user Quote this message in a reply
g0moshb Offline
Wearer of the almighty neckbeard


Reputation: 0
Post: #13
RE: Is parallelization worth it?
(2013-12-17 11:41)g1snkz Wrote:  
(2013-12-17 07:50)g0moshb Wrote:  It's too late to be useful, but I used pthread's thread-local-storage functions, specifically pthread_key_* and pthread_{get|set}specific, combined with a simple modification to the transform matrices.

why did you end up modifiying the transform matricies? how much did you alter the render function?

I parallelized them by converting Raytracer::_modelToWorld from `Matrix4x4' to 'Matrix4x4& ()`. The internals of it is that _modelToWorld calls Raytracer._tls->get()->modelToWorld and returns a reference to that. Raytracer::Thread_local takes care of the pthread-specific TLS parts. Otherwise, race conditions ensue when transformations start to stack up.

Converting _modelToWorld to _modelToWorld() was a vim one-liner Smile

If anything, I rejiggered Raytracer::render(...) to spawn workers and generate time counters.

'_tls->' because PIMPL so I don't have to muck with Raytracer.h if I want to tweak the threading-related code.
(This post was last modified: 2013-12-17 15:32 by g0moshb.)
2013-12-17 15:25
Visit this user's website Find all posts by this user Quote this message in a reply
g1snkz Offline
Student


Reputation: 0
Post: #14
RE: Is parallelization worth it?
(2013-12-17 15:25)g0moshb Wrote:  
(2013-12-17 11:41)g1snkz Wrote:  
(2013-12-17 07:50)g0moshb Wrote:  It's too late to be useful, but I used pthread's thread-local-storage functions, specifically pthread_key_* and pthread_{get|set}specific, combined with a simple modification to the transform matrices.

why did you end up modifiying the transform matricies? how much did you alter the render function?

I parallelized them by converting Raytracer::_modelToWorld from `Matrix4x4' to 'Matrix4x4& ()`. The internals of it is that _modelToWorld calls Raytracer._tls->get()->modelToWorld and returns a reference to that. Raytracer::Thread_local takes care of the pthread-specific TLS parts. Otherwise, race conditions ensue when transformations start to stack up.

Converting _modelToWorld to _modelToWorld() was a vim one-liner Smile

If anything, I rejiggered Raytracer::render(...) to spawn workers and generate time counters.

'_tls->' because PIMPL so I don't have to muck with Raytracer.h if I want to tweak the threading-related code.

Thanks for clarifying!
2013-12-19 19:42
Find all posts by this user Quote this message in a reply
g0moshb Offline
Wearer of the almighty neckbeard


Reputation: 0
Post: #15
RE: Is parallelization worth it?
(2013-12-19 19:42)g1snkz Wrote:  
(2013-12-17 15:25)g0moshb Wrote:  
(2013-12-17 11:41)g1snkz Wrote:  
(2013-12-17 07:50)g0moshb Wrote:  It's too late to be useful, but I used pthread's thread-local-storage functions, specifically pthread_key_* and pthread_{get|set}specific, combined with a simple modification to the transform matrices.

why did you end up modifiying the transform matricies? how much did you alter the render function?

I parallelized them by converting Raytracer::_modelToWorld from `Matrix4x4' to 'Matrix4x4& ()`. The internals of it is that _modelToWorld calls Raytracer._tls->get()->modelToWorld and returns a reference to that. Raytracer::Thread_local takes care of the pthread-specific TLS parts. Otherwise, race conditions ensue when transformations start to stack up.

Converting _modelToWorld to _modelToWorld() was a vim one-liner Smile

If anything, I rejiggered Raytracer::render(...) to spawn workers and generate time counters.

'_tls->' because PIMPL so I don't have to muck with Raytracer.h if I want to tweak the threading-related code.

Thanks for clarifying!

I'm planning on adding a basic parser to it so I can separate the tracer from the scene setup so I don't have to recompile when playing with geometry. I might release it as a new github repo eventually, after a bit of further refactoring, since it's definitely more advanced (and fast! (40 minutes for 2 renderings at --width 1600 --height 1200 --threads 4 --depth 5 --antialias 5 --gloss 5)) than my submission for A3. `gcc-4.8 -O3 -ffast-math -march=native` works well, though adding __attribute__((align(16))) to the arrays helps quite a bit. C++11 has aligned-storage specifiers, so use that if you want inter-compiler portability.
2013-12-20 00:02
Visit this user's website Find all posts by this user Quote this message in a reply
Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5


Forum Jump:


User(s) browsing this thread: 1 Guest(s)