Platform independent parallelization without changing the framework?

I hope the title did not mislead you.

My problem is the following: Currently I try to speed up a raytracer and this is done with the help of the graphics card. It works fine despite the fact that it got slower by this. :)

This is caused by the fact, that I trace one ray on the whole geometry at once on the graphics card(my "tracing server") and then fetch the results, which is awfully slow, so I have to gather some rays and calc them and fetch the results together to speed this up.

The next problem is, that I am not allowed to rewrite the surrounding framework that should know nothing or least possible about this parallelization.

So here is my approach: I thought about using several threads, where each one gets a ray and requests my "tracing server" to calc the intersections. Then the thread is stopped until enough rays were gathered to calc the intersections on the graphics card and get the results back efficiently. This means that each thread will wait until the results were fetched.

You see I already have some plan but following I do not know:

• Which 开发者_运维技巧threading framework should I take to be platformindependent?
• Should I use a threadpool of fixed size or create them as needed?
• Can any given thread library handle at least 1000 waiting threads(because that would be the number that I need to gather for my fetch to be efficient)?

But I also could imagine doing this with one thread that

1. dumps its load (a new ray) to the "tracing server" and fetches the next load until
2. there is enough to fetch the results.
3. Then the thread would take the results one by one, do the further calculations until all results are processed and then goes back to step one until all rays are done.

Also if you have some better idea how to parallelize this, tell me about it.

Regards,

Nobody

PS If you need this information: The two platforms I want to use are Linux and Windows.

use either Thread Building Blocks or boost::thread.

http://www.boost.org/doc/libs/1_46_0/doc/html/thread.html

http://threadingbuildingblocks.org/

As far as threadpool/on-demand-threads - threadpool is generally better idea as it avoids creation overhead.

Number of waiting threads is gonna depend on the underlying system more than anything else:

Maximum number of threads per process in Linux?