LuxCoreRender Forums

Keep in mind that there is a difference in samples/sec mostly because the scene is too simple. In any no trivial scene, the difference should be negligible. You can use one of the scenes at https://github.com/LuxCoreRender/LuxCoreTestScenes to check.

acasta69 wrote: ↑Wed Mar 06, 2019 4:03 pm You are working on windows, right?

I am on Linux, sorry. I will try to compile the debug version now, but it takes ages on my computer

Dade wrote: ↑Wed Mar 06, 2019 4:06 pm Keep in mind that there is a difference in samples/sec mostly because the scene is too simple. In any no trivial scene, the difference should be negligible. You can use one of the scenes at https://github.com/LuxCoreRender/LuxCoreTestScenes to check.

I've noticed that when I used Bidir, even in this simple scene.

Do you think it is worth to investigate it a bit more and fix it for PhotonGI? Sobol is pretty state-of-the-art as far as I could research and I don't know if it is likely that this sequence is capable of surpassing it. The implementation is much simpler, though

alpistinho wrote: ↑Wed Mar 06, 2019 9:25 pm Do you think it is worth to investigate it a bit more and fix it for PhotonGI? Sobol is pretty state-of-the-art as far as I could research and I don't know if it is likely that this sequence is capable of surpassing it.

I doubt it can provide any significative improvement over Sobol too.

There is one aspect of Random/Sobol samplers you could look into: the adaptive aspect. For instance, one part to improve is that they are currently skipping samples instead of just progressing slower on some (already converged) pixel. The current advantage is that there is one single global "pass" instead of a "pass" for each pixel. It saves some ram but it is pretty bad for sampling.

Dade wrote: ↑Wed Mar 06, 2019 11:09 pm There is one aspect of Random/Sobol samplers you could look into: the adaptive aspect. For instance, one part to improve is that they are currently skipping samples instead of just progressing slower on some (already converged) pixel. The current advantage is that there is one single global "pass" instead of a "pass" for each pixel. It saves some ram but it is pretty bad for sampling.

Seems nice, I will have a look into it.

Maybe something like that: https://jo.dreggn.org/home/2009_stopping.pdf

Shamelessly taken from: https://github.com/oktomus/gsoc-2018/bl ... -report.md

alpistinho wrote: ↑Wed Mar 06, 2019 11:46 pm Maybe something like that: https://jo.dreggn.org/home/2009_stopping.pdf

Shamelessly taken from: https://github.com/oktomus/gsoc-2018/bl ... -report.md

Unfortunately, it is the kind of stuff would never work on a GPU.

Dade wrote: ↑Thu Mar 07, 2019 12:59 am Unfortunately, it is the kind of stuff would never work on a GPU.

Hum, they claim the opposite "Due to this simplicity it can be easily integrated in GPU based ray tracing systems", but I have very little knowledge about GPU computation.

Any other suggestions?

alpistinho wrote: ↑Thu Mar 07, 2019 1:02 am Any other suggestions?

I wasn't suggesting to look for a totally new solution, I was suggesting to improve the current one

Dade wrote: ↑Wed Mar 06, 2019 11:09 pm There is one aspect of Random/Sobol samplers you could look into: the adaptive aspect. For instance, one part to improve is that they are currently skipping samples instead of just progressing slower on some (already converged) pixel. The current advantage is that there is one single global "pass" instead of a "pass" for each pixel. It saves some ram but it is pretty bad for sampling.

Why is it bad for sampling that some pixels are skipped?

I am currently trying to integrate the error metric mentioned on https://jo.dreggn.org/home/2009_stopping.pdf to improve the issue lacilaci was reporting a while ago here: viewtopic.php?f=4&t=712&p=7328#p7328

A drawback for this metric is that it is not measured in the same dimension pixel is, but pixel/sqrt(pixel), making more difficult to compare the performance between the two methods.

From that I hope to build up something that could improve the current solution.

alpistinho wrote: ↑Sun Mar 10, 2019 10:37 pm From that I hope to build up something that could improve the current solution.

Do you have already a good idea how to write the implementation in OpenCL for GPUs ?

Dade wrote: ↑Sun Mar 10, 2019 11:34 pm Do you have already a good idea how to write the implementation in OpenCL for GPUs ?

Not yet, I will install the AMDGPU-pro in my Linux box to do that.

Is the structure significantly different from the C++ code? I have never coded for GPU but I understand that the architecture is very different, so I know I need to be careful not to tank the performance.

Right now I am experimenting with some statistic based solution that doesn't require changing anything outside the FilmConvTest::Test() function.