LuxCoreRender Forums

Sharlybg wrote: Thu Mar 08, 2018 4:24 pm

A bit vague what you report, but i would try with/without cpu on a less powerful machine.

Very slow compile time. And poor performance compared to CPU.But will add more after testing on AMD GPu.

Checked over, can verify following:
Its now like a Brontosaurus, aka starts smaller at the beginning, reaches a peak in the middle and the geos down to low renderspeed again.
Odd.
Example: luxball starts around 28M goes up to 33M+ and stays with alpha 5.
Alpha 6 reaches 32M but within a few minutes decreases to 4M and less.
! The NVidia app shows the gpus go down to lowest powermizer state, as they would goto idle !!!

Tested with orig alpha6 as well as my own builds. Same behaviour.
Tescase: Microphone scene with luxcoreui: ./bin/luxcoreui -d '/media/Workdata3/Development/Lux_dev/linux_reboot/LuxCoreTestScenes/scenes/LuxMark-LuxBall' -D opencl.devices.select 111 -D batch.haltthreshold.stoprendering.enable 1 '/media/Workdata3/Development/Lux_dev/linux_reboot/LuxCoreTestScenes/scenes/LuxMark-LuxBall/render.cfg'

Edit: its the convergence reaching 100% muddling me here, the microphone testscene is so fast finished, the convergence goes down fast.So my observation is normal. The confusion comes from the render stats still show samples/sec when finished.
This turned also out to be a bit flakey, cause the gpu(s) never get released. Wonder what did change here, afaik we had convergence test already in alpha5 ?

Checked over, can verify following:
Its now like a Brontosaurus, aka starts smaller at the beginning, reaches a peak in the middle and the geos down to low renderspeed again.
Odd.

My results:

GPU
CPU

Sharlybg wrote: Thu Mar 08, 2018 4:45 pm

Checked over, can verify following:
Its now like a Brontosaurus, aka starts smaller at the beginning, reaches a peak in the middle and the geos down to low renderspeed again.
Odd.

My results:

GPU

GPU.jpg

CPU

cpu.jpg

With hotel i could reproduce your slow render with pascal and maxwell gpu's.
But only with official alpha6, my own build is fast, If you have linux also, try it out.

Example : GTX 980ti 1.8M with alpha6, 3.8M with my build.( off. alpha5 3.2M )

newer alpha6 build doesn't show any artifacts on Display, had rarely crashed but...
... BUT
Compile times are unreasonably looong now with alpha6 on NVidia & win7... even a small scene with not that much of textures (2k+) renders it noncompetitive (for an artist = unusable). Alpha5, hell even Indigo & AMD's RPR (baykal) run circles around this... so may i know: "What's the bug or the point?"

edit: without textures compiling times are fine.

@ jensverwiebe
Do you have a build available for Win? ... i have never build anything (i just mash up)


Impressions otherwise,
very nice flow, stable, fast & responsive Display time
love new mat. preview & IOR on glossy
seems as if Lux is coming nicely back together again

kintuX wrote: Thu Mar 08, 2018 11:16 pm [snip]
@ jensverwiebe
Do you have a build available for Win? ... i have never build anything (i just mash up)
[/snip]

Nope, i have only linux and osx builds in testing.

Jens

About the TILPATH halt conditions: TILPATH has its own halt conditions based on number of passes and/or tile convergence test.

Now I have added the support for generic film halt conditions like samples per pixel, time and/or film convergence test so they will work too in the next alpha.

Now I have added the support for generic film halt conditions like samples per pixel, time and/or film convergence test so they will work too in the next alpha.

thanks you !

About NVIDIA performance, I'm unable to replicate the problem on Linux with a 980 GTX.

This is likely to be related to Windows terrible thread scheduler and hybrid rendering: the CPU may be busy and unable to "feed" the GPUs fast enough.

Try to compare alpha5 and alpha6 disabling hybrid rendering by setting the number of native threads to 0. Once hybrid rendering is disabled, you should obtain exactly the same performance.

If this is true, you can than try to re-enable hybrid rendering leaving, at least, 1 core free for each GPU you are using (i.e. 4xCore+1xGPU => 3 native threads, 4xCore+2xGPU => 2 native threads, etc.).

P.S. NVIDIA compilation times are yet another topic.

jensverwiebe wrote: Thu Mar 08, 2018 4:10 pm

Sharlybg wrote: Thu Mar 08, 2018 1:44 pm Also notice poor performance on Nvidia GPu.
I've to comfirm with a render onn AMD.

A bit vague what you report, but i would try with/without cpu on a less powerful machine.
NVidia drivers tend to need a bit more "feedpower".

I personally can not reproduce less speed generally, can you be a bit more specific ?

Jens

Already told him. It might be a wiser decision anyway to have nativethreads - gpucount at least.

Also 'am in contact with NVidia about opencl kernel compile.

Hi all,

I've made a test with a scene I'm working on two different computers, one with an gforce gtx 1070 and another with a radeon r9 280x.
After a while I'm getting 1.6M with the gforce and 1.3M with the radeon. Only opencl.

Given radeon is on a much older computer, is this normal?

Thanks.