Parallel API

[Carbonflux]

Whereas the bloom calculation is single-threaded in current mainline code, and thus sees a massive performance boost when TBB is used to multi-thread it.

This is a good point. Also, adding a second threading api is normally a bad practice, there could be unforeseen conflicts. Just in terms of good software engineering there should be one sub-system for this which we have relied on boost to provide the abstraction for. Maybe its been a mistake to use boost raw. Also this idea of "hand tuning" could just as well be defined as the natural adaption process of a api, when switching to a new api it can seem simple at first and easier to use without "hand tuning" but after a few debugging freeback cycles it can end up in the same place or with a better system but its harder than many think to predict this. It is important to evaluate this carefully.

[guibou]

Whereas the bloom calculation is single-threaded in current mainline code, and thus sees a massive performance boost when TBB is used to multi-thread it.

This is a good point. Also, adding a second threading api is normally a bad practice, there could be unforeseen conflicts. Just in terms of good software engineering there should be one sub-system for this which we have relied on boost to provide the abstraction for. Maybe its been a mistake to use boost raw. Also this idea of "hand tuning" could just as well be defined as the natural adaption process of a api, when switching to a new api it can seem simple at first and easier to use without "hand tuning" but after a few debugging freeback cycles it can end up in the same place or with a better system but its harder than many think to predict this. It is important to evaluate this carefully.

I wanted to discuss a bit this issue now that 1.0 has been released and that we can play a bit.

I really want something as TBB inside lux, mainly because it may improve code quality and improve cpu usage and thread scheduling. I choose TBB mainly because it is GPL, it is known to work well on many plateform (Linux, Mac OS, Windows) and many compilers.

Why not another API ? jens did a test on GCD and I'm not convinced at all. Performances seems to be roughly the same. Tbb is well deployed and easy to install on every target plateform we have when in the other hand for GCD you need clang, you need a custom code compiled from svn and it tooks me half a day te be able to run my first example.

In the next commits, TBB will be used as a second thread api, but I hope to replace our main threading api soon by TBB and I hope this will gives us something cleaner.

So what or we going with this ? should I close the TBB branch and merge stuff, or close it and not merging stuff ?

[jeanphi]

Hi,

That will be a new external dependency for Lux, but it looks to be worth a try. Can you continue to update the tbb branch and we'll merge when it's ready. That way we'll be sure to not miss a special case that tbb wouldn't be able to handle (you never know).

Jeanphi

[jeanphi]

Hi,

I just saw that Jens has just commited a GCD patch. Could we please try to have a uniform solution across all platforms and not a triple size source code with defines for TBB, GCD, nothing, what else, ...
Actually I'd much prefer to have no improved threading API that special cases scattered everywhere as it will soon become a maintenance nightmare. We're not that many developers and maintainability is a key factor for the long term, much more than speed.

Jeanphi

[guibou]

That will be a new external dependency for Lux, but it looks to be worth a try. Can you continue to update the tbb branch and we'll merge when it's ready. That way we'll be sure to not miss a special case that tbb wouldn't be able to handle (you never know).

Hello.

I did some work on the tbb branch to match the state of the default branch, mainly:

# the samplertbbrenderer
- now integrate all changes done in the samplerrendere since previous merge
- has thread number limitation and pause (Yes !)
- has a more cleaner code than the samplerrendere now (In my opinion) and small hacks may disapears if TBB become the main solution
# film
- I synchronized with the work of jens and Vignetting is now TBB too.

Ok, for now:

a) please run the TBB branch, I'm interesting about:

- compilation issues on different plateform (other than linux)
- a better cmake integration, I don't understand anything about cmake, so my work is a hack
- performance of the tbbsamplerrender. For me it is something as 1% slower than the normal renderer, and stuff can be improved I think.

b) Still one open issue, the number of thread looks like a hack and must be, if we stick with TBB, become something of the whole lux and not of the renderer

Some stuff are still hackish inside the TBB implementation, but I'm pretty satisfied of its state now. Now we'll have to discuss.

I just saw that Jens has just commited a GCD patch. Could we please try to have a uniform solution across all platforms and not a triple size source code with defines for TBB, GCD, nothing, what else, ...
Actually I'd much prefer to have no improved threading API that special cases scattered everywhere as it will soon become a maintenance nightmare. We're not that many developers and maintainability is a key factor for the long term, much more than speed.

I think that GCD work may go on a separate branch if needed. In the other hand I'm not fan of GCD for the reasons I previously exposed.

[jeanphi]

Hi,

Just to make things clear, I don't care about the framework as long as it is cross platform for at least Windows/MacOS/Linux and as the interfaces are complete and clean. So it can be TBB, GCD, OpenMP, OpenCL,your own, whatever, I really don't care.

Jeanphi

[guibou]

Just to make things clear, I don't care about the framework as long as it is cross platform for at least Windows/MacOS/Linux and as the interfaces are complete and clean. So it can be TBB, GCD, OpenMP, OpenCL,your own, whatever, I really don't care.

Me too I tried openmp and was not convinced because of portability and feature, I tried GCD and was not convinced because of portability and future of the project, opencl or other stuff fit different purposes. TBB appears complete, well maintained (and they don't break compatibility each day like boost), easy to install, portable and GPL.

Sorry if this topic has bothered you.

[guibou]

I updated a bit the TBB branch (mainly to merge changes from defaut branch).

Some changes, the code is a bit cleaner, with less *hack*. I introduced two new arguments to the renderer:

- chunksize: number of ray processed before a pause/thread add/remove event will be handled
- latency: if different from 0, chunksize will automatically adjust itself to a value which ensure that the pause event will be handled in less than *latency* second.

In summary, if chunksize or latency is big, the threading overhead is null, but pause may have to wait a few seconds, in the other hand, you may get realtime pause/thread handling, but at the cost of a few scheduling overhead.

Please note that on my computer the TBB renderer runs at the same performances than the normal sampler renderer. You can see a difference at launch because TBB must wait the end of a chunk before adding a thread, but once you are running with full thread, it works at the same speed. Please note that this issue can be easilly handled if the renderer starts by knowing the number of rendering thread instead of getting noticed after its start to add thread (in my opinion, the current api sucks in this respect...)Code is (in my opinion) cleaner in the TBB sampler renderer compared to the default sampler renderer.

My tests on SPPM (when I was writting the threaded improved version) always shown better performances over TBB than using my custom parallel API.

Tbb will really shine on other renderers (especially those with not so parallel tasks, such as the exphotonmap or any hybrid renderer, VCM, CBPT). Having the exphotonmap integrator building the photon map in parallel is a ten minutes hack.

So my question is: what should I do to re-open the debate about inclusion of TBB in luxrender ? I have the feelling that because this work is on a separate branch, no one tests, no one cares.

[SATtva]

So my question is: what should I do to re-open the debate about inclusion of TBB in luxrender ? I have the feelling that because this work is on a separate branch, no one tests, no one cares.

Indeed. My vote is to merge it with the main branch right after 1.2 release. If it doesn't introduces any regressions, but may provide clear benefits (especially for advanced modes like hybrid rendering or VCM), i think it worth it.

[Lord Crc]

Thanks guibou, and sorry for slacking.

I must admit I feared dragging in another dependency, but I finally gave it a shot. TBB built flawlessly out of the box on MSVC 2010 and I'll be moving to precompiled libs for the windows builds, I don't have any reservations against including TBB. I just compiled the thing a few days ago, so I'll do some testing within a few days.