 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Consider the following code;
// A first try at a "Simple eroder"
#version 3.7;
global_settings {
ambient_light 0
adc_bailout 0.09
max_trace_level 200
noise_generator 3
assumed_gamma 1.0
}
#include "shapes.inc"
#declare WindDirection = -1;
#declare Particles = frame_number*50;
#declare ParticleRandom = seed(1);
#declare ParticleSize = seed(1);
// A simple column object
#declare Object = union {
cone {<0, 12, 0>, 6, <0, 50, 0>, 3}
#for (CC, 0, 8)
cylinder {<-6, 12, 0>, <-3, 50, 0>, 0.5 rotate y * CC * 45}
#end
torus {6, 1 translate y * 12}
torus {7, 1 translate y * 11}
torus {8, 1 translate y * 10}
Round_Box_Union(<-10,-10,-10>, < 10, 10, 10>, 1)
}
#declare Max = max_extent(Object);
#declare Min = min_extent(Object);
#macro Damage()
#local Hit = false;
#while (Hit = false)
// #local ParticleOrigin = <0, 0, 0>;
#local ParticleOriginX = -WindDirection * 1000;
#local ParticleOriginY = Min.y + (Max.y - Min.y) * rand(ParticleRandom);
#local ParticleOriginZ = Min.z + (Max.z - Min.z) * rand(ParticleRandom);
#local ParticleOrigin = < ParticleOriginX, ParticleOriginY,
ParticleOriginZ>;
#local PointOfImpact = trace(Object, ParticleOrigin, <-1,0,0>);
#if (vlength(PointOfImpact) > 0)
#local Hit = true;
#end
#end
sphere{PointOfImpact, (1 + rand(ParticleSize))/10}
#end
#macro Erode(ObjectToErode)
#for (ParticleCount, 0, Particles, 1)
#declare ObjectToErode =
difference {
object { ObjectToErode }
Damage()
}
#end
ObjectToErode
#end
#macro Erode1(ObjectToErode)
#declare ObjectToErode =
difference {
object { ObjectToErode }
#for (ParticleCount, 0, Particles, 1)
Damage()
#end
}
ObjectToErode
#end
object {Erode(Object) pigment {rgb 1}}
camera {
location < 100, 60, 100>
look_at <0,20, 0>
direction z * 2.0
right image_width / image_height * x
}
light_source {< 400, 1000, 500>*10, color 1.0 }
light_source {< -400, 1000, 500>*10, color 0.125 rotate y * 120 shadowless}
light_source {< -400, 1000, 500>*10, color 0.125 rotate y * -120 shadowless}
// End code
If I use the first Erode macro, the proc runs nicely with all cores at 100%
and at normal work temp. When I otoh the Erode1 macro use, the parse times
are obviously much shorter but the processor get way too hot when tracing
the image.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.04.2013 00:38, schrieb Ger:
>
> If I use the first Erode macro, the proc runs nicely with all cores at 100%
> and at normal work temp. When I otoh the Erode1 macro use, the parse times
> are obviously much shorter but the processor get way too hot when tracing
> the image.
"100% CPU load" does not mean that the CPU actually runs at its full
potential - it only means that the CPU is constantly busy in /some/ way,
whether it is actually computing stuff or just waiting for the main
memory to deliver data.
The simpler your scene is, the less memory it takes as a whole, and
therefore the more of it can be kept in the CPU caches; as a result, the
CPU spends more time doing actual work than waiting for main memory
operations to complete.
A well-designed computer should be ok even at full throttle. However,
not all computers are well-designed with respect to thermal management,
and POV-Ray has a habit of making the CPU sweat like no other application.
If you are worried that your CPU might overheat, the most obvious
solution is to reduce the number of work threads.
Note that the maximum thermal limit varies between different CPUs. There
are also huge differences in what happens when the limit is exceeded:
Current Intel CPUs are known to handle thermal issues very graciously,
being designed to automatically throttle their performance (or in the
worst case simply halt themselves entirely) before reaching fatal core
temperatures. In contrast, AMD CPUs have a reputation for failing
catastrophically and suffering permanent damage.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Am 02.04.2013 00:38, schrieb Ger:
>>
>> If I use the first Erode macro, the proc runs nicely with all cores at
>> 100% and at normal work temp. When I otoh the Erode1 macro use, the parse
>> times are obviously much shorter but the processor get way too hot when
>> tracing the image.
>
> "100% CPU load" does not mean that the CPU actually runs at its full
> potential - it only means that the CPU is constantly busy in /some/ way,
> whether it is actually computing stuff or just waiting for the main
> memory to deliver data.
If you look at the code then you'll see that in both cases the object in
view is something like
difference {
union {
box {}
cone {}
torus{}
}
50 x frame_number // for each iteration the same
sphere{}
}
The big difference is how the placement of the little spheres is calculated
during parse time. And as povray only uses 1 core when parsing a piece of
code it won't overheat the processor.
>
> The simpler your scene is, the less memory it takes as a whole, and
> therefore the more of it can be kept in the CPU caches; as a result, the
> CPU spends more time doing actual work than waiting for main memory
> operations to complete.
Shouldn't matter here because in both cases the object data is the same.
>
> A well-designed computer should be ok even at full throttle. However,
> not all computers are well-designed with respect to thermal management,
> and POV-Ray has a habit of making the CPU sweat like no other application.
True, but beside the point.
>
> If you are worried that your CPU might overheat, the most obvious
> solution is to reduce the number of work threads.
Obvious, but not true. Even running on only 2 cores the processor gets
significantly hotter when using the Erode1 macro
>
> Note that the maximum thermal limit varies between different CPUs. There
> are also huge differences in what happens when the limit is exceeded:
> Current Intel CPUs are known to handle thermal issues very graciously,
> being designed to automatically throttle their performance (or in the
> worst case simply halt themselves entirely) before reaching fatal core
> temperatures. In contrast, AMD CPUs have a reputation for failing
> catastrophically and suffering permanent damage.
Also very true, but equally beside the point.
I'm not worried that my processor will overheat, it won't. What I'm trying
to find out how that little change in the code can make such a large
difference in core temperature. iow, processor load.
The main difference between the 2 code segments is that in the first I
difference 1 sphere from an object and declare that as the new object and do
the next difference and so on until I have differenced 1000's of spheres
from the original object. In the second code segment I difference 1000's of
spheres from the original object in one big swoop
Btw, I forgot to mention;
Povray 3.7 RC7 running on an AMD FX8-core with Opensuse 12.3
And as an added test I ran the same code on
AMD X64 dual core and an Intel Quad core with the same results. Both with
the same OS and Povray version.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> The simpler your scene is, the less memory it takes as a whole, and
>> therefore the more of it can be kept in the CPU caches; as a result, the
>> CPU spends more time doing actual work than waiting for main memory
>> operations to complete.
>
> Shouldn't matter here because in both cases the object data is the same.
I don't think the object data is the same, in one case you have a
difference object with N+1 child objects, in the other one you have N
nested difference objects, each with 2 objects.
My suspicion is the nested objects cause a lot more "memory" type work
for the processor during rendering (reading pointers, transform data
etc) and as such even though the CPU is at "100%" it's having an easy
time waiting for slow memory operations to complete.
How do the CPU temperatures vary as you change the number of particles -
are they much closer with just 1 or 2 particles?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.04.2013 08:45, schrieb Ger:
>
> If you look at the code then you'll see that in both cases the object in
> view is something like
>
> difference {
> union {
> box {}
> cone {}
> torus{}
> }
> 50 x frame_number // for each iteration the same
> sphere{}
> }
>
Nope; the code the Erode macro generates is
difference {
difference {
difference {
object { ObjectToErode }
sphere {}
}
sphere {}
}
sphere {}
}
whereas the code the Erode1 macro generates is
difference {
object { ObjectToErode }
sphere {}
sphere {}
sphere {}
}
Note that POV-Ray doesn't collapse nested differences into a single one
(although it would probably be a good idea).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 02/04/2013 7:45 AM, Ger wrote:
> I'm not worried that my processor will overheat, it won't.
In case anyone else sees the subject and thinks that it might be
relevant to them as their processor overheats when rendering.
My laptop was shutting itself down when I was using SSL as it was
overheating. (The problem was a broken fan blade trapped inside the fan.)
I found an application called TThrottle which throttles the CPU when a
set CPU or GPU temperature is reached.
http://efmer.eu/boinc/
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <ger### [at] gmail com> wrote:
> When I otoh the Erode1 macro use, the parse times
> are obviously much shorter but the processor get way too hot when tracing
> the image.
Yes, there's a super-secret function in povray that instructs the CPU to
raise its temperature.
Seriously though, CPU temperatures are really not a problem of applications
(especially not compute-intensive ones.) If your CPU gets too hot, it's a
problem with your hardware. There may be several causes for that, such as:
- The CPU is not getting enough ventilation. This may be caused by poor
chasis design, or not having enough fans (or them having been installed
in the wrong places.)
- The CPU might not be getting enough ventilation because of too much dust
on its heatsink. You should check that.
- Wrong BIOS settings can cause the CPU fan to either spin too slowly
(causing overheat) or too fast (causing fan noise that's way louder
than it has to be.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>Warp on date 02/04/2013 16.43 wrote:
> Ger <ger### [at] gmailcom> wrote:
>> When I otoh the Erode1 macro use, the parse times
>> are obviously much shorter but the processor get way too hot when tracing
>> the image.
>
> Yes, there's a super-secret function in povray that instructs the CPU to
> raise its temperature.
>
> Seriously though, CPU temperatures are really not a problem of applications
> (especially not compute-intensive ones.) If your CPU gets too hot, it's a
> problem with your hardware. There may be several causes for that, such as:
>
> - The CPU is not getting enough ventilation. This may be caused by poor
> chasis design, or not having enough fans (or them having been installed
> in the wrong places.)
>
> - The CPU might not be getting enough ventilation because of too much dust
> on its heatsink. You should check that.
>
> - Wrong BIOS settings can cause the CPU fan to either spin too slowly
> (causing overheat) or too fast (causing fan noise that's way louder
> than it has to be.)
>
Even a power supply not enough accurate in current erogation can cause a
raise of processor temperature.
Paolo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Ger <ger### [at] gmailcom> wrote:
>> When I otoh the Erode1 macro use, the parse times
>> are obviously much shorter but the processor get way too hot when tracing
>> the image.
>
> Yes, there's a super-secret function in povray that instructs the CPU to
> raise its temperature.
I knew it :)
>
> Seriously though, CPU temperatures are really not a problem of
> applications (especially not compute-intensive ones.) If your CPU gets too
> hot, it's a problem with your hardware. There may be several causes for
> that, such as:
>
> - The CPU is not getting enough ventilation. This may be caused by poor
> chasis design, or not having enough fans (or them having been installed
> in the wrong places.)
>
> - The CPU might not be getting enough ventilation because of too much dust
> on its heatsink. You should check that.
>
> - Wrong BIOS settings can cause the CPU fan to either spin too slowly
> (causing overheat) or too fast (causing fan noise that's way louder
> than it has to be.)
>
All true and all known to me (I have build and sold computers for ~15
years). But this still leaves the question why a small change in code can
raise the temperature of the cpu
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Am 02.04.2013 08:45, schrieb Ger:
>>
>> If you look at the code then you'll see that in both cases the object in
>> view is something like
>>
>> difference {
>> union {
>> box {}
>> cone {}
>> torus{}
>> }
>> 50 x frame_number // for each iteration the same
>> sphere{}
>> }
>>
>
> Nope; the code the Erode macro generates is
>
> difference {
> difference {
> difference {
> object { ObjectToErode }
> sphere {}
> }
> sphere {}
> }
> sphere {}
> }
>
> whereas the code the Erode1 macro generates is
>
> difference {
> object { ObjectToErode }
> sphere {}
> sphere {}
> sphere {}
> }
>
True, I stand corrected.
> Note that POV-Ray doesn't collapse nested differences into a single one
> (although it would probably be a good idea).
I have looked at the source code to find out as to what might possibly cause
this, but it's several miles beyond my knowledge of code. (I don't go much
further then "hello world")
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>>> The simpler your scene is, the less memory it takes as a whole, and
>>> therefore the more of it can be kept in the CPU caches; as a result, the
>>> CPU spends more time doing actual work than waiting for main memory
>>> operations to complete.
>>
>> Shouldn't matter here because in both cases the object data is the same.
>
> I don't think the object data is the same, in one case you have a
> difference object with N+1 child objects, in the other one you have N
> nested difference objects, each with 2 objects.
True, as clipka pointed out to me.
>
> My suspicion is the nested objects cause a lot more "memory" type work
> for the processor during rendering (reading pointers, transform data
> etc) and as such even though the CPU is at "100%" it's having an easy
> time waiting for slow memory operations to complete.
>
> How do the CPU temperatures vary as you change the number of particles -
> are they much closer with just 1 or 2 particles?
Don't know yet, but I'll try and test it a little later today.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 02.04.2013 19:20, schrieb Ger:
>> Note that POV-Ray doesn't collapse nested differences into a single one
>> (although it would probably be a good idea).
>
> I have looked at the source code to find out as to what might possibly cause
> this, but it's several miles beyond my knowledge of code. (I don't go much
> further then "hello world")
Well, the thing that causes that nested differences aren't collapsed
into a single one is the /absence/ of code to effect the collapsing, so
no surprise you didn't find anything :-P
It probably would have to go in the parsing code for CSG objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
>
> Well, the thing that causes that nested differences aren't collapsed
> into a single one is the /absence/ of code to effect the collapsing, so
> no surprise you didn't find anything :-P
>
> It probably would have to go in the parsing code for CSG objects.
Well, I'm not going to try and patch the povray sources. That's beyond my
level. :)
What I did however is store the differenced spheres in a text file and later
#include that. Doing it this way you don't have the nested differences
anymore and that has a huge impact on the render time. 7 seconds against
1:36 minutes.
As it turns out (from what I can determine) povray spends a lot of time
handling the nested differences.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> A well-designed computer should be ok even at full throttle. However,
> not all computers are well-designed with respect to thermal management,
> and POV-Ray has a habit of making the CPU sweat like no other application.
Yep, I've certainly noticed that; my old emachines single-core AMD64
Athlon-based computer kicks into 'high gear' on some of my scenes. (I can even
hear a subtle high-pitched whine--not from the cooling fan AFAIK, but, I'm
guessing, from the CPU(?).)
> ... AMD CPUs have a reputation for failing
> catastrophically and suffering permanent damage.
Yikes! Didn't know that. But it seems that my system's fan throttles well
enough; happy to say that I've never had such a failure. I *do* clean the
machine's innards from time to time, though.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.04.2013 19:48, schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> A well-designed computer should be ok even at full throttle. However,
>> not all computers are well-designed with respect to thermal management,
>> and POV-Ray has a habit of making the CPU sweat like no other application.
>
> Yep, I've certainly noticed that; my old emachines single-core AMD64
> Athlon-based computer kicks into 'high gear' on some of my scenes. (I can even
> hear a subtle high-pitched whine--not from the cooling fan AFAIK, but, I'm
> guessing, from the CPU(?).)
Yeah, that's the CPU crying for mercy ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger <ger### [at] gmailcom> wrote:
>
> What I did however is store the differenced spheres in a text file and later
> #include that. Doing it this way you don't have the nested differences
> anymore and that has a huge impact on the render time. 7 seconds against
> 1:36 minutes.
Really?! That's quite fascinating; I've never tried such a trick. Being able to
shave off that much time is a method I need to investigate--especially for
animation!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
>
> - The CPU might not be getting enough ventilation because of too much dust
> on its heatsink. You should check that.
>
Great advice. It's amazing how much dust accumulates in a heatsink--like
smothering the CPU in a blanket.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth wrote:
> Yep, I've certainly noticed that; my old emachines single-core AMD64
> Athlon-based computer kicks into 'high gear' on some of my scenes. (I can even
> hear a subtle high-pitched whine--not from the cooling fan AFAIK, but, I'm
> guessing, from the CPU(?).)
must be your CPU kicking up to 20 KHz turbo mode ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christian Froeschlin <chr### [at] chrfrde> wrote:
> Kenneth wrote:
>
> > Yep, I've certainly noticed that; my old emachines single-core AMD64
> > Athlon-based computer kicks into 'high gear' on some of my scenes. (I can even
> > hear a subtle high-pitched whine--not from the cooling fan AFAIK, but, I'm
> > guessing, from the CPU(?).)
>
> must be your CPU kicking up to 20 KHz turbo mode ;)
Ha! No no, 30KHz :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth wrote:
> Ger <ger### [at] gmailcom> wrote:
>>
>> What I did however is store the differenced spheres in a text file and
>> later
>> #include that. Doing it this way you don't have the nested differences
>> anymore and that has a huge impact on the render time. 7 seconds against
>> 1:36 minutes.
>
> Really?! That's quite fascinating; I've never tried such a trick. Being
> able to shave off that much time is a method I need to
> investigate--especially for animation!
Yes. I have tried it multiple times and the results are quite astonishing.
You have to keep in mind however that this is done on a barebones scene.
Just one main sphere with a bunch of differenced spheres, no AA, simple
light_source and so on. Whatever else you put in your scene does not profit
from this trick. Having said that, what I tend to do is when I have objects
that are the result of time consuming calculations I try to always store
those in external text files and later #include those files.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kenneth wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>
>>
>> - The CPU might not be getting enough ventilation because of too much
>> dust
>> on its heatsink. You should check that.
>>
>
> Great advice. It's amazing how much dust accumulates in a heatsink--like
> smothering the CPU in a blanket.
That's not the case here. I have seen too many PC's burn out over the years.
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
