![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Interesting, though I'm not sure that it really saves me much work since the
more difficult thing is farming out rendering of *different* sections of the
scene...
In fact, what I'd want would be a way to execute pov remotely on a linux machine
by invoking it from my windows machine.
--
Tek
www.evilsuperbrain.com
"Patrick Elliott" <sha### [at] hotmail com> wrote in message
news:MPG.1acfe5462ad64919899fa@news.povray.org...
> Hmm. just had a thought.. There is a program called Synergy out that lets
> you control two networked machines with the same keyboard and mouse.
> There is an article on TechTV about it at:
>
> http://www.techtv.com/screensavers/downloadoftheday/story/0,24330,3647418
> ,00.html
>
> This might actually make managing two or more machines easier. It runs on
> both Windows and Linux. Haven't tried it myself, but then I haven't got
> anything networked to try it with. It definitely looked interesting
> though.
>
> --
> void main () {
> call functional_code()
> else
> call crash_windows();
> }
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> This is true for the *CPU*. However, it's not the CPU which handles
> the floating point code, but the FPU.
> The FPU is completely separate from the CPU. The FPU has eight 80-bit
Well, you seems to mix CPU and ALU:
ALU stands for Arithmetic and Logic Unit. It is the part of the chip
that compute on integers.
The ALU and the FPU are separate, but are both inside the CPU.
> registers and it performs all floating point operations on them. I don't
> know, however, if the FPU is able to load 64 and 80-bit floats directly
> from memory, but I wouldn't be surprised if it could (actually I'm not
> sure how wide the memory bus is in athlons, but I would be surprised
> if it was narrower than 64 bits).
Well, to know this for sure, we'll have to find an assembler programmer
which will be able to say if it is possible to load one of the FPU
register directly from the cache in the same number of cycles the other
registers do.
If so, then the speed difference between the Athlon-XP and the Athlon-64
is partly (they can also have improved the FPU unit...) because the last
one can use ALL the registers to store 64 bits data, instead of the
lower number of FPU registers and then require the cache, which is slower.
Regards,
--
Laurent ARTAUD (lau### [at] free fr)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Tek wrote:
> But I thought POV doesn't support dual CPUs?
>
Running POV-Ray on a multiprocessor system would be the same as running
on several independent machines - you would start several render
processes for using all available processors.
--
Christoph Hormann
http://www.tu-bs.de/~y0013390/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Tek wrote:
>
> That's true if I follow the philosophy of running seperate instances of pov on
> seperate machines, but surely it would be possible to modify POV to run in some
> multi-threaded configuration (say with each ray on a seperate thread) which
> could then be farmed out to the different processors?
>
> Has anyone attempted such a thing? Is there software/OS's available that will
> let a network of PCs emulate a multi-processor system? I confess I've never
> programmed anything like that and I've never looked at POV's source, so I'd be
> very curious to know how difficult it would be to do something like that.
This has been discussed a lot already - first of all a use of
multithreading inside POV-Ray will not have any significant advantage
for distributed renders on a cluster of several machines - even if you
use a system emulating a single multiprocessor machine the communication
overhead would require a completely different design than on a true SMP
machine (and you would have the same trouble with techniques that are
difficult to parallelize as with an external implementation).
But much more important is that there is no way to implement
multithreading in a portable manner - not even for the three 'official'
platforms. So if you want to attempt implementing such a system (which
would be pretty hard on the current POV-Ray source anyway) you would
have to implement several platform specific variants.
--
Christoph Hormann
http://www.tu-bs.de/~y0013390/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christoph Hormann wrote:
> Running POV-Ray on a multiprocessor system would be the same as running
> on several independent machines - you would start several render
> processes for using all available processors.
And hope your not using radioasity....
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> But I thought POV doesn't support dual CPUs?
It doesn't, but you will be able to render 2 halfs of an image (depending on
image) or 2 images, or render on one cpu and still be able to use the PC as
normal.
--
Rick
Kitty5 NewMedia http://Kitty5.com
POV-Ray News & Resources http://Povray.co.uk
TEL : (+44) 0845 1083740 - ICQ : 15776037
PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Yes, I get the point now. If I'm going for a multi-PC system it's actually
cheaper to have half as many PCs all with dual processors. That's some good
advice and I'm currently checking the online shops to figure out where the sweet
spot is between speed and money :)
--
Tek
www.evilsuperbrain.com
"Rick [Kitty5]" <ric### [at] kitty5 com> wrote in message
news:4066a47c@news.povray.org...
> > But I thought POV doesn't support dual CPUs?
>
> It doesn't, but you will be able to render 2 halfs of an image (depending on
> image) or 2 images, or render on one cpu and still be able to use the PC as
> normal.
>
> --
> Rick
>
> Kitty5 NewMedia http://Kitty5.com
> POV-Ray News & Resources http://Povray.co.uk
> TEL : (+44) 0845 1083740 - ICQ : 15776037
>
> PGP Public Key : http://pgp.kitty5.com
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
laurent.artaud[AT]free.fr <"laurent.artaud[AT]free.fr"> wrote:
> > This is true for the *CPU*. However, it's not the CPU which handles
> > the floating point code, but the FPU.
> > The FPU is completely separate from the CPU. The FPU has eight 80-bit
> Well, you seems to mix CPU and ALU:
No, I'm not. We were discussing whether the FPU can handle chunks of
data larger than 32 bits. You claimed that the *FPU* of Athlon XP can't
because it's internally 32-bit. I casted doubt about this. As an argument
you said that the CPU and the ALU of Athlon XP is 32 bits architecture.
I commented that the FPU has nothing to do with those.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Among other things, "laurent.artaud[AT]free.fr" wrote:
>>>Even if the Athlon-XP's FPU is able to use 64 bits double precision
>>>floats
>>
>> What do you mean "if"?
>
> Ah?
> Sorry, I'm not a native English speaker, so I may have used the wrong
> saying.
> I was NOT trying to say that I do not think the FPU able to work on 64
> bits double precision floats. In fact, I KNOW that it can work on 80
> bits long double floats, as any x87 compatible FPU must.
Maybe "Even though the Athlon-XP's FPU ..." would be more appropriate? :)
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> No, I'm not. We were discussing whether the FPU can handle chunks of
> data larger than 32 bits. You claimed that the *FPU* of Athlon XP can't
> because it's internally 32-bit. I casted doubt about this. As an argument
Well, re-read my posts: I _NEVER_ SAID THAT THE _FPU_ WAS 32 BITS!
--
Laurent ARTAUD (lau### [at] free fr)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |