LuxRender v1.0RC1 release

[J the Ninja]

The reason we changed it to 48/48 was because with the CPU bidir there was no real performance difference. Wondering if we should change it back now.

[Meelis]

The reason we changed it to 48/48 was because with the CPU bidir there was no real performance difference. Wondering if we should change it back now.

Maybe rr helped and most path depths were more like 16/16 even with 48/48 settings.

BTW has anybody made super clean render with 16/16 and 128/128 or something, is there any differents in visual look?

[rendermagic]

The reason we changed it to 48/48 was because with the CPU bidir there was no real performance difference. Wondering if we should change it back now.

Maybe rr helped and most path depths were more like 16/16 even with 48/48 settings.

BTW has anybody made super clean render with 16/16 and 128/128 or something, is there any differents in visual look?

I've done some of my own personal experimenting, but I don't have any leftover images to post. From what I can remember, the big difference between the settings was that there was a slightly better performance, up to 64/64, but no difference in quality. I did these test for CPU bi-dir and many of my scenes use a lot of glass 2 materials. The performance difference above 16/16 was hardly noticeable. I have a lot of RAM, so I'm thinking that if I didn't have a lot of RAM, my real performance advantage would have been between 16-32/16-32.

As for hybrid bi-dir testing, I haven't been able to do any tests on that yet. I was going to wait until Jenaphi finished his latest fixes with it.

[Lord Crc]

BTW has anybody made super clean render with 16/16 and 128/128 or something, is there any differents in visual look?

The main difference in my experience is in scenes with glass which experience total internal reflection. If you set the max depth to low it will just be black there, which can cover a non-trivial amount of the glass. In my experience the benefit dropped off after 50/50 in most scenes which were prone to this.

[jeanphi]

Hi,

SSS materials also need higher path depths. For the hybrid version it might be advisable to do RR rejection of path connections.

Jeanphi

[Dade]

BTW, it shouldn't be particularly hard to solve the problem with very long eye/light paths in hybrid bidir (i.e. use dynamic memory allocation instead of static allocating of memory up to the max. depth). It is just the current implementation to be very sensitive to the used max. depth. It may be simpler to solve the problem than change exporters, etc.

[dragon]

CUDA is a closed standard. Using a closed standard in an open source project doesn't make very much sense.

CUDA is much faster than OpenCL

With new nVidia-OpenCL-Driver i get a speed down around 50%
This is not really funny - so i do not upgrade to new driver

I mean CUDA as option - SLG can support both OpenCL+CUDA

[SATtva]

CUDA is much faster than OpenCL
With new nVidia-Driver i get a speed down around 50%

You get it wrong. Technically, both OpenCL and CUDA code is processed on the same computation units, the problem is nVidia screwed done something wrong to OpenCL driver/compiler/optimizer while introducing new OpenCL specs support, which resulted in the 50% slowdown with the new drivers. Lets not start a holy war here.

I mean CUDA as option - SLG can support both OpenCL+CUDA

Meaning twice the headache for the maintainer to keep the code driver bugs-compatible.

[pciccone]

There is also the issue that nVidia implemented OpenCL on top of CUDA instead of doing it natively. AMD's implementation is direct. The type of implementation is not a meter for the strength of the API. Also, CUDA does not allow the use of the CPU, while OpenCL provides a model that works for both the GPU and CPU.

[Dade]

My to two cents on the OpenCL Vs CUDA holy war: NVIDIA has recently released the 680GTX, it is an awesome card for gaming ... but no one interested GPU computing is going to use it because it is slower than the 580GTX both in CUDA and OpenCL. Ok, fine, let use the 580GTX ... no way, NVIDIA has stopped the production of the 580. So ? What are you going to buy to run CUDA software ?

Now, I know NVIDIA is working on the "Big" Kepler and it is very likely to be an amazing GPU, but I hope you see how bad is to be locked with a single hardware vendor.

P.S. about CUDA-is-a-lot-faster-than-OpenCL thing, I would very curious to see a comparison between SLG (OpenCL) running on 7970 and Cycles (CUDA) running on 580 (or a 680 or what ever run faster).