I received at least one email suggesting a Windows-based rendering farm - likely to consist of a few rack systems all running 64-bit Windows. I read an article on Tomshardware which gave some decent insight. What can list participants offer on this concept?
I don't care _how_ the resource is implemented - virtual machine, cluster, etc. I just want to get the most resources for the money, and permit the users to get the results they need, when and how they need it. If a desktop solution can be implemented in multiuser farm environment, that would be great. Just provide links/resources to help me get better educated. Who knows, maybe others on the list would benefit from the discussion and results, too.
If it makes most sense to migrate the money from a single desktop to a transparently available farm that does the same job the desktop could have done, and considering the farm is expandable, then I'm all for it, as would be the money people!
Insights and educated welcome!
Scott
Funny, I build/maintain em all the time.
U in VFX by chance?
What are you rendering, in what app? If the app is only in Winblowz, hen thats the pain u will be in.
What are your artists, mainly VFX sup comfortable in, Winblowz or Linuz?
I like to ask the VFX sup what he/she wants first b4 proceeding. If they dunno, pitch pros and cons of each.
If you got OSX in here, its easier to go Linux on the farm.
2D has very diff characteristics then 3D.
I saw that very same Toms article, it seemed to be written from an artists perspective.
These things can spiral out of control easily so first is first, is this for an immediate project or you want to amortize this over time?
If u b in VFX, Bell Computers rents render farms and will apply that rental 100% to purchasing it, a win win. We currently have some 16 core beasties from him now. The only caveat is that your rental has to be consecutive in terms of time rented.
Don't cheap out on the switch if you can afford to amortize over a few years. You will feel pain using Dell/Netgear switches if doing Mental Ray particle cache renders which I've sen 15GB per frame.
I've always liked Foundry/Extreme, unlike Cisco/Netgear, they are non blocking meaning they don't over subscribe there backbone.
The backbone of any farm is the file server, so be vert careful and find out what kind of bandwidth you need.
Ping me off line if you need, to me this is a huge conversation.
On Oct 9, 2009, at 3:40 PM, Scott Ehrlich wrote:
I received at least one email suggesting a Windows-based rendering farm - likely to consist of a few rack systems all running 64-bit Windows. I read an article on Tomshardware which gave some decent insight. What can list participants offer on this concept?
I don't care _how_ the resource is implemented - virtual machine, cluster, etc. I just want to get the most resources for the money, and permit the users to get the results they need, when and how they need it. If a desktop solution can be implemented in multiuser farm environment, that would be great. Just provide links/resources to help me get better educated. Who knows, maybe others on the list would benefit from the discussion and results, too.
If it makes most sense to migrate the money from a single desktop to a transparently available farm that does the same job the desktop could have done, and considering the farm is expandable, then I'm all for it, as would be the money people!
Insights and educated welcome!
Scott _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Scott Ehrlich wrote:
I received at least one email suggesting a Windows-based rendering farm - likely to consist of a few rack systems all running 64-bit Windows. I read an article on Tomshardware which gave some decent insight. What can list participants offer on this concept?
Well, since you've asked in a Linux forum, let's discuss Linux-based render farms instead, okay?
(If not okay, kindly take your question somewhere else. Thank you. :) )
It comes down to whether the rendering app has a Linux version.
This is more common than you (or those emailing you) might think. Many companies with Windows or Mac-only GUI tools offer command-line Linux versions specifically for use in render farms. Such versions are not always advertised; it may only be available to select customers, on request.
If your client is a VFX studio with many seats of the GUI version of the VFX tool in question, it'll be a lot easier to get access to such tools than if you're a lone gun.
I don't care _how_ the resource is implemented - virtual machine, cluster, etc.
Generally you let the tool itself tell you how the implement the farm. Often such programs are built with a proprietary networking protocol that distributes the work for you, and has certain assumptions about the system architecture built into it.
Sometimes it's possible to buy third-party farm management software that works better than the first-party offering.
Either way, you don't decide on the architecture before studying the existing tools.
Just provide links/resources to help me get better educated.
Ask the vendors of the tools in question. They will have documentation.
If it makes most sense to migrate the money from a single desktop to a transparently available farm that does the same job the desktop could have done, and considering the farm is expandable, then I'm all for it, as would be the money people!
In my limited VFX experience, render farms are never transparent. At bare minimum, expect the "render on farm" command in the program to be different from the "render locally" command, and for it to work differently in key ways. You're not likely to get the same visual progress indications when rendering to the farm as when you render locally.
It's not uncommon for the entire render setup process to be up to the individual artist, at least with the in-box render farm support. This is one big reason why the third-party farm management software market exists.
Warren,
It's not anything I had ever looked into, or needed, but thanks for the view into the heavy duty rendering field.
mark Warren Young wrote:
Scott Ehrlich wrote:
I received at least one email suggesting a Windows-based rendering farm - likely to consist of a few rack systems all running 64-bit Windows. I read an article on Tomshardware which gave some decent insight. What can list participants offer on this concept?
Well, since you've asked in a Linux forum, let's discuss Linux-based render farms instead, okay?
(If not okay, kindly take your question somewhere else. Thank you. :) )
It comes down to whether the rendering app has a Linux version.
This is more common than you (or those emailing you) might think. Many companies with Windows or Mac-only GUI tools offer command-line Linux versions specifically for use in render farms. Such versions are not always advertised; it may only be available to select customers, on request.
If your client is a VFX studio with many seats of the GUI version of the VFX tool in question, it'll be a lot easier to get access to such tools than if you're a lone gun.
I don't care _how_ the resource is implemented - virtual machine, cluster, etc.
Generally you let the tool itself tell you how the implement the farm. Often such programs are built with a proprietary networking protocol that distributes the work for you, and has certain assumptions about the system architecture built into it.
Sometimes it's possible to buy third-party farm management software that works better than the first-party offering.
Either way, you don't decide on the architecture before studying the existing tools.
Just provide links/resources to help me get better educated.
Ask the vendors of the tools in question. They will have documentation.
If it makes most sense to migrate the money from a single desktop to a transparently available farm that does the same job the desktop could have done, and considering the farm is expandable, then I'm all for it, as would be the money people!
In my limited VFX experience, render farms are never transparent. At bare minimum, expect the "render on farm" command in the program to be different from the "render locally" command, and for it to work differently in key ways. You're not likely to get the same visual progress indications when rendering to the farm as when you render locally.
It's not uncommon for the entire render setup process to be up to the individual artist, at least with the in-box render farm support. This is one big reason why the third-party farm management software market exists. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
mark wrote:
It's not anything I had ever looked into, or needed, but thanks for theview into the heavy duty rendering field.
I'm glad you were able to extract some value from my incoherent babbling. (No false modesty....on re-reading the post it's clear the caffeine isn't working yet.)
-
aurfalien＠gmail.com -
mark -
Scott Ehrlich -
Warren Young