"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

Chris Cason wrote:
> "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).

perhaps something involving a little MathML would help, we should set up a
steering commitee....


--
Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.377 / Virus Database: 211 - Release Date: 15/07/2002

Post a reply to this message

Christian Parpart <cpa### [at] surakwarenet> wrote in
news:3d484c5a@news.povray.org 

[...]

Stupid question... why not just :

CPU-1 render lines 0..160
CPU-2 render lines 160..320

etc ?

or CPU-1 render every n*2 pixel, and CPU-2 (n*2)+1 pixel in each line

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in 
news:Xns### [at] 204213191226

> CPU-1 render lines 0..160
> CPU-2 render lines 160..320

renders can be run as completly separate thread's (like running 2 copys of 
POV at once, each on diffrent CPU). Disadvantage is duplicating memory, and 
dual parsing for each process.

Second solution is :
  Parsing scene - only one CPU
  Shooting photons - one CPU, 
    or give 1-st, 3,5 light-source to 1-CPU and
    2,3,6 to 2-CPU, and/or do same with target objects
  Sorting Photons - there probably are algorithms for sorting on 2-CPU's
  Radiosity pre-trace - not shure, maybe divide scene into separate pixels, 
  as in Render step
  Render - give half pixels to one CPU, and half to others, run both 
renders as separate threads tahat will share memory with 
Photons/Vista/Scene/etc data

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

On 1 Aug 2002 09:20:35 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Stupid question... 

http://www.povray.org/search/?s=multiple+processors

ABX

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote in message
news:Xns### [at] 204213191226...
> Christian Parpart <cpa### [at] surakwarenet> wrote in
> news:3d484c5a@news.povray.org
>
> [...]
>
> Stupid question... why not just :
>
> CPU-1 render lines 0..160
> CPU-2 render lines 160..320
>

I think this is what some people do - obviously it depends on scenes where the
render time is the issue, rather than parse time. With radiosity, it all gets
more complicated.

Question: Do photons break this method, or are they more "fixed" than radiosity?
(I assume the latter).

Post a reply to this message

ABX wrote:
>> Stupid question...
>
> http://www.povray.org/search/?s=multiple+processors

not a stupid question, a very valid and *required* feature


--
Rick

Kitty5 WebDesign - http://Kitty5.com
POV-Ray News & Resources - http://Povray.co.uk
TEL : +44 (01270) 501101 - FAX : +44 (01270) 251105 - ICQ : 15776037

PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA

Post a reply to this message

Rick [Kitty5] wrote:

> ABX wrote:
> 
>>>Stupid question...
>>>
>>http://www.povray.org/search/?s=multiple+processors
>>
> 
> not a stupid question, a very valid and *required* feature
> 
Which has been answered from a long time already.

For the technically minded, you "just" have to rewrite the
rendering engine so that no global/static variable is used with
write/modify access. The bad news is that it is only the first
step, and that there is a lot of such variable/arrays,
specially as optimisation of some patterns and computation
of shadow & reflection.

The following steps introduce non-portability unless

you restrict portability to something like Posix thread
compliant systems (or whatever you choose for multiple processors).
Anyway, it is bad...

Post a reply to this message