Cant flush from GUI?

[floze]

Mr does not seem to be able to flush it's caches when rendering from within the maya 7.0 GUI. It silently aborts at first flush, without coming back with any error, like if I hit the ESC key. It does work fine in batch mode though. And I guess it worked from within the maya 6.5 GUI too, though I'm not 100% sure.

Did anyone else experience this? Is it even a logged bug maybe, or has this been addressed before? Thanks in advance for your feedback.

[floze]

I was able to render an incredible amount of tris using mayabatch, cache flushing and a proper relation between memory limit and task size:

MEM  0.0  info : heap size limit set to 640 MB

[...]

SCEN 0.0  progr: begin scene preprocessing for frame 1
SCEN 0.0  info : 148226 geometry leaf instances (148226 scheduled, 0 cached, 0 shared)
SCEN 0.0  info : 1 light leaf instance
SCEN 0.0  info : wallclock  0:00:08.69 for scene preprocessing
SCEN 0.0  info : allocated 294 MB, max resident 294 MB
RCB  0.0  info : scene extent: (-0.51,-0.51,-0.51) : (384.51,0.51,384.51)
RCB  0.0  info : scene diameter: 544.494920
RC   0&#46;0  warn   082008&#58; jittering disabled because max samples < 1
RC   0&#46;0  info &#58; option&#58; scanline          rapid
RC   0&#46;0  info &#58; option&#58;   samples collect 1
RC   0&#46;0  info &#58; option&#58;   shading samples 1&#46;0
RC   0&#46;0  info &#58; option&#58;   samples motion  1
RC   0&#46;0  info &#58; option&#58; trace             off
RC   0&#46;0  info &#58; option&#58; shadow            off
RC   0&#46;0  info &#58; option&#58; lightmap          on
RC   0&#46;0  info &#58; option&#58; motion            off
RC   0&#46;0  info &#58; option&#58; luminance weights 0&#46;212671 0&#46;71516 0&#46;072169
RC   0&#46;0  info &#58; option&#58; caustic           off
RC   0&#46;0  info &#58; option&#58; globillum         off
RC   0&#46;0  info &#58; option&#58; finalgather       off
RC   0&#46;0  info &#58; option&#58; filter            clip mitchell 4 4
RC   0&#46;0  info &#58; option&#58; render space      object
RC   0&#46;0  info &#58; option&#58; face              both
RC   0&#46;0  info &#58; option&#58; field             off
RC   0&#46;0  info &#58; option&#58; hair              off
RC   0&#46;0  info &#58; option&#58; hardware          off
RC   0&#46;0  info &#58; option&#58; task size         16
RC   0&#46;0  info &#58; option&#58; pixel preview     off
RC   0&#46;0  info &#58; option&#58; lens              on
RC   0&#46;0  info &#58; option&#58; volume            off
RC   0&#46;0  info &#58; option&#58; geometry          on
RC   0&#46;0  info &#58; option&#58; displace          off
RC   0&#46;0  info &#58; option&#58; premultiply       on
RC   0&#46;0  info &#58; option&#58; colorclip         raw
RC   0&#46;0  info &#58; option&#58; output            off
RC   0&#46;0  info &#58; option&#58; merge             off
RC   0&#46;0  info &#58; option&#58; virtual framebuf  on
RC   0&#46;0  info &#58; option&#58; image   type   interpolate
RC   0&#46;0  info &#58;           0        rgba       yes
RC   0&#46;0  info &#58; camera&#58; focal length      1&#46;37795
RC   0&#46;0  info &#58; camera&#58; aperture          1&#46;41732
RC   0&#46;0  info &#58; camera&#58; aspect            1
RC   0&#46;0  info &#58; camera&#58; resolution        512 512
RC   0&#46;0  info &#58; camera&#58; clip              1 100000
RC   0&#46;0  info &#58; camera&#58; frame             1 1 0
RC   0&#46;0  progr&#58; rendering
RCI  0&#46;0  progr&#58; begin intersection preprocessing
RCI  0&#46;0  info &#58; using the rasteriser for eye rays
RCI  0&#46;0  info &#58; not tracing secondary rays
RCI  0&#46;0  progr&#58; end intersection preprocessing
RCI  0&#46;0  info &#58; wallclock  0&#58;00&#58;00&#46;00 for intersection prep&#46;
RCI  0&#46;0  info &#58; allocated 351 MB, max resident 351 MB
PHEN 0&#46;0  info &#58; ----------------------------------------------
PHEN 0&#46;0  info &#58; mayabase version 7&#46;5, compiled on Jul 19 2005&#46;
PHEN 0&#46;0  info &#58; ----------------------------------------------
JOB  0&#46;0  progr&#58;     0&#46;0%    rendered on Freelance02&#46;0
JOB  0&#46;4  progr&#58;     0&#46;1%    rendered on Freelance02&#46;4

&#91;&#46;&#46;&#46;&#93;

RC   0&#46;0  info &#58; wallclock  1&#58;41&#58;01&#46;67 for rendering
RC   0&#46;0  info &#58; allocated 719 MB, max resident 733 MB
GAPM 0&#46;0  info &#58; triangle count excluding retessellation &#58;  1195294464
GAPM 0&#46;0  info &#58; triangle count including retessellation &#58;  1603373184
DB   0&#46;0  info &#58; disk swapping&#58; 0 objects &#40;0 KB&#41; swapped out in 0&#46;00 s,
DB   0&#46;0  info &#58; 0 objects &#40;0 KB&#41; swapped in in 0&#46;00 s, max swap space used 0 KB, 101406812 KB f
ailed
MEM  0&#46;1  progr&#58; scene cache flushed asynchronously 247 MB for module JOB, now&#58; 520 MB
MEM  0&#46;0  info &#58; 13647 scene cache flushes freed 99205 MB in 0&#46;14s
MSG  0&#46;0  info &#58; wallclock  1&#58;43&#58;20&#46;97 total
MSG  0&#46;0  info &#58; allocated 142 MB, max resident 733 MB

Press any key to continue &#46; &#46; &#46;

From the maya UI, I noticed mr comes back with 'mental ray out of memory, aborting' when hitting the memory limit, instead of flushing the cache and going on.

I have a hard time finding the right correlation between memory amount and task size, there does not seem to exist some general rule (there is a very general rule, but it's too general to be applicable). Mr seems to have problems when many small objects fall into the same render tile. On the other hand the render times seem to raise exponentially with smaller (4, 8..) job sizes. I havent seen much info on all this stuff yet, not getting much feedback either, which lets me assume this is not a quite common issue. I'm still grateful for sharing any experience on this.

[Osaires]

Hi Floze,

Can you explain whats the best setting to use for a heavy poly count sceen like that. i tried a few test render myself, but it's getting extreamly slow when it start flushing memory(but it is flushing at least).

how can i keep memory usage low, so i don't need to flush memory?

i'm using standalone and my sceen is 10 mil polys and with AO.

thanks

[haggi]

I had the same experience. I tried a quite simpele scene with some displacment and as soon as mr tired to flush anything, it stopped. But it worked from a batchrendering.

[Remydrh]

A few things. . .if you are running out of memory, save the file and batch from command prompt. c:\blahblah\render -r mr filename.mb If you remember to kill off Maya you dump A LOT out of RAM that's not being used. Maya and MR also seem to work with one another if you batch from inside Maya. I don't think Maya is great at saving MR if it hits a wall. Also, if you have more than 2GB of RAM on a Windows machine, be sure the boot.ini has the 3GB switch, search Microsoft Docs Online.

Next, memory map large textures using imf_copy, Maya help docs explain the process, but on Linux and MS systems, MR will just load the correct resolution and piece of the texture rather than the whole file.

Lastly, on Lamrug, look here: http://www.lamrug.org/resources/chardiags.html

Tune your settings to get the most for your money in a heavy geometry machine. And as a last result, cut up the scene and render in layers if possible. Fine Displacement is also supposed to be more memory efficient for geometry.

Hope this helps.

[floze]

The interesting thing is that the flushing works fine in rapid scanline mode.

Osaires, maybe try this thread on cgtalk if you have not already:
http://forums.cgsociety.org/showthread.php?t=353827

Remydrh, the mayabatch executable may have one big woe: it quits at 1.6GB memory allocation. It's not mental ray that crashes, it actually is maya that commits seppuku. There's a comment about this issue in the help files, and I experienced it myself again lately:

What went wrong
Troubleshoot memory exceptions
On some 32-bit machines (including Windows and Linux) virtual memory is restricted to 1.6 Gbs (or thereabouts). It doesn't matter if you have hundreds of giga-bytes of physical memory or swap, no process can grow larger than this size. Maya may encounter a memory exception and report that there is still lots of memory available.

It quits at almost exactly 1.6GB, not so in the GUI though.

[Remydrh]

Hmm, My machine has 3.5 GB and XP Pro with the 3GB switch. I have had MR approach 2GB on it's own. Not sure how far exactly but very close.

The switch forces the Windows Kernal to use 1GB instead of 2GB, freeing up to 3GB address space for other applications.

Typically, a process can access up to 2 GB of memory address space (assuming the /3GB switch was not used), with some of the memory being physical memory and some being virtual memory.

Other windows systems like the server platforms on intel chips and address up to 16GB (PAE). Is it possible Maya wasn't built with that in mind? Some software can't address the extra memory unless it was written to see it (/LARGEADDRESSAWARE). I assume standalone has that switch, but if Maya doesn't, it's toast.

http://http://msdn.microsoft.com/lib...tuning.asp

[floze]

Hmm, My machine has 3.5 GB and XP Pro with the 3GB switch. I have had MR approach 2GB on it's own. Not sure how far exactly but very close.

Hm, I had that 1.6GB limit on an AMD Opteron 64bit system; not sure if/how the CPU architecture influenced this. It only happened in batch mode anyway. In GUI mode it crashes at ~3.5GB total memory charge, thanks to the 64bit windows system. On a 32bit system I had it usually crashing at ~2.6GB total charge, means around 2GB for the maya process which aligns with your depiction.

[Remydrh]

I'm not sure, because I don't have 64-bit mental ray, but Maya batch from GUI even on a 64-bit OS might still smash just because it has no clue what to do with the extra memory.

The 3GB switch on 64-bit Windows is obsolete technically. But since Maya still runs as 32-bit and MR 3.4.5.2 is also 32-bit, they will both probably crash before 4GB because 4GB is all they ever knew in the 32-bit world. So crashing at 3.6GB on a 64-bit OS still makes sense. So I'm taking a guess that 32-bit mental ray on a 64-bit machine will still just give you a tiny help in the memory arena. You'd still need 64-bit mental ray not to crash at the same barrier.

And as a side note I made an attempt to Beta 2 test 64-bit Vista. . .it is EVIL. The OS alone swallows 600MB as a default setup and it is simply too much of a pain to tweak out the resources so far. Avoid like plague.