Render machine advice

  • I am investigating building a render machine. Looking for feedback from those who’ve done it.

    My driving design consideration was to get an LGA2011x2 motherboard to support 2 Xeon processors. My thought is that two Xeons will render faster than a single i7. The 2687w seemed like a good price point and with a 3368 Geekbench score, two of them should rip along nicely. I can get the 2687w at just over $200 each used on eBay, so the final price would be below $1800.

    Thoughts? Are there limitations in Poser or Superfly that would make this a bad choice?

    PC Part Picker configuration

  • Poser Ambassadors

    @ctrl-shift That looks promising. I would like to verify that the motherboard will read the 32GB unregistered RAM. I don't see any details which specify "____GB of unregistered RAM, ____GB registered RAM". But, the RAM of 512GB tells me that the main chipset is stout. I can find a .pdf on Intel's site for the C602 main chipset, but it doesn't state unregistered/registered limits either.

    I think the mobo will read all 32GB of that memory, but I can't verify that. Can anybody confirm/deny this? @shvrdavid might know.

    Power supply size is good. Good CPU coolers.

    Those processors would give 32 render threads at 3.1GHz, a core * clockspeed factor of 99.2 - that packs a whollop!

  • @ctrl-shift why blow all that cash on 2 Xeons when GPU rendering is much faster?

  • @seachnasaigh is it possible to use SM Download Manager to directly download and install just QueueManager on a render node? Or is it just a matter of copying the QueueManager application from the workstation to the render node?

    I have a MacBook Pro gathering dust which I'd like to use as a render node, but it has such limited space that I don't want to waste it downloading more than absolutely necessary. [250GB internal HDD with <10GB free]

  • @anomalaus D'Oh! RTFM!!! Enter the serial number for Queue Manager in SM Download Manager on the remote node and its download options become just the QueueManager relevant installers. [The forest trembles and the mountains resound with the tintinnabulation of a cataclysmic forehead slap]

  • Poser Ambassadors


    • CPU rendering can use all of the machine's RAM, not limited to the GPU's onboard VRAM

    • In the past, Firefly GPU rendering has lacked some capabilities (volumetrics)

    • CPU rendering is universal to all popular render engines, whereas GPU rendering options often require a particular type of card (Lux uses ATI/Radeon, Superfly uses nVidia)

    • Some render engines don't offer GPU rendering (HyperVue)

    • Queue Manager can't network out GPU animation/batchlist renders

    GPU rendering is a great addition to the Poser arsenal, but CPU rendering still has its place.

    @ctrl-shift could also install a couple of GPUs in addition to the Xeons. If so, I'd get a 1200W-1350W power supply.

  • Poser Ambassadors

    @anomalaus Yes. It's easy to overlook that a separate Queue Manager serial key comes with Poser Pro.
    For the wider forum: You can run Queue on as many machines as you wish. Install DLM, insert the Queue Manager serial (^not^ the Poser Pro serial), and DLM will download only Queue Manager, which basically the render engines (Firefly, Superfly, et al) with a bit of networking and minimal UI framework.
    It is noticeably smaller than Poser Pro.

  • @ghostship The main reason is that GPU cards don't fit into my MacBook Pro. If I have to buy a windows machine, I might as well build one that is capable without an expensive GPU. I can add a card later, if it really outperforms these two Xeon chips. I've laid out the i7 build and it doesn't come cheaper.

    I looked into adding an external GPU via thunderbolt, but that in itself is a big expense and there were too many risks. I think I could do it now if I upgraded my mbp to one with USB-C, but there is another expense. And its not easy to add an external graphics card- it is a complicated driver mess and it ties you to the desk anyway. On top of that, I recall complaints around GPU rendering with Poser - and I haven't seen any recent threads on that topic. All risks tell me to buck-up, put my mbp aside, and invest in a Windows CPU.

    I won't be happy to have a windows machine back in the house. The happiest days of my life were after I bought my mbp and didn't have to deal with windows BS. (To each their own.) I hope to be able to continue to design on my mbp. @ 5 years old it is still amazingly capable. But we will see. If turnaround on the renders is quick enough, it may make more sense to stay in one environment. I think the trade-off around render-quality vs. render-time will play into this too. If I like the quality I can get from letting it run a little longer, I may keep designing on the mbp to keep the work flowing.

    @seachnasaigh Thanks for the advice. It looks like non-ECC RAM will work just fine. I also like the idea of getting a larger power supply now in case I want to add some monster card later.

  • @seachnasaigh strike-that. ECC required for 2 CPUs.

  • Poser Ambassadors

    @ctrl-shift If that is so, then shop for server memory, registered with ECC (error correcting code). Expect it to be more expensive than gaming desktop memory.

  • Poser Ambassadors

    If you need to change the memory in your build, I would also specify metal heat spreaders to the registered ECC memory.

  • Poser Ambassadors

    @ctrl-shift said in Render machine advice:

    I can add a card later, if it really outperforms these two Xeon chips. I've laid out the i7 build and it doesn't come cheaper.

    I also like the idea of getting a larger power supply now in case I want to add some monster card later.

    For the benefit of others reading through this thread, be aware that you cannot run two i7 processors on a server motherboard. They'll physically fit the sockets, but i3/i5/i7 CPUs lack the circuitry which handles parallel processing. So if you are going to run dual CPUs, get Xeons.

Log in to reply

Looks like your connection to Graphics Forum was lost, please wait while we try to reconnect.