I'm a little bit confused about rpiece and multiple processors. So
rpiece can take rpict arguments, and -PP is an rpict argument telling
it to fork as necessary, is it a good idea to pass that along to
rpiece?
Out of curiosity, I tried running enough rpiece -PP commands for each
processor and wound up with a bunch of rpieces running but only one of
those had rpicts that were actually doing anything. Additionally, I
think rpict thought it as doing a sequence of frames. The images
appear to be rendering, but is this the proper method? Are rpict -PP
and rpiece mutually exclusive on platforms that support both?
Thanks in advance,
--Dave
P.S. - Here's the process tree from htop:
`[...two more rpiece's like the first two below]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -S 1 -PP pp -w -i [...]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -S 1 -PP pp -w -i [...]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -PP pp -w -i [...]
`- rpict -PP pp -w -i [...]
Hi Dave,
Rpiece calls on rpict to render "pieces" of the image as determined by rpiece. So in other words, you do not start rpiece and then start rpict, this is what rpiece does for you. Looking at what you have provided, I have to surmise that you are not telling rpiece to divide the view up. In order to do this you need to provide rpiece with -X <divisions in X> -Y <divisions in Y>, so for example -X 2 -Y 2 would divide the image into a 2x2 matrix. We do not know what your other arguments are so it is hard to tell if other things are missing. It might help if you could provide the the full command line that you are using to run the job.
-Jack
David Smith wrote:
···
I'm a little bit confused about rpiece and multiple processors. So
rpiece can take rpict arguments, and -PP is an rpict argument telling
it to fork as necessary, is it a good idea to pass that along to
rpiece?
Out of curiosity, I tried running enough rpiece -PP commands for each
processor and wound up with a bunch of rpieces running but only one of
those had rpicts that were actually doing anything. Additionally, I
think rpict thought it as doing a sequence of frames. The images
appear to be rendering, but is this the proper method? Are rpict -PP
and rpiece mutually exclusive on platforms that support both?
Thanks in advance,
--Dave
P.S. - Here's the process tree from htop:
`[...two more rpiece's like the first two below]
>
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
> `- rpict -S 1 -PP pp -w -i [...]
> `- rpict -S 1 -PP pp -w -i [...]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
> `- rpict -S 1 -PP pp -w -i [...]
> `- rpict -S 1 -PP pp -w -i [...]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -PP pp -w -i [...]
`- rpict -PP pp -w -i [...]
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
One clarification on this. While rpiece does manage calling rpict, you DO need to call rpiece for however many jobs you want to run on your machine. Thus if you have 4 cores on the machine you would fire off 4 copies of the rpiece command line.
-Jack
Jack de Valpine wrote:
···
Hi Dave,
Rpiece calls on rpict to render "pieces" of the image as determined by rpiece. So in other words, you do not start rpiece and then start rpict, this is what rpiece does for you. Looking at what you have provided, I have to surmise that you are not telling rpiece to divide the view up. In order to do this you need to provide rpiece with -X <divisions in X> -Y <divisions in Y>, so for example -X 2 -Y 2 would divide the image into a 2x2 matrix. We do not know what your other arguments are so it is hard to tell if other things are missing. It might help if you could provide the the full command line that you are using to run the job.
-Jack
David Smith wrote:
I'm a little bit confused about rpiece and multiple processors. So
rpiece can take rpict arguments, and -PP is an rpict argument telling
it to fork as necessary, is it a good idea to pass that along to
rpiece?
Out of curiosity, I tried running enough rpiece -PP commands for each
processor and wound up with a bunch of rpieces running but only one of
those had rpicts that were actually doing anything. Additionally, I
think rpict thought it as doing a sequence of frames. The images
appear to be rendering, but is this the proper method? Are rpict -PP
and rpiece mutually exclusive on platforms that support both?
Thanks in advance,
--Dave
P.S. - Here's the process tree from htop:
`[...two more rpiece's like the first two below]
>
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
> `- rpict -S 1 -PP pp -w -i [...]
> `- rpict -S 1 -PP pp -w -i [...]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
> `- rpict -S 1 -PP pp -w -i [...]
> `- rpict -S 1 -PP pp -w -i [...]
`- rpiece -v -PP pp -F syncfile @viewpoint @options @arguments
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -S 1 -PP pp -w -i [...]
`- rpict -PP pp -w -i [...]
`- rpict -PP pp -w -i [...]
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction
Jack,
The shell script I used is below, adapted from Mark Stock's reference
code. It runs rpiece -PP four times, each calling corresponding
rpicts, but the fourth rpiece/rpict instance is the only one where the
rpict does anything. From what I can tell, the rpict from the last
rpiece will fork and take over any available cores (making NCPU rpicts
for this rpiece, two rpicts for the other rpieces), leaving the rpict
instances of the other rpieces useless. That doesn't seem like the
right way to go about breaking up a picture, it seems like there are 4
rpicts but they are only working one segment of the 8x8 grid at a
time.
I guess what I'm asking is this: Aside from the order in which the
picture gets processed, does rpiece x 4 == rpict -PP ?
--Dave
···
----------------------
NCPU=4
COLS=8
ROWS=8
echo "-vf 6.vf" > viewpoint
echo "-w -i -bv -ab 4 -ar 128 -ad 1024 -as 512 -aa 0.15 -av 0.0 0.0
0.0 -aw 0 -lr -10 -lw 0.004 -x 2048 -y 2048 -af ambfile -ps 1 -ds .1
-dj .6 -t 120" > options
echo "-o smp.unf model.oct" > arguments
echo $COLS $ROWS > syncfile
rm -f pp
while [ "$NCPU" -gt 0 ]
do
echo "running proc $NCPU"
rpiece -v -PP pp -F syncfile @viewpoint @options @arguments &
NCPU=`expr $NCPU - 1`
done
wait
Hi Dave,
The -PP switch is to enable a basic level of memory sharing on a multi-cpu or multi-core host, that is, sharing of memory among multiple processes running on the same host. If you choose not to use -PP then each process will use its own memory space.
Rpiece is tricky. I believe that there is actually some kind of race or deadlock condition that can occur when processes are started up one right after another. Unfortunately, I have not been able to diagnose this is a sufficient way to pass along. I would suggest either one of the following modifications to the script:
OPTION 1:
NCPU=4
COLS=8
ROWS=8
echo "-vf 6.vf" > viewpoint
echo "-w -i -bv -ab 4 -ar 128 -ad 1024 -as 512 -aa 0.15 -av 0.0 0.0 0.0 -aw 0 -lr -10 -lw 0.004 -x 2048 -y 2048 -af ambfile -ps 1 -ds .1 -dj .6 -t 120" > options
echo "-o smp.unf model.oct" > arguments
echo $COLS $ROWS > syncfile
rm -f pp
while [ "$NCPU" -gt 0 ]
do
echo "running proc $NCPU"
rpiece -v -PP pp -F syncfile @viewpoint @options @arguments &
NCPU=`expr $NCPU - 1`
sleep 2
done
wait
OPTION 2:
NCPU=4
COLS=8
ROWS=8
echo "-vf 6.vf" > viewpoint
echo "-w -i -bv -ab 4 -ar 128 -ad 1024 -as 512 -aa 0.15 -av 0.0 0.0 0.0 -aw 0 -lr -10 -lw 0.004 -x 2048 -y 2048 -af ambfile -ps 1 -ds .1 -dj .6 -t 120" > options
echo "-o smp.unf model.oct" > arguments
#echo $COLS $ROWS > syncfile
rm -f syncfile
rm -f pp
while [ "$NCPU" -gt 0 ]
do
echo "running proc $NCPU"
rpiece -X $COLS -Y $ROWS -v -PP pp -F syncfile
@viewpoint @options @arguments &
NCPU=`expr $NCPU - 1`
sleep 2
done
wait
-Jack
David Smith wrote:
···
Jack,
The shell script I used is below, adapted from Mark Stock's reference
code. It runs rpiece -PP four times, each calling corresponding
rpicts, but the fourth rpiece/rpict instance is the only one where the
rpict does anything. From what I can tell, the rpict from the last
rpiece will fork and take over any available cores (making NCPU rpicts
for this rpiece, two rpicts for the other rpieces), leaving the rpict
instances of the other rpieces useless. That doesn't seem like the
right way to go about breaking up a picture, it seems like there are 4
rpicts but they are only working one segment of the 8x8 grid at a
time.
I guess what I'm asking is this: Aside from the order in which the
picture gets processed, does rpiece x 4 == rpict -PP ?
--Dave
----------------------
NCPU=4
COLS=8
ROWS=8
echo "-vf 6.vf" > viewpoint
echo "-w -i -bv -ab 4 -ar 128 -ad 1024 -as 512 -aa 0.15 -av 0.0 0.0
0.0 -aw 0 -lr -10 -lw 0.004 -x 2048 -y 2048 -af ambfile -ps 1 -ds .1
-dj .6 -t 120" > options
echo "-o smp.unf model.oct" > arguments
echo $COLS $ROWS > syncfile
rm -f pp
while [ "$NCPU" -gt 0 ]
do
echo "running proc $NCPU"
rpiece -v -PP pp -F syncfile @viewpoint @options @arguments &
NCPU=`expr $NCPU - 1`
done
wait
_______________________________________________
Radiance-general mailing list
[email protected]
http://www.radiance-online.org/mailman/listinfo/radiance-general
--
# Jack de Valpine
# president
#
# visarc incorporated
# http://www.visarc.com
#
# channeling technology for superior design and construction