 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I have some problems when allocating memory to POV where it breaks the
first 128 Mo (ie when system + pov memory > 128 Mo).
Pov crashes with error 1 or 2 or hang the system.
test files concerned are memory hogs (+45 000 objects, mostly cylinders
and cones), but if I reduce number of object to come under the 128 Mo
limit (global not pov), it works.
this is true since first 3.0 version, but when I make a custom
compilation with MPW, it works well.
So it seems that it is an Adressing space problem.
(MacOs 8.1 fr, 8600 PowerMac 192 Mo memory)
Does anyone encounters same problems ?
--
JL Peuriere
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Allocating further than 128 to POV
Date: 4 Aug 1999 15:43:19
Message: <37a897d7@news.povray.org>
|
|
|
| |
| |
|
|
In article <1dw### [at] st-etienne-3-4 club-internetfr> ,
jl_### [at] club-internetfr (Jean-Luc Peuriere) wrote:
> I have some problems when allocating memory to POV where it breaks the
> first 128 Mo (ie when system + pov memory > 128 Mo).
> Pov crashes with error 1 or 2 or hang the system.
>
> test files concerned are memory hogs (+45 000 objects, mostly cylinders
> and cones), but if I reduce number of object to come under the 128 Mo
> limit (global not pov), it works.
>
> this is true since first 3.0 version, but when I make a custom
> compilation with MPW, it works well.
>
> So it seems that it is an Adressing space problem.
>
> (MacOs 8.1 fr, 8600 PowerMac 192 Mo memory)
>
> Does anyone encounters same problems ?
No, just weak memory management of the CodeWarrior libraries, it has nothing
to do with 128 MB, depending on the scene you will find such a problem with
20 MB or with 500 MB. Did you try 3.1g.r1 yet? It can reduce such problems
as well. 3.5 will likely have a custom memory management system to
eliminate the problems once and for all.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trfde> wrote:
>
> No, just weak memory management of the CodeWarrior libraries, it has nothing
> to do with 128 MB, depending on the scene you will find such a problem with
> 20 MB or with 500 MB. Did you try 3.1g.r1 yet? It can reduce such problems
> as well. 3.5 will likely have a custom memory management system to
> eliminate the problems once and for all.
For 3.1g.r1 same problem.
If codewarrior memory management is somewhat weak, I still think there
is a problem of adressing space. I was able to render the scenes with a
smaller system, thus going under the 128 Mo and it worked fine.
But if memory management is improved with 3.5 that's a great news.
I'm new to this newsgroup, so I have only the "POV-Team Plans for 1999"
document as evolution planning. What is the timeline for 3.5 ?
JL Peuriere
--
GG: Si maintenant on introduit le concept de normalite des bugs,
ou va l'informatique ?
Chez Microsoft ? Ah oui, pas faux ca.
-+- GG in Guide du Macounet Pervers : R i F, you'll be Buggified -+-
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Allocating further than 128 to POV
Date: 5 Aug 1999 10:48:46
Message: <37a9a44e@news.povray.org>
|
|
|
| |
| |
|
|
In article <1dw### [at] st-etienne-2-74club-internetfr> ,
jl_### [at] club-internetfr (Jean-Luc Peuriere) wrote:
> For 3.1g.r1 same problem.
Try setting the memory cache slider to "Largeste Cache". Oh, and how large
is the POV-Ray scene file? Would it be possible to e-mail it to me? (You can
use tho### [at] trfde instead of mac### [at] povrayorg.)
> If codewarrior memory management is somewhat weak, I still think there
> is a problem of adressing space. I was able to render the scenes with a
> smaller system, thus going under the 128 Mo and it worked fine.
Well, there are a lot of applicions developed with CodeWarrior and I am
pretty sure they would have found it before. It has to do with the number of
allocations.
One example for the problem appearing before the 128 MB is pyramid2.pov
(under 3.1g, not 3.1gr1). With recursion level 6 it works just fine with
about 15 MB free, if you set it to 7 you will notice t hat the CodeWarror
memory management breaks down (sometimes) after about 40 MB used. You will
also notice a very, very big slowdown after about half way through parsing.
> I'm new to this newsgroup, so I have only the "POV-Team Plans for 1999"
> document as evolution planning. What is the timeline for 3.5 ?
Except for that document, nothing else has been decided to be final and no
other information has been release so far.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
From: Thorsten Froehlich
Subject: Re: Allocating further than 128 to POV
Date: 9 Aug 1999 15:47:55
Message: <37af306b@news.povray.org>
|
|
|
| |
| |
|
|
In article <37a9a44e@news.povray.org> , "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> One example for the problem appearing before the 128 MB is pyramid2.pov
> (under 3.1g, not 3.1gr1). With recursion level 6 it works just fine with
> about 15 MB free, if you set it to 7 you will notice t hat the CodeWarror
> memory management breaks down (sometimes) after about 40 MB used. You will
> also notice a very, very big slowdown after about half way through parsing.
Another example is a scene I recently used to check out the stability. It
used 140 MB, 200000 objects and over 2.5 million individual allocated blocks
without problems:
Creating bounding slabs.
Scene contains 202500 frame level objects; 0 infinite.
Creating vista buffer.
Creating light buffers.
Displaying...
Rendering...
Done Tracing
untitled.pov Statistics, Resolution 100 x 100
----------------------------------------------------------------------------
Pixels: 10000 Samples: 10000 Smpls/Pxl: 1.00
Rays: 10000 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Sphere 332 178 53.61
Bounding Box 3505 333 9.50
Light Buffer 3539 1053 29.75
Vista Buffer 43551 24318 55.84
----------------------------------------------------------------------------
Calls to Noise: 0 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 117 Succeeded: 0
----------------------------------------------------------------------------
Smallest Alloc: 26 bytes Largest: 1620024
Peak memory used: 140421828 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 3 minutes 22.0 seconds (202 seconds)
Time For Trace: 0 hours 0 minutes 1.0 seconds (1 seconds)
Total Time: 0 hours 3 minutes 23.0 seconds (203 seconds)
-- [AnimFrame] file#:'untitled.pict' frame#:0 clock:0
Reclaiming memory
-- [Stack] Total Stack space used = 8320 bytes
-- [Finish] File=untitled.pov, Time=09.08.1999 21:29:57 Uhr
----------------------------------------------------------------------------
POV-Ray Mac Memory Cache Statistics
Cache hits: 2513256 Cache misses: 8581
Total calls to malloc: 2521837 Cache hit rate: 99%
---------------------------------------------------------------------------
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been using POV-Ray 3.1g.r1, and I've seen cache hit rates ranging from
100% to -45%. In the latest cases pov-ray suggest me to increase the memory
cache, but I have already set it to it's maximum. My question is:
The cache hit rate can be increased simply allocating more memory to pov (via
get info)?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37AF4B0A.B5DBD195@ma.usb.ve> , Alberto <ame### [at] mausbve>
wrote:
> I've been using POV-Ray 3.1g.r1, and I've seen cache hit rates ranging from
> 100% to -45%. In the latest cases pov-ray suggest me to increase the memory
> cache, but I have already set it to it's maximum. My question is:
> The cache hit rate can be increased simply allocating more memory to pov (via
> get info)?
No, for some scenes the cache is simply not effective. The cache will not
benefit from increasing the memory available to POV-Ray, all it does is to
fast make the free memory "available" to POV-Ray. You can find a few more
details on the http://mac.povray.org/help_info.html page.
> 100% to -45%.
Is the -45% just a typo or was it really a negative number?
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>...
>Is the -45% just a typo or was it really a negative number?
>
>
> Thorsten
No, unfortunately this is not a typo. Following is the status window in an
example. The scene contains a blob with 1500 elements (spheres) a disc and a
sky_sphere.
The blob is highly transparent with ior (1.1 in this case).
Negative values appear when the output image is ~800x600 and the antialiasing is
on and there are transparent objects (as far I've seen).
! Available Memory: 8944 KBytes
! MacOS system version: 8.10
! AppleScriptExists: 1
! QuickTimeVersion: 4.00 ImageCompressionExists: 1
! CPU type: PowerPC
Remove bounds........On Split unions.........On
Library paths: orion:graphics:POV-Ray 3:Include:
Output Options
Image resolution 800 by 600 (rows 1 to 600, columns 1 to 800).
Rendering to screen only. No file output.
Graphic display......On (type: 0, palette: 3, gamma: 1.8)
Mosaic preview......Off
CPU usage histogram.Off
Continued trace.....Off Allow interruption...On Pause when done.....Off
Verbose messages....Off
Tracing Options
Quality: 9
Bounding boxes.......On Bounding threshold: 10
Light Buffer.........On Vista Buffer.........On Draw Vista Buffer...Off
Antialiasing.........On (Method 2, Threshold 0.200, Depth 3, Jitter 0.00)
Radiosity...........Off
Animation Options
Clock value.... 0.000 (Animation off)
Redirecting Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
Parsing........................................................................
...........................................
Creating bounding slabs.
Scene contains 2 frame level objects; 0 infinite.
Displaying...
Rendering...
Aborting render...
tubblob.pov Statistics (Partial Image Rendered), Resolution 800 x 600
----------------------------------------------------------------------------
Pixels: 202018 Samples: 978995 Smpls/Pxl: 4.85
Rays: 2941811 Saved: 228 Max Level: 53/90
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Blob 16877478 10703588 63.42
Blob Component 1279954953 851231048 66.50
Blob Bound 2876546617 1687731484 58.67
Disc 16877478 2804781 16.62
----------------------------------------------------------------------------
Roots tested: 15626998 eliminated: 4488562
Calls to Noise: 35018 Calls to DNoise: 10
----------------------------------------------------------------------------
Shadow Ray Tests: 27871790 Succeeded: 8740772
Reflected Rays: 181963 Total Internal: 181963
Refracted Rays: 1780853
----------------------------------------------------------------------------
Smallest Alloc: 26 bytes Largest: 180024
Peak memory used: 768472 bytes
----------------------------------------------------------------------------
Time For Parse: 0 hours 0 minutes 2.0 seconds (2 seconds)
Time For Trace: 2 hours 10 minutes 34.0 seconds (7834 seconds)
Total Time: 2 hours 10 minutes 36.0 seconds (7836 seconds)
User abort.
Reclaiming memory
-- [Stack] Total Stack space used = 32672 bytes
-- [Finish] File=tubblob.pov, Time=8/10/99 10:24:22 AM
----------------------------------------------------------------------------
POV-Ray Mac Memory Cache Statistics
Cache hits: 26209226 Cache misses: 4
Total calls to malloc: 26209230 Cache hit rate: -63%
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The memory cache it rate is extremely low, try to increase the cache size!
To do so go to the Edit menu and enter the Preferences dialog. The setting
is in the General pane.
----------------------------------------------------------------------------
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW. I have set the memory cache to largest, and of course, negative values also
appear on completely rendered images.
Alberto.
I don't know if of any use, but here is the code of the example.
global_settings{max_trace_level 90}
camera{location 10*<0,5,-5> look_at 0 angle 7.25}
light_source{<-4,4,-4> rgb 1}
light_source{< 4,4,-4> rgb 1}
sky_sphere{
pigment{bozo color_map{
[0 rgb <1,.5,0>] [1 rgb .5* <1,.5,0>]
}
}
}
disc{-3*y y 10
pigment{checker rgb <1,.5,0>, rgb .5* <1,.5,0>}
rotate 30*y
}
#macro Knot(m, r, n, th)
#local mp = m+1; #local k = 0;
blob{threshold th
#while(k < n)
#local s = 2*pi*k/n;
sphere{
< (2 + cos(mp*s))*cos(m*s), 2*sin(mp*s),
(2 + cos(mp*s))*sin(m*s)
>, r, 1
}
#local k = k + 1;
#end
}
#end
object{Knot(3 .6 1500 4)
finish{ ambient 0 diffuse 0
specular 1 roughness .002}
interior{ior 1.1 caustics .1}
pigment{rgbf <1,1,1,.9>}
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <37B042CA.8624B5C6@ma.usb.ve> , Alberto <ame### [at] mausbve>
wrote:
> BTW. I have set the memory cache to largest, and of course, negative values
> also appear on completely rendered images.
Hmm, yes. I use a very simple way to calcualte the cache hit rate and for
more than 21.45 million memory allocations this will cause an integer value
overflow calculating the hit rate (which causes the value to be negative).
This is not harmful, but of course it gives incorrect values.
Here is how to calculate the correct hit rate (in percent):
Cache hit rate = (Cache hits * 100) / (Total calls to malloc)
Thus, also stated otherwise, you have a nearly 100% hit rate for your scene!
Just ignore the cache hit rate notice.
I am sorry for this bug. Thank you for pointing it out!
As it is not serious, it won't get fixed until POV-Ray Mac 3.5.
Thorsten
____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg
I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
