RenderFred
09-15-2005, 03:08 PM
This is part I of my renderfarm experiment with Vue 5 Infinite build 278257. The chosen scene is the well-known Sponza.
The goal of this experiment is to test V5I renderfarming abilities with stills (part I) and animations (part II). I hope it will be helpful for users who want to build a rendering farm, and also for e-on in order to improve this important feature.
In this experiment, I used a 10 PCs renderfarm. I added each PC one after the other in order to record additional gains.
Please be aware that V5i is relatively inefficient for still images parallel rendering when fast and slow PCs render at the same time. V5i does not determine at rendertime what are the "hardest" tiles to render, so if a very slow PC gets a very hard tile, it will continue to render long after all the others have finished. The renderfarm could actually render faster without the slowest PCs ! If all the PCs on the network have the same rendering power, of course the problem goes away.
This problem could be dealt with simply by allowing manual allocation (by the user) of the number of tiles. With small tiles, even slow PCs would not get stuck too long, particularly in small renderfarms. I hope this option will be implemented in future versions of V5i.
In each case the Manager was running on the fastest PC (Opteron). There was no noticeable delay to transfert the scene and the textures to the other machines on the network (a few seconds max).
Sponza scene, ultra rendering mode, render to screen, 1024 x 768 pixels.
PC 1 added (Dual Opteron 275 @ 2442 MHz) : 40 mn 24 s - 4 tiles
PC 2 added (Dual Xeon @ 2800 MHz) : 33 mn 14 s - 9 tiles
PC 3 added (Pentium 4C @ 3200 MHz) : 23 mn 08 s - 16 tiles
PC 4 added (Pentium 4C @ 3400 Mhz) : 20 mn 14 s - 16 tiles
PC 5 added (Pentium 4C @ 3300 Mhz) : 18 mn 34 s - 25 tiles
PC 6 added (Pentium 4C @ 3300 MHz) : 16 mn 09 s - 25 tiles
PC 7 added (Athlon 64 @ 2450 MHz) : 14 mn 58 s - 36 tiles
PC 8 added (Athlon 64 @ 2400 MHz) : 14 mn 11 s - 36 tiles
PC 9 added (Athlon 64 @ 2400 MHz) : 13 mn 33s - 36 tiles
PC 10 added (Athlon XP @ 2250 MHz) : 12 mn 03 s - 49 tiles
So the entire renderfarm completed the job 3.35 times faster than the fastest machine. It does not seem extremely impressive, but you will see that kind of result if one or two machines are clearly faster than the others.
Note 1 : I had many crashes (V5I goes back to desktop) at the beginning of rendering. It seems to be a consequence of running repeated renderfarm runs without quitting and reloading the app first. The first time it occurred was after adding PC 5. I reloaded V5i and the Sponza scene and all went well. It seems that repeated renderfarm runs are difficult to handle by the program if you add new PCs one by one, and then render. If you add all the PCs you need in one run (this is generally the case) there is no problem.
Note 2 : the display in the 'RenderCow Status' of the HyperVue network manager is rather strange. At the end of a render, you get the impression that many PCs are rendering the same tile, which is obviously not the case. I think it is a display bug. Has anyone noticed this ?
Part II of the experiment (in a few days if I find the time) will use the same protocol but with an animation. In that case images are not cut into tiles, but each frame of the animation is sent to a different PC. Efficiency should be better, as the complexity does not vary much between frames.
The goal of this experiment is to test V5I renderfarming abilities with stills (part I) and animations (part II). I hope it will be helpful for users who want to build a rendering farm, and also for e-on in order to improve this important feature.
In this experiment, I used a 10 PCs renderfarm. I added each PC one after the other in order to record additional gains.
Please be aware that V5i is relatively inefficient for still images parallel rendering when fast and slow PCs render at the same time. V5i does not determine at rendertime what are the "hardest" tiles to render, so if a very slow PC gets a very hard tile, it will continue to render long after all the others have finished. The renderfarm could actually render faster without the slowest PCs ! If all the PCs on the network have the same rendering power, of course the problem goes away.
This problem could be dealt with simply by allowing manual allocation (by the user) of the number of tiles. With small tiles, even slow PCs would not get stuck too long, particularly in small renderfarms. I hope this option will be implemented in future versions of V5i.
In each case the Manager was running on the fastest PC (Opteron). There was no noticeable delay to transfert the scene and the textures to the other machines on the network (a few seconds max).
Sponza scene, ultra rendering mode, render to screen, 1024 x 768 pixels.
PC 1 added (Dual Opteron 275 @ 2442 MHz) : 40 mn 24 s - 4 tiles
PC 2 added (Dual Xeon @ 2800 MHz) : 33 mn 14 s - 9 tiles
PC 3 added (Pentium 4C @ 3200 MHz) : 23 mn 08 s - 16 tiles
PC 4 added (Pentium 4C @ 3400 Mhz) : 20 mn 14 s - 16 tiles
PC 5 added (Pentium 4C @ 3300 Mhz) : 18 mn 34 s - 25 tiles
PC 6 added (Pentium 4C @ 3300 MHz) : 16 mn 09 s - 25 tiles
PC 7 added (Athlon 64 @ 2450 MHz) : 14 mn 58 s - 36 tiles
PC 8 added (Athlon 64 @ 2400 MHz) : 14 mn 11 s - 36 tiles
PC 9 added (Athlon 64 @ 2400 MHz) : 13 mn 33s - 36 tiles
PC 10 added (Athlon XP @ 2250 MHz) : 12 mn 03 s - 49 tiles
So the entire renderfarm completed the job 3.35 times faster than the fastest machine. It does not seem extremely impressive, but you will see that kind of result if one or two machines are clearly faster than the others.
Note 1 : I had many crashes (V5I goes back to desktop) at the beginning of rendering. It seems to be a consequence of running repeated renderfarm runs without quitting and reloading the app first. The first time it occurred was after adding PC 5. I reloaded V5i and the Sponza scene and all went well. It seems that repeated renderfarm runs are difficult to handle by the program if you add new PCs one by one, and then render. If you add all the PCs you need in one run (this is generally the case) there is no problem.
Note 2 : the display in the 'RenderCow Status' of the HyperVue network manager is rather strange. At the end of a render, you get the impression that many PCs are rendering the same tile, which is obviously not the case. I think it is a display bug. Has anyone noticed this ?
Part II of the experiment (in a few days if I find the time) will use the same protocol but with an animation. In that case images are not cut into tiles, but each frame of the animation is sent to a different PC. Efficiency should be better, as the complexity does not vary much between frames.