-P option

Help
Shwetha
2007-01-19
2013-04-25
  • Shwetha

    Shwetha - 2007-01-19

    Hello,

    I am new to Pixie. I have successfully compile Pixie 1.7.6. I am trying to use the -P option and this is the error message I get. Could anyone let me know how to use this? Without -P option, it runs ok.
    Any help is greatly appreciated.

    rndr -P:4 teapot.rib
    Connection error
    Connection error
    Connection error
    Connection error
    Timeout waiting for socket
    Cannot launch multiprocessor subprocesses

    Thanks a lot in advance,
    Shwetha

     
    • George Harker

      George Harker - 2007-01-20

      Hi Shwetha,

      That's odd.

      The rndr -P option causes Pixie to launch itself (these are the subprocesses).  These subprocesses try to connect back to the 'rndr' process you launched in order to split the render over multiple processors.

      The things that can go wrong are: the subprocesses don't launch correctly, or they can't connect back.

      Which OS are you running?

      Subprocesses failing to launch can be caused by Pixie not being on the path, or PIXIEHOME not being set correctly.

      Make sure rndr is launchable without having to specify the full path.

      Networking setup issues might cause the processes not to be able to connect back - though it's a local connection, so there would have to be something wrong with localhost setup for this to be an issue.

      In the next release of Pixie, multithreaded rendering is supported which means that one process will run with multiple threads.  This is more efficient than -P multiproc renders by several factors.  But for now, the -P should work ok if Pixie is on the path and the networking stuff is set up right (fingers crossed).

      Cheers

      George

       
    • Shwetha

      Shwetha - 2007-01-22

      Thanks George.

      The connect() system call in windows failed in rndr.cpp. Changing
      client.sin_addr.s_addr    = inet_addr( "127.0.0.1" ); seems to do the magic.

      -Shwetha

       
      • George Harker

        George Harker - 2007-01-23

        Hi Shwetha,

        Thanks for finding this.  It looks like in Win32, there's an issue with the INADDR_ANY address.  For a conformant tcp sockets implementation connect() to INADDR_ANY is supposed to attempt connections to whichever interface IP is appropriate (including loopback).  Did you also have to change the bind() or just the connect?  By the way, some firewalls and some virus detection software can interfere with tcp socket binding, but I suspect that's not the case here.

        For the next release, I've tidied up that code a little and added a second attept to INADDR_LOOPBACK (which will be inet_addr("127.0.0.1") ) if the first attempt fails. 

        That said, in most all cases, the new -t:n option which runs multithreaded rather than multiprocess will be far more efficient.  You will still get utilization of n processors but there will be less repeated work, and therefore a faster result.

        Cheers

        George

         

Log in to post a comment.