non-realtime cpu issues (using render_node)


    Mar 30 2006 | 8:52 pm
    I am using Randy Jones his render_node patch to render some video's. It switches max to non-realtime to render every frame. The problem is max/jitter takes a very long time to render things that it can do in realtime. I have a jitter patch running at about 60% cpu usage in realtime. When I start recording it, it records at about 1 fps. The example patch that comes with render_node is showing the same behavior.
    The weird thing is that max itself shows 100% cpu usage, while my taskmanager shows its doing almost nothing. The max interface is jammed like it would be at 100%, but I can keep on using other programs without problems. My computer even turns on its screensaver after a while, and it doesn't interfere with anything.
    I stripped down the patch to where its basically only rendercontext -> to_texture -> jit.qt.record, bypassing the frame accumulations and plugins, but without luck. Also the movie size and codec doesn't make much of a difference. Rendering 320x240 raw against 800x600 jpeg, still about 1fps.
    I also tried changing the dsp settings. As far as I know Randy doesn't know what's up either, and I suppose its the same on mac as it is on my windows system. I'm wondering if someone can tell me something relevant about this realtime mode. Am I missing something? Does anyone have similar experience with non-realtime mode?
    I recently had to wait for 3 hours to render a 4,5min movie :-/
    Thijs

    • Mar 30 2006 | 9:21 pm
      On Mar 30, 2006, at 12:52 PM, Thijs Koerselman wrote:
      > I also tried changing the dsp settings. As far as I know Randy > doesn't know what's up either, and I suppose its the same on mac as > it is on my windows system. I'm wondering if someone can tell me > something relevant about this realtime mode. Am I missing > something? Does anyone have similar experience with non-realtime mode?
      Well sfplay~ and sfrecord in NRT mode perform synchronous disk access and are *quite* slow as a result. NRT mode is primarily in place for us to debug MSP objects, and though it is useful for tasks like this, it doesn't warrant the considerable oevrhaul that would be necessary to speed up sfplay~ and sfrecord~ in this case. The work around is to record into a buffer~ with record~ and then export the buffer~ to AIFF at the final stage. I guarantee that this will be noticably faster than using sfplay~/sfrecord~ in NRT mode (and I believe this is floating around the maxmsp mailing list archives somewhere.
      I have a hunch that this is where your bottleneck lies, but if not, keep stripping your patch down, disabling MSP and DSP in NRT, etc. until you come to a conclusion as to where the precise bottleneck lies. Shark (part of Apple's excellent CHUD tools, downloadable from their developer site) may prove useful for determining what is taking the performance hit, though it can be misleading in situations where MaxMSP is spending all it's time waiting on synchronous disk I/O (and thus not showing up much in the process monitor or in shark).
      Good luck.
      -Joshua
    • Mar 30 2006 | 9:36 pm
    • Mar 30 2006 | 9:39 pm
      On Mar 30, 2006, at 3:52 PM, Thijs Koerselman wrote:
      > I recently had to wait for 3 hours to render a 4,5min movie :-/
      while i haven't had time to check out render_node yet ,this is not unusual for off-line rendering in general. a lot of my work entails the use of high end compositing programs like after effects where several seconds of hi-rez video can take hours. cheers bruce
      bruce tovsky www.skeletonhome.com
      "Reality is whatever refuses to go away when I stop believing in it.." Philip K. Dick
    • Mar 30 2006 | 10:05 pm
      Thanks!! I just deleted the audio recording part, and it's rendering in realtime speed now :-) x30 speed up! Awesome. I read about this in the archives just after posting my mail... stupid me.
      Best, T_
    • Apr 01 2006 | 5:17 pm
      M/M/J has not yet been released for the new Intel Macs.
      best, dan