Open topic with navigation
Network rendering allows additional GPUs in other computers to be utilized in rendering images. OctaneRender distributes compiled render data and not scene data, so no file management is required by the user. Conceptually it is similar to working with additional GPUs by allowing the distributed rendering of single images over multiple computers connected through a fast local area network. Network rendering requires a master and one or more slaves on different computers. The OctaneRender instance that drives the rendering is referred as the “master” and the OctaneRender instances that are helping are referred as the rendering “slaves”.
Since an OctaneRender slave currently requires an activated Standalone license, it is advisable to run the Standalone first to activate a Standalone license on that computer, if necessary. It is best to copy the whole folder of the released archive onto the slave computer. Also ensure that the master and the slave are not blocked by the Operating System firewall or any firewalls in the network. This can be done, for example, by turning off the firewall for home/work networks on the master. If that does not help, also try switching off the firewall on the slave computer for home/work networks.
Master, Slaves and Daemons
The Standalone version or the octane.exe act as master and a special console version of OctaneRender, octane_slave.exe, can run on other computers as slaves. Of course, they should be all on different computers or they would have to share the same GPUs. Running the slave on the same computer as the master is pointless.
The OctaneRender network render slave is fairly dumb and all the render data processing is actually done on the master side. The slave does not need to have a powerful CPU at all, but the slave is of course required to have enough memory (RAM) to store the render data plus some render results. The operating systems of the slaves can also be different since the communication between the machines is cross platform. No data is stored on the slaves’ discs, it all happens 100% in memory.
Each time network rendering is required, the slave process has to be launched on the slave machines. The slave daemon makes the control of the slaves more practical, as slave daemon can be set up to be launched at every start up of the operating system of each machine in the network. The daemon is the little program that starts a slave process on the machine (on request by a master), monitors it and stops it (on request by a master). Monitoring means making sure that a running slave sends a regular “heartbeat” to the daemon and if that doesn’t happen it will try to stop the slave gracefully and if that does not work, it kills the process. The daemon runs all the time and starts/stops a slave process if a master requests it. The daemon also listens for the “heartbeat” of the slave to check if the slave process is still running at all. This slave daemon eliminates the need to launch the slave process manually on each computer each time rendering is required on the slave.
The Standalone Edition’s network rendering feature is also useful while using a Plugin Edition:
Octane’s licenses are per machine where any machine can become either master or slave.
Setting Up The Slave Daemon
To set up the daemon, simply run the batch script _install_daemon.bat on the slave computer. During the setup, it will ask which port the daemon should listen to for master requests. After that, the daemon will be resident on that machine and it will be active at all times.
When a daemon is invoked by a master, the slave is quickly launched to get some information about the number of GPUs, version, bitness, etc. and then closed again. After that there is no slave process running. So the daemon just sits there and waits for masters (there could be multiple masters in the local network) to detect it, by scanning the complete local network in regular intervals. The daemon should appear in the daemon list of the network preferences of the masters. If it does not, it can have the following reasons:
Only when you enable a daemon in the master settings, the slave gets actually launched and will eventually appear in the status bar of the master. One daemon can be activated only by one master at a time. If daemon is currently “occupied” by another master the user will see the daemon state change accordingly. The automatic port configuration is an option on the master that enables multiple masters to be used on the same computer.
When network rendering is disabled, the local network is not scanned for daemons. The master scans for daemons only when network rendering is enabled.
Maximum Number of GPUs
Octane (through the Master) may use the networked gpus provided that the number of gpus do not exceed the limit set by the Octane license for that Master. The Octane full non-subscription license allows a Master (the machine with the GUI open) to render with only a maximum of 40 GPUs at a time. The 40 also includes those that are at the Master. For subscription licenses, a Master is allowed a maximum of 20 GPUs at a time.
In the past v3.05.0 and earlier V3 full versions, Octane only looks for GPUs in slave nodes within the same subnet and thus Octane treats every GPUThe GPU is responsible for displaying graphical elements on a computer display. The GPU plays a key role in the Octane rendering process as the CUDA cores are utilized during the rendering process. in Master (local) and the enabled slaves (remote) altogether as if these are installed directly in the master machine. It will not even know the difference between a GPU in an expansion box or in another machine. In those earlier V3 versions, to Octane, each local and remote GPU in the slaves is just another GPU, so as long as it is available (not used by other renderers or the OS or any other application) and correctly exposed as a CUDA gpu, Octane will pick those GPUs in that subnet until the GPU limit is reached, if the network has more than the GPUs limit then the rest of the available GPUs will just not be used.
In Octane v3.06.x and later versions, the native Octane Network RenderingThe utilization of multiple CPUs or GPUs over a network to complete the rendering process. feature has integrated support for multiple subnets and considers Hostnames and IP addresses. The improved Network Render feature considers the per slave systems that determine how GPUs are allocated to applications and the overall network system configuration that affect how networked nodes allocate processing capabilities between nodes. Depending on how the mix of configurations play out, there are some cases where a network allows Octane to use up to the GPU limit across the network regardless of which slave nodes the GPUs are installed in (per GPU regardless of the slave node) and there are also other cases where the network cuts off the other remaining slaves when a slave will potentially go over GPU limit (so per slave node rather than per GPU, this means all GPUs in that slave or not use that slave at all) - effectively reducing the total rendering GPUs to significantly less than the limit.
In all versions of Octane, there is always some hardware considerations such as the node/GPU power density and heat loads within the slaves which affect availability and usability of each installed GPU.
Open topic with navigation