Re: Regular crashes with satellite.

[André Adam <a_adam(at)49games.de>]

One thing to keep in mind is the term *contiguous* memory Halfdan used 
below. Most people forget that when they look at the memory available 
via the task manager and think everything should fit just fine while in 
reality the memory may be heavily fragmented. So rendering from the 
command line and using map files definately is worth a try when 
experiencing crashes like the ones you see.
Though this is nowhere officially stated, I seem to notice that memory 
management got better with XP64 vs XP32 (both systems equaly equipped 
with only 2GB), especially when moving towards the physical memory limit.
Regarding XSI not immediately vanishing from memory after shutdown, this 
has always been like this. I guess it performs some kind of cleanup. Of 
course it shouldn't crash...

   -André


Thomas Helzle wrote:
> Ah - Halfdan, thanks a lot for your input - that sounds interesting.
>
> The current renderings are only 2560x1769. I render to .sgi 16 Bit 
> (just because Photoshop insists on making the alpha transparent with 
> no way to stop it from doing that if I render to .tif ... ). The files 
> are 35 MB when converted to uncompressed RGBA tif.
>
> I will try to shut off the disk-framebuffer, but if that would be it, 
> I still guess there is something fishy, since it neither fails on 
> rendering, nor directly after, but 2-5 minutes later or if I try to 
> render again.
>
> (BTW. Insane or not, one of my next jobs may need a 14000x14000 pixel 
> rendering (580MB RGB 8Bit) ;-). My largest so far was 16000x9000 
> rendered in 4 parts in Foundation 4.2, but I've done 10000 wide with 
> no problem before in one chunk.
> Last week I rendered a tree from an emdl-model that was 816MB on disk! 
> It only worked with Scanline (Rasterizer and Raytracing just hang up) 
> but I rendered it 6000x3000 pixels on my laptop in ~20 minutes. Wow.
> That is what I love about MR and one of the main reasons I stick with 
> XSI :-)
> That gigapolycore really isn't advertising...)
>
> Now that diagnostic thing sounds like a lead. Is it in the docs what 
> is and what isn't sent to satellites? I never stumbled over that 
> information before. Is that even true if you use MR-functions-only to 
> retrieve data?
>
> Well, after about 50 crashes/restart cycles I am done for today.
> All the images are rendered and I can now start to try the suggestions 
> from everybody.
>
> I will report back if I find a solution.
>
> Thanks a ton for all the help!
>
> Thomas Helzle
>
> On Dec 15, 2007 7:00 PM, Halfdan Ingvarsson <hingvars(at)softimage.com 
> <mailto:hingvars(at)softimage.com>> wrote:
>
>     If we're talking, say, 10K image for print (which is completely
>     insane, btw), that's ~400MB gone already for 8-bit RGBA output,
>     twice that for 16-bit and four times for float. That's only on the
>     master, however.
>
>     One particular fallout from this, is that mental needs to find a
>     way to fit the entire output image in memory. When using on-disk
>     framebuffers, this can cause problems because mental ray only
>     brings the image into memory when it needs to write a finished
>     tile to disk or generate the output file. Unfortunately, if this
>     doesn't succeed (due to lack of contiguous memory available)
>     mental ray will either silently fail or cause some other problems
>     further down the line.
>
>     With that said, you might benefit by fixing the framebuffer in
>     memory (mental ray options->Framebuffers->On-Disk Framebuffer = Off)
>
>     One thing to bear in mind with 3rd party shaders, is that I've
>     seen instances where they try to look up the name of the object
>     being rendered for the purpose of emitting a diagnostic message.
>     This won't work with satellites since the name table is not passed
>     to them. If the shader doesn't guard against this, it can lead to
>     a crash. Those crashes are likely to happen when the shaders get
>     shut down at the end of render, since that's a popular place to
>     print those diagnostics.
>
>      - ½
>
>     -----Original Message-----
>     From: owner-xsi(at)Softimage.COM <mailto:owner-xsi(at)Softimage.COM>
>     [mailto:owner-xsi(at)Softimage.COM <mailto:owner-xsi(at)Softimage.COM>]
>     On Behalf Of Tim Leydecker
>     Sent: 15-Dec-2007 12:46
>     To: XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>
>     Subject: Re: Regular crashes with satellite.
>
>     2GB isn´t alot to work with, 320MB for XP, 300-600 for XSI plus
>     the amount of RAM mR actually needs.
>
>     I had a lot of problems rendering automotive highrez scenes in
>     Maya 7 32bit w/mR. Pretty much the same behaviour.
>
>     Open scene, render once, grab 32bit file from temp buffer folder,
>     store away savely and watch Maya die on further userinput.
>     Due to a compile bug, Maya batch was no option, the batchprocess´
>     large adress memory flag wasn´t set but since mayabatch didn´t
>     accept user memory limits to be set, instead allways defaulted to
>     800MB, that didn´t matter...
>
>     So I actually guess Kim is on the right track, it is a memory
>     problem, either a bug where memory isn´t free´d up or simply a
>     lack of memory to work with. You might be able to further extend
>     the use of your slaves by adding another 1GB RAM or even throwing
>     in a 4GB RAM kit (should give you 3-3.5 GB useable memory under XP32).
>
>     Currently DDR2 RAM is really cheap, a fresh 4GB kit starts at ~70
>     Euros.
>
>     Also, a good place for specing out a new machine (germany)
>     http://www.heise.de/preisvergleich/
>
>     A one CPU socket bargain basis for upgrades/slaves:
>
>     Gigabyte P35 DS-3 mainboard, Q6600, 4GB Ram ~350 Euros.
>
>     Might be taxically interesting to order/pay this year instead of
>     next.
>
>     Cheers
>
>     tim
>
>
>
>
>     ----- Original Message -----
>     From: "Thomas Helzle" <thomashelzle(at)gmail.com
>     <mailto:thomashelzle(at)gmail.com>>
>     To: < XSI(at)Softimage.COM <mailto:XSI(at)Softimage.COM>>
>     Sent: Saturday, December 15, 2007 6:21 PM
>     Subject: Re: Regular crashes with satellite.
>
>
>     I am using XSI 6.5 Essentials on 3 machines with Win XP SP2 32 Bit
>     with 2
>     Gig of Ram each.
>
>     I encountered the same as you with the image settings and it is
>     set to the
>     correct one.
>
>     My machines aren't rebooted while rendering and I don't change the
>     IPs.
>
>     I don't have SSS shaders in the scene, but I may check if any of
>     the shaders
>     I use is buggy and it only shows up when doing satellite
>     rendering. I know
>     too little about what is going on under the hood when "satelliting" to
>     really make educated guesses...
>
>     I often use the T2S material - is that known to be problematic?
>
>     Sorry if I offended anybody but Kim with my mail, I should have
>     sent it
>     offlist. But I need real help, like from all the other people, not
>     some
>     mutterings without actual substance. I guess I will unsubscribe
>     again after
>     I - hopefully - solved this problem... I'm too emotional for this
>     list ;-)
>
>     Thank you very much for the suggestions, good to know that it is
>     working for
>     you - so something is wrong with my setup.
>
>     Cheers!
>
>     Thomas Helzle
>
>
>     On Dec 15, 2007 5:50 PM, Tim Leydecker <BauerOink(at)gmx.de
>     <mailto:BauerOink(at)gmx.de>> wrote:
>
>     > Which XSI version are you using?
>     >
>     > I´ve lately run XSI 6.02 32bit on XP64 with 4GB/node
>     > and had no errors with sat rendering except for these:
>     >
>     > The image file textures needed to be set to editable
>     > in their PPG otherwise mR would crash, as if the
>     > files had to be *sliced* internally to simplyfy distribution
>     > to the slaves. The other two settings broadcast or whatever
>     > (I don´t have XSI open currently) didn´t work. might be fixed.
>     >
>     > Turning on/off a slave while having a rendersession open
>     > doesn´t work, a bugger that is easily missed is DHCP,
>     > when you have your networked PCs receive random IP
>     > adresses from a router/DHCP server (for security reasons)
>     > you might end up making your slaves unavailable if that
>     > random refresh cyle (once a day, every x hours...) falls
>     > into a timewindow where the slave is rendering.
>     > You´d get mR spit out a warning like "slave xyz died, ...".
>     >
>     > SSS shaders didn´t scale too well in terms of speed, since
>     > the lightmap seems to be calculated locally, idling out the
>     > other slaves for a good amount of time.
>     >
>     > Cheers
>     >
>     > tim
>     >
>     > P.S: I don´t know what would have been wrong with Kim´s reply.
>     >
>     > ----- Original Message -----
>     > From: "Thomas Helzle" <thomashelzle(at)gmail.com
>     <mailto:thomashelzle(at)gmail.com>>
>     > To: <xsi(at)Softimage.COM <mailto:xsi(at)Softimage.COM>>
>     > Sent: Friday, December 14, 2007 7:57 PM
>     > Subject: Regular crashes with satellite.
>     >
>     >
>     > > Hi,
>     > >
>     > > I thought I best ask here if anybody had a similar problem and
>     maybe
>     > found
>     > > a
>     > > cure:
>     > >
>     > > I render lots of printsize images of bottles and other design
>     objects
>     > for
>     > > a
>     > > design agency. I need to render them with satellite, since
>     each image is
>     > > rather large and needs to be rendered as fast as possible,
>     then I change
>     > > for
>     > > instance a label and render again, one image at a time.
>     > > After EVERY render to disk, XSI crashes. Not immediately, but
>     almost as
>     > if
>     > > there was a bomb ticking - equal if I use XSI or if it is
>     minimized to
>     > the
>     > > taskbar or just sits there.
>     > > If I start a second rendering XSI hangs directly after the
>     render window
>     > > opens.
>     > > It would be unusable, but since it never crashes _while_
>     rendering if I
>     > > restart it after each render, it is pretty annoying but not
>     completely
>     > > unusable.
>     > >
>     > > If I close XSI after the rendering, it looks as if it closes
>     just fine,
>     > > the
>     > > GUI is gone, but the taskmanager shows that it is still on,
>     sometimes
>     > > doing
>     > > nothing, sometimes using up one processor. This ghost thread
>     crashes
>     > after
>     > > some time as well.
>     > > In Taskmanager I can see that it is eating memory in little
>     bites until
>     > it
>     > > crashes. But it never reaches anywhere near my 2Gig of
>     installed RAM.
>     > > The scenes are large, since it is NURBS converted to polygons
>     with MOI,
>     > > but
>     > > on rendertime XSI uses something around 300 to 600 MB of RAM -
>     not that
>     > > much...  On the satellites it uses even less.
>     > >
>     > > I use 3 Machines with P4 3Ghz CPUs, 2Gig of RAM each, Gigabit
>     Ethernet,
>     > > Windows XP Pro SP2. They all have pretty much the same specs.
>     > >
>     > > I contacted support already with this, but they were just as
>     clueless as
>     > I
>     > > am.
>     > >
>     > > I hope to be able to buy better machines next year, but for
>     now I have
>     > to
>     > > use what's there. I updated to Essentials mostly because of
>     satellite
>     > > rendering, so I am pretty disappointed with this extreme
>     instability
>     > that
>     > > goes on for months now.
>     > >
>     > > It feels as if some component of satellite rendering doesn't
>     get a clean
>     > > exit after rendering and brings the whole system down after
>     some time.
>     > >
>     > > Since it crashes some time after rendering, I am pretty sure
>     it isn't
>     > > memory
>     > > related. And it doesn't matter how long the rendering takes, I
>     had times
>     > >>from 7 minutes for one image up to 7 hours - it always renders
>     just fine
>     > >>but
>     > > crashes afterwards.
>     > >
>     > > So if anyone has a clue what this could be, I would be very
>     happy - I'm
>     > > out
>     > > of ideas.
>     > >
>     > > ---- Cool, it "vanished" just once more in the background
>     while I was
>     > > writing after a render ...
>     > >
>     > > Cheers,
>     > >
>     > > Thomas Helzle

---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi