(L) [2014/02/10] [tarlack] [Re: Hybrid : CPU & GPU strategies] Wayback!Haha, I don't know how to reply [SMILEY :mrgreen:] but as the the author of this paper I can only be happy you cited it... [SMILEY :mrgreen:]
As for the speedup, the goal of this paper was to bring a speedup where no speedups were possible before, but I agree with you for sure that full on-board computations are better when possible [SMILEY :)] And, I'm really impressed by what octane and similar can do !
(L) [2014/02/10] [spectral] [Re: Hybrid : CPU & GPU strategies] Wayback!>> However, in practice, hybrid rendering will never provide the kind of speedup you can achieve with a full OpenCL rendered (or CUDA or whatever you are using).
Sure, but it is not the goal... any speedup is still fine [SMILEY ;-)]
Thx
(L) [2014/02/11] [Dade] [Re: Hybrid : CPU & GPU strategies] Wayback!>> spectral wrote:Sure, but it is not the goal... any speedup is still fine
Yup but a LuxRender-like hybrid rendering (i.e. where only rays are traced on the GPU) provide a very small speedup. If we assume a 50% load for shading and 50% for ray tracing, in a best case scenario (i.e. infinite GPU speed), you get only a 2x speed up. In practice, you obtain only a 15%-60% speed up (it is very scene dependent).
Tarlack's CBPT requires to port to GPU some BSDF evaluation code in addition to ray tracing and, in my opinion, it makes hybrid rendering less attractive. The main feature of hybrid rendering for me is the need to port a very small amount of code to the GPU and suites well the need of adapting a large existing amount of code written for the CPU.
I have also tried a variation of CBPT: I was tracing eye and light paths on the CPU, generating all the n^2 connection rays and tracing them on the GPU. While this kind of code is very easy to write and requires a very little amount of OpenCL code, it doesn't deliver any significant speedup most of the times. It is a pit, it was a kind of solution very easy to apply to any existing Bidirectional path tracer.
Let's hope that all the upcoming CPU/GPU integration on the horizon (i.e. AMD HSA, etc.) will change a bit the scenario.
(L) [2014/02/11] [tarlack] [Re: Hybrid : CPU & GPU strategies] Wayback!I have learned quite a lot since I wrote CBPT about engineering hybridized code without adapting too much and having duplicated algorithms... I would implement it very differently now. In fact, for the parts that need to be hybridized, I think that it is very worthwhile thinking in terms of code and memory layout that need to be usable both on CPU and GPU without changing a single line of code in the algorithms, and only making the data access code different (direct array access on CPU, texture accesses on GPU, for instance). Some #defines for the openCL/CUDA specificities which will reduce to almost nothing for CPU, and you're up for a good deal of work saved, and a very good maintainability. And you can debug your GPU code on CPU ! (at least for everything not linked to race conditions and so on) .