Re: Introduction

Hi Paul, Hi Mulyadi,

here are my two (euro) cents:

Mulyadi Santosa wrote:

>Dear Paul...
>
>I am not a 3D experts.....I am more specialized on clustering 
>solution....but OK, I'll give it a try to bring some hints...
>  
>
>>What renderer do you use, why do you like it, what don't you like in
>>it? This is not a renderer war, it is just a gauge of what the users
>>think.
>>    
>>
>
>If you are limited on budget and would like to consider open source 
>solution, try Aqsis. Go to http://aqsis.sourceforge.net for complete 
>details.....
>
>  
>
In my opionion this will be determined by the 3D user to IT admin ratio. 
If you have only limited IT admin resources you should go with an easy 
off-the-shelve integrated option like Mental Ray. This gives you good 
performance, a good integration into your 3D application and minimal 
problems for your IT staff to deal with. In the early days we were using 
a pipeline from Softimage 3D to Renderman. Comparing that workflow (I 
should say workblockage) to a  Soft3D/XSI to MentalRay one, it was so 
obvious that we had to switch. No more handfiddeling scenes that didn't 
render as expected, getting shaders to work right and so on...

>>If we choose a render engine like Mental Ray (though Brazil is
>>favoured by my IT guy...) is it worth investing in more cluster boxes
>>or more ram per box? John Hearns suggested dual opteron 2 GB ram
>>solutions, which seems to be a good price/performance solution. But,
>>should one go for 1 MB or 2 MB L2 cache on those computers? As an old
>>IT-student I'd say bigger cache wins, but price/performance do
>>matter, and is the win that big?
>>    
>>
>
>Well, IMHO, bigger L2 cache is always a plus. But, we do know that cache 
>is only helpful if there are big percentage of cache hit.....in other 
>word, the most used instructions and data need to be fit well inside 
>the cache and the program tends to prevents cache thrashing (e.g 
>because there are many data write which invalidates the cache 
>frequently)
>
>So, in short...I guess the best solution is to rent an experimental box 
>from a vendor and do profiling against your preferred application (e.g 
>renderer) and see which one gives you better cache hit based on your 
>estimated workload. Use :
>-LPerfex ( http://www.osc.edu/~troy/lperfex/oldversions.html)
>or
>- OProfile (http://oprofile.sourceforge.net/examples/)
>to help you gathering important statistics....
>
>  
>
I can second that. Bigger L2 cache is always a good investment.

>>I'm also thinking middle of the road opterons, since the price jump
>>for a couple of hundred extra MHz often is way out of proportion from
>>the gains in processing speed.
>>    
>>
>
>Perhaps...you could consider AMD Althlon MP? Cheaper...and SMP ready....
>Anyway, do you need really 64 bit application?
>
>  
>
No way. I wouldn't want to trade my Opteron boxes for anything right 
now. What makes the difference to Intel is, that you have a much better 
memory performance on Opteron boxes, due to the fact that Xeons do have 
to share the single memory bus with all CPUs. Especially rendering is a 
dependend on memory performance.

We took one step lower CPUs than the topmodell and this is ok. Also you 
might want to wait for the Dual-Core Opterons, which will give you a 
dual socket box with four CPU-cores. This won't give you double the 
performance, but near and way cheaper than a second box...

Also check if there are 64bit Versions of your renderer. Most 
applications start to offer them now. Advantage of this is, that you can 
use more than 2GB of system memory in an efficent way. Depending of your 
needs, this might also be a big plus of 64bit processors.

>>Do you guys on this list use Linux exclusively, or do you more or
>>less use linux for rendering farms?
>>    
>>
>
>Linux is frequently used on high end renderfarm...maybe because three 
>reasons : cheap , open source and reliable. However, sometimes you need 
>to tweak the Linux kernel, along with the applications itself to gain 
>fastest perfomance. But you must also pay attention about application 
>compatibility with certain Linux distribution. Always spend enough time 
>to ensure the compatibility, because if not, you might end up with 
>frequent crash/hang
>  
>
Yes. For certain applications you might find that there is no reliable 
support for linux. We for example run our main renderfarm on Windows, 
'cause the stability for Digital Fusion Renderers isn't quite there on 
Linux. Let's just hope that FU5 will work fine on linux...

The other machines are running Linux (Servers run Gentoo, Workstations 
RedHat (where required) and Debian). We do our rendering with our 
baselight grading software completely on Linux and I can say that this 
is absolutely stable. Rendering 100.000+ 2k frames without a single 
crash or reboot.

       Best,
   
             Frank...

>And last...for batch queueing program, try to consider DrQueue, SunGrid 
>Engine, or openPBS. Each has its own strengths and weaknesses....but I 
>heard SGE is getting popular for handling renderfarm jobs.
>
>regards
>
>Mulyadi Santosa
>  
>
 

-----------------------------------------------
Frank Hellmann     [email protected]     www.vfx.to
Reimarusstr. 17    20459 Hamburg    Germany



-------------------------------------------------------
SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate
online with coworkers and clients while avoiding the high cost of travel and
communications. There is no equipment to buy and you can meet as often as
you want. Try it free.http://ads.osdn.com/?ad_id=7402&alloc_id=16135&op=click