Network rendering support

[jensverwiebe]

You can use a command line option like "-D opencl.devices.select 010" to have a specific setting in every rendering node. You can use any number of custom properties and they will be used to override the settings coming from the network.

Yes i know, but i prefer not to have intel ocl in any case on linux.
Remember the flag incompatibilities also ? Afaik -strict-aliasing is borked on intel ocl. Not worth the hazzle.
Seems 'am back for good in "all directions" again

Jens

[jensverwiebe]

OSX nodes now checked too, there is a change noticed:
Although the export was with "use_gpu" but not "use_cpu" for ocl, the mac now uses all available
ocl devices. I guess thats wanted unless i define other way.
I overlooked this cause my expectation was exported config is used in first place.

EDIT: i noticed combining gpu('s) with cpu is much more effecient as it formely was, the win is noticable now.
I may reconsider my linux setup too.

EDIT2: just FYI: an 3.8GHz i7 5960 8core only adds 2 % over my 3 gpu, so i stay without using it for ocl.
Removed last statement for osx, the better speed is from gpu alone, seems something else was also optimized by the latter fixes.
The additionally cpu on mac also gives only a few % but lot more heat indeed ( good in winter but surely on edge in summer )

EDIT3: aaah, now ic:

Code: Select all

-			opencl.gpu.workgroup.size = 0
+			opencl.gpu.workgroup.size = 64

This explains it

Alright so far ... Jens

[Dade]

Added the support for rendering multiples files with something like:

Code: Select all

pyluxcorenetconsole --halt-spp 1000 scene1.bcf --halt-spp 1500 scene2.bcf

[jensverwiebe]

Atm. try to debug ( hash 38f7772 ):

Code: Select all

Traceback (most recent call last):
  File "samples/pyluxcorenetconsole/pyluxcorenetconsole.py", line 38, in <module>
    cmd.main(sys.argv)
  File "./lib/pyluxcoretools.zip/pyluxcoretools/pyluxcorenetconsole/cmd.py", line 177, in main
    line = line.strip()
  File "./lib/pyluxcoretools.zip/pyluxcoretools/pyluxcorenetconsole/cmd.py", line 149, in Exec
    
  File "./lib/pyluxcoretools.zip/pyluxcoretools/renderfarm/renderfarmjobsingleimage.py", line 76, in __init__
  RuntimeError: unregistered class

Not yet any idea

[Dade]

Atm. try to debug ( hash 38f7772 ):

Code: Select all

Traceback (most recent call last):
  File "samples/pyluxcorenetconsole/pyluxcorenetconsole.py", line 38, in <module>
    cmd.main(sys.argv)
  File "./lib/pyluxcoretools.zip/pyluxcoretools/pyluxcorenetconsole/cmd.py", line 177, in main
    line = line.strip()
  File "./lib/pyluxcoretools.zip/pyluxcoretools/pyluxcorenetconsole/cmd.py", line 149, in Exec
    
  File "./lib/pyluxcoretools.zip/pyluxcoretools/renderfarm/renderfarmjobsingleimage.py", line 76, in __init__

Not yet any idea

The error ? You forgot to copy the last line of the message. Previous log messages are significative too.

If you get an error while loading the film (and the film file is not corrupted), you may be using executable compiled from different source versions or different Boost version, etc. Check to use the same executable everywhere.

[jensverwiebe]

Ups, error is "RuntimeError: unregistered class"

Hmm the build env, did not change, i recheck ...

EDIT: you are right, deleting .flm made the issue go away.
I tested clang builds yesterday ( 10% faster in nativeCPU btw. ) and in this direction it worked. ( gcc created flm -> clang )
But something slipped in once it was touched.

EDIT2: it was testing if we are c++11 ready ( we are not ), so once touched with an c++11 build and going back it broke, makes complete sense..
"Normal" clang vs. gcc builds are fully interchangable.

EDIT3: forgot ... thx Dade for explanation.

Jens

[Dade]

EDIT2: it was testing if we are c++11 ready ( we are not ), so once touched with an c++11 build and going back it broke, makes complete sense..
"Normal" clang vs. gcc builds are fully interchangable.

The version of OpenImageIO we are using is not compatible with C++11 so we can not switch at the moment. However, after the release of v2.0 we can upgrade everything (including the Python version required by Blender v2.8).

[B.Y.O.B.]

(including the Python version required by Blender v2.8).

We might want to wait with that, I will wait for 2.8 to get more stable before I start making the new addon ready for it.
At the moment from what I read 2.8 is unusable for anything but experimental tests (a bit like BlendLuxCore), half of the stuff is not working, so it might take months until we have to switch the Python version.

However I'm all for updating of libraries and testing if we maybe can switch to clang completely (IMO it generates much better error messages than gcc and the speedup is a nice plus, too).

[jensverwiebe]

[snip] ... [/snip]
However I'm all for updating of libraries and testing if we maybe can switch to clang completely (IMO it generates much better error messages than gcc and the speedup is a nice plus, too).

+ clang compiles a lot faster, something good for developer nerves

Jens

[Sharlybg]

Just forget to ask and propose if possible :

__ i don't know the GUI tools behind blender and old luxrender UI but assume the licence here must bring what we need.