Hi all,

I unfortunately miss that feature. I've a Linux SMP machine and would like 
to provit from it in my POV-Ray times as well ;)

I just made a picture with radiosity and it's still computing - since 3 +1/2 
hours :(((. It would be 2x faster if it would use both CPUs.

This could be implemented for example by having 2 processes with concurrent 
pixel computation. (that's how I'd implement it ;)

Thanks,
Christian Parpart.

p.s: I hope that some developers are watching to the NG.

Post a reply to this message

On Wed, 31 Jul 2002 22:45:13 +0200, Christian Parpart wrote:
> This could be implemented for example by having 2 processes with concurrent 
> pixel computation. (that's how I'd implement it ;)

Oh, well, shucks, why didn't we think of that?  It's so much easier than 
the way we were planning on doing it, where the processors vote on the colors
of all of the pixels.

-- 
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions

Post a reply to this message

Ron Parker inspired the electrons to say:
> On Wed, 31 Jul 2002 22:45:13 +0200, Christian Parpart wrote:
>> This could be implemented for example by having 2 processes with
>> concurrent pixel computation. (that's how I'd implement it ;)
> 
> Oh, well, shucks, why didn't we think of that?  It's so much easier than
> the way we were planning on doing it, where the processors vote on the
> colors of all of the pixels.

Looks interesting, but not fast enough IMO. When do you think of a first 
beta release of it? I'd beta test it (any algorithm you chose).

Well, I didn't take a look at your (old) sources yet, all I know is that 
it's written in (plain?) C and I unfortunately prefer C++ and their design 
patterns ;) But if your API to the POV-Ray Backend is clear I'd really like 
to take a look at it and write it myself.

Just note, that I'm using Linux with GCC 3.1. wo I can't produce windows 
binaries for windows testing. 

How do you think?

Greets,
Christian Parpart

p.s.: but the source isn't _still_ available.

Post a reply to this message

Christian Parpart inspired the electrons to say:
> I just made a picture with radiosity and it's still computing - since 3
> +1/2 hours :(((. It would be 2x faster if it would use both CPUs.

http://cparpart.surakware.net/public/water.png (original)
http://cparpart.surakware.net/public/water.jpeg (converted)

It really used 4 hours 38 minutes on a dual machine.
AMD AthlonMP 1500+ 2CPUs, 1GB RAM.
amazing.

Cheers,
Christian.

Post a reply to this message

On Wed, 31 Jul 2002 16:45:13 -0400, Christian Parpart quoth:

> Hi all,
> 
> I unfortunately miss that feature. I've a Linux SMP machine and would
> like to provit from it in my POV-Ray times as well ;)
> 
> I just made a picture with radiosity and it's still computing - since 3
> +1/2 hours :(((. It would be 2x faster if it would use both CPUs.
> 
> This could be implemented for example by having 2 processes with
> concurrent pixel computation. (that's how I'd implement it ;)

To give a non-sarcastic answer:
This topic comes up so often that it is mentioned both in the VFAQ and
the manual.  RTFM.

-- 
Mark

Post a reply to this message

Ron Parker wrote:
> Oh, well, shucks, why didn't we think of that?  It's so much
 > easier than the way we were planning on doing it, where the
 > processors vote on the colors of all of the pixels.

Simple majority or 2/3rds?

-- 
Tim Cook
http://empyrean.scifi-fantasy.com
mirror: http://personal.lig.bellsouth.net/lig/z/9/z993126

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

On Wed, 31 Jul 2002 22:57:26 -0500, Timothy R. Cook wrote:

> Ron Parker wrote:
>> Oh, well, shucks, why didn't we think of that?  It's so much
>  > easier than the way we were planning on doing it, where the
>  > processors vote on the colors of all of the pixels.
> 
> Simple majority or 2/3rds?
 
And if one of the CPUs is really offended by a color, can it be blocked
in committee and prevented from ever coming to a floor vote?

And what about filibusters?

I'm starting to understand why this hasn't been implemented.  It sounds
very complicated.  Just the task of implementing Robert's Rules of Order
would be overwhelming.

Post a reply to this message

"Christian Parpart" <cpa### [at] surakwarenet> wrote in message
news:3d484c5a@news.povray.org...
> I just made a picture with radiosity and it's still computing - since 3
+1/2
> hours :(((. It would be 2x faster if it would use both CPUs.

Only 3 1/2?  I can make a reflective sphere over a checkered plane take that
long to render, w/o radiosity :)

...Chambers

Post a reply to this message

On Wed, 31 Jul 2002 22:45:13 +0200, Christian Parpart <cpa### [at] surakwarenet>
wrote:
> p.s: I hope that some developers are watching to the NG.

Please spend some time:
- reading documentation
- digging newsgroups
- searching website
all at povray.org.
Your a few years long working with pov means
nothing when you are asking such questions.

This is really serious advice. IIRC I have spend more than
year reading all important groups. Then I send first post.
There goes a big knowledge follow pov-community. Don't waste
their time if they already answered many of question.

ABX

Post a reply to this message

"Ed Jackson" <eja### [at] iastateedu> wrote in message
news:pan### [at] iastateedu...
> And if one of the CPUs is really offended by a color, can it be blocked
> in committee and prevented from ever coming to a floor vote?

Well, as you know, the colors must all be politically correct, these rules
are difficult to express in algorithms (as they seem to change every few
months).

-- Chris

Post a reply to this message