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.
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
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
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
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
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