I built pov 3.7 rc6 beta on my Raspberry PI.

The first time I built, openexr was enabled by default; the second time 
I built with '--without-openexr'. For each build I ran povray on the 
biscuit.pov file as done by 'make check'. Perhaps this is by design, but 
when built with openexr, the 8-bit color PNG exhibits weird artifacts. I 
would expect to see this if I used '+fn16' (I actually used +fn) and 
pnginfo displays the same info for both PNG's:

[openexr enabled povray]
   $ pnginfo biscuit-withexr.png
   Image Width: 320 Image Length: 240
   Bitdepth (Bits/Sample): 8
   Channels (Samples/Pixel): 3
   Pixel depth (Pixel Depth): 24
   Colour Type (Photometric Interpretation): RGB
   Image filter: Single row per byte filter
   Interlacing: No interlacing
   Compression Scheme: Deflate method 8, 32k window
   Resolution: 0, 0 (unit unknown)
   FillOrder: msb-to-lsb
   Byte Order: Network (Big Endian)
   Number of text strings: 2 of 9
     Software (tEXt uncompressed): POV-Ray 3.7.0.RC6
     Comment (tEXt uncompressed): Render Date: 2012-08-16 
06:02:06Z\nPlatform: armv6l-unknown-linux-gnueabi\nCompiler: g+
+ 4.6\n

[--without-openexr]
   $ pnginfo biscuit-noexr.png
   Image Width: 320 Image Length: 240
   Bitdepth (Bits/Sample): 8
   Channels (Samples/Pixel): 3
   Pixel depth (Pixel Depth): 24
   Colour Type (Photometric Interpretation): RGB
   Image filter: Single row per byte filter
   Interlacing: No interlacing
   Compression Scheme: Deflate method 8, 32k window
   Resolution: 0, 0 (unit unknown)
   FillOrder: msb-to-lsb
   Byte Order: Network (Big Endian)
   Number of text strings: 2 of 9
     Software (tEXt uncompressed): POV-Ray 3.7.0.RC6
     Comment (tEXt uncompressed): Render Date: 2012-08-17 
12:20:06Z\nPlatform: armv6l-unknown-linux-gnueabi\nCompiler: g+
+ 4.6\n

Furthermore, there are still artifacts in the no-exr image when compared 
to a PNG rendered on Win7x64 using povray 3.7 RC6. I've attached all 
three images for comparison.

For you information, when I first got the Raspberry PI up and running, I 
ran an ancient program 'paranoia.c' which tests floating point accuracy. 
The program can still be found here:
   http://www.netlib.org/paranoia/paranoia.c
The program reported no abnormalities on the Raspberry PI, so I would 
expect that the PNG's produced by both x86 and arm (--without-openexr) 
would be >close< to identical. But they are not...?

Post a reply to this message

Attachments:
Download 'biscuit-withexr.png' (165 KB) Download 'biscuit-noexr.png' (164 KB) Download 'biscuit-win7x64.png' (163 KB)

Preview of image 'biscuit-withexr.png'

Preview of image 'biscuit-noexr.png'

Preview of image 'biscuit-win7x64.png'

Le 17/08/2012 20:28, Dave nous fit lire :
> pnginfo displays the same info for both PNG's:

Nothing shocking here, the platform & compiler are in the comments, but
not the configure's options.

Have you tried another output format ?

Post a reply to this message

Am 17.08.2012 20:28, schrieb Dave:
> I built pov 3.7 rc6 beta on my Raspberry PI.
>
> The first time I built, openexr was enabled by default; the second time
> I built with '--without-openexr'. For each build I ran povray on the
> biscuit.pov file as done by 'make check'. Perhaps this is by design, but
> when built with openexr, the 8-bit color PNG exhibits weird artifacts. I
> would expect to see this if I used '+fn16' (I actually used +fn) and
> pnginfo displays the same info for both PNG's:

This is definitely /not/ by design; whether you build with openEXR or 
not should be irrelevant unless you actually try to use openEXR in- or 
output.

The only reason I can think of why disabling openEXR /does/ make a 
difference is that it is a file format based on some special 
"half-precision" floating point data type; maybe enabling openEXR also 
causes the CPU's floating point module to be switched into a different 
mode, where some computation errors become more prominent.


Are you sure the ARM does support full double-precision IEEE floating 
point arithmetics?


> For you information, when I first got the Raspberry PI up and running, I
> ran an ancient program 'paranoia.c' which tests floating point accuracy.
> The program can still be found here:
>    http://www.netlib.org/paranoia/paranoia.c
> The program reported no abnormalities on the Raspberry PI, so I would
> expect that the PNG's produced by both x86 and arm (--without-openexr)
> would be >close< to identical. But they are not...?

I have no idea what that program actually tests - not to mention that 
you might have compiled it with totally different floating point mode 
settings.

Post a reply to this message

On 8/17/2012 3:40 PM, clipka wrote:
> Am 17.08.2012 20:28, schrieb Dave:
>> I built pov 3.7 rc6 beta on my Raspberry PI.
>>
>> The first time I built, openexr was enabled by default; the second time
>> I built with '--without-openexr'. For each build I ran povray on the
>> biscuit.pov file as done by 'make check'. Perhaps this is by design, but
>> when built with openexr, the 8-bit color PNG exhibits weird artifacts. I
>> would expect to see this if I used '+fn16' (I actually used +fn) and
>> pnginfo displays the same info for both PNG's:
>
> This is definitely /not/ by design; whether you build with openEXR or
> not should be irrelevant unless you actually try to use openEXR in- or
> output.
>
> The only reason I can think of why disabling openEXR /does/ make a
> difference is that it is a file format based on some special
> "half-precision" floating point data type; maybe enabling openEXR also
> causes the CPU's floating point module to be switched into a different
> mode, where some computation errors become more prominent.
>
>
> Are you sure the ARM does support full double-precision IEEE floating
> point arithmetics?
>

 From what I have gathered from the RPi site/forums, the device uses 
hardware floating point. When I was looking into this, I tried 
-mfloat-abi=softfp and I got a link error that said (paraphrased):

   cannot mix objects compiled with different floating point abi's

I have since read on the forums:

   the RPi only supports -mfpu=vfp -mfloat-abi=hard (and this is the 
default)

When I built povray & the paranoia.c program, I took all defaults. I 
have no reason to believe that any compile-time floating point settings 
changed. As far as openexr... I could not tell you, but since I have no 
monitors that can display such images I decided to disable it.


>> For you information, when I first got the Raspberry PI up and running, I
>> ran an ancient program 'paranoia.c' which tests floating point accuracy.
>> The program can still be found here:
>>    http://www.netlib.org/paranoia/paranoia.c
>> The program reported no abnormalities on the Raspberry PI, so I would
>> expect that the PNG's produced by both x86 and arm (--without-openexr)
>> would be >close< to identical. But they are not...?
>
> I have no idea what that program actually tests - not to mention that
> you might have compiled it with totally different floating point mode
> settings.
>

Take a look at the program & compile it on your system & see what you 
think. I am not mathematically savvy enough to say whether the program 
is correct or not -- it purports to test floating point accuracy and 
seems to be testing against what was the proposed IEEE floating point 
standard ca. 1985. However, I compiled and ran the program on Win7x64 
using the MinGW gcc 64-bit compiler. The results are essentially 
identical (diff appended below). Since my Intel CPU supports IEEE 
floating point and the paranoia.c program produces identical results, I 
would bet that the RPi supports IEEE floating point.

$ diff MinGW.txt RPi.txt

< $ gcc --version
< gcc.exe (GCC) 4.5.4 20111030 (prerelease) [svn/rev.180676 - mingw-w64/oz]
< Copyright (C) 2010 Free Software Foundation, Inc.
---
 > $ gcc -version
 > gcc (Debian 4.6.3-8+rpi1) 4.6.3
 > Copyright (C) 2011 Free Software Foundation, Inc.
7c7
< $ gcc paranoia.c -lm
---
 > $ gcc paranoia.c
101c105
< Closest relative separation found is U1 = 1.1102230e-016 .
---
 > Closest relative separation found is U1 = 1.1102230e-16 .
144c151
< What the machine gets for (Z + Z) / Z is  2.00000000000000000e+000 .
---
 > What the machine gets for (Z + Z) / Z is  2.00000000000000000e+00 .
148c155
< The Underflow threshold is 2.22507385850720190e-308,  below which
---
 > The Underflow threshold is 2.22507385850720188e-308,  below which
151c158
< UfThold = (2.00000000000000000e+000) ^ (-1.02200000000000000e+003)
---
 > UfThold = (2.00000000000000000e+00) ^ (-1.02200000000000000e+03)
153,154c160,161
< 	(2.00000000000000000e+000) ^ (-2.04400000000000000e+003);
< actually calculating yields: 0.00000000000000000e+000 .
---
 > 	(2.00000000000000000e+00) ^ (-2.04400000000000000e+03);
 > actually calculating yields: 0.00000000000000000e+00 .
157c164
< Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065220e+000 as 
X -> 1.
---
 > Testing X^((X + 1) / (X - 1)) vs. exp(2) = 7.38905609893065218e+00 as 
X -> 1.
169c177
< Trying it on Y = -1.#INF0000000000000e+000 .
---
 > Trying it on Y = -inf .
171,174c179,182
< Overflow threshold is V  = 1.79769313486231570e+308 .
< Overflow saturates at V0 = 1.#INF0000000000000e+000 .
< No Overflow should be signaled for V * 1 = 1.79769313486231570e+308
<                            nor for V / 1 = 1.79769313486231570e+308 .
---
 > Overflow threshold is V  = 1.79769313486231571e+308 .
 > Overflow saturates at V0 = inf .
 > No Overflow should be signaled for V * 1 = 1.79769313486231571e+308
 >                            nor for V / 1 = 1.79769313486231571e+308 .
186c195
<     Trying to compute 1 / 0 produces ...  1.#INF000e+000 .
---
 >     Trying to compute 1 / 0 produces ...  inf .
189c198,199
<     Trying to compute 0 / 0 produces ...  -1.#IND000e+000 .
---
 >
 >     Trying to compute 0 / 0 produces ...  nan .

Post a reply to this message

On 8/17/2012 2:58 PM, Le_Forgeron wrote:
> Le 17/08/2012 20:28, Dave nous fit lire :
>> pnginfo displays the same info for both PNG's:
>
> Nothing shocking here, the platform & compiler are in the comments, but
> not the configure's options.
>

I took all defaults. povray --V (for the openexr version) gives the 
output below. The only thing I added for the non-openexr version was 
'--without-openexr':

povray: This is a RELEASE CANDIDATE version of POV-Ray. General 
distribution is discouraged.
POV-Ray 3.7.0.RC6

This is a release candidate of POV-Ray version 3.7.0.
General distribution is strongly discouraged.

Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.

Built-in features:
   I/O restrictions:          enabled
   X Window display:          enabled (using SDL)
   Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
   Unsupported image formats: -

Compilation settings:
   Build architecture:  armv6l-unknown-linux-gnueabi
   Built/Optimized for: armv6l-unknown-linux-gnueabi
   Compiler vendor:     gnu
   Compiler version:    g++ 4.6
   Compiler flags:      -pipe -Wno-multichar -Wno-write-strings 
-fno-enforce-eh-specs -s -O3 -ffast-math -pthread


> Have you tried another output format ?
>

I reran with PPM output. Results look the same.

povray+exr +ipovray-3.7.0.RC6/scenes/advanced/biscuit.pov +fp 
+obiscuit-exr.ppm   -d +p +v +w320 +h240 +a0.3
povray     +ipovray-3.7.0.RC6/scenes/advanced/biscuit.pov +fp 
+obiscuit-noexr.ppm -d +p +v +w320 +h240 +a0.3

Post a reply to this message

Attachments:
Download 'biscuit-exr.ppm.dat' (226 KB) Download 'biscuit-noexr.ppm.dat' (226 KB)

On 8/17/2012 3:40 PM, clipka wrote:
> Are you sure the ARM does support full double-precision IEEE floating
> point arithmetics?

 From the Raspberry PI site (http://www.raspberrypi.org), the FAQ contains:

   What SoC are you using?

   The SoC is a Broadcom BCM2835. This contains an ARM1176JZFS, with 
floating point, running at 700Mhz, ...

Not sure what a "SOC" is, but a Google for 'ARM1176JZFS' leads to:

 
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf

which is 'ARM1176JZF-S Revision r0p7 Technical Reference Manual'. In 
that manual it states (page 20.3, item 20.2.1):

   20.2.1 An IEEE 754 standard-compliant implementation
   The VFP11 hardware and support code together provide VFPv2 
floating-point instruction implementations that are compliant with the 
IEEE 754 standard. Unless an enabled floating-point exception occurs, it 
appears to the program that the floating-point instruction was executed 
by the hardware. If an exceptional condition occurs that requires 
software support during instruction execution, the instruction takes 
significantly more cycles than normal to produce the result. This is a 
common practice in the industry, and the incidence of such instructions 
is typically very low.

Since the RPi runs Debian Linux (the 'Wheezy' version? I'm not familiar 
enough with Linux to tell you what that means). Anyway, the package 
repositories are not built expressly for the RPi but for 'armhf' (again, 
I can't tell you what that means). What I would deduce from this is that 
from a programmer's viewpoint, IEEE floating point is supported, 
otherwise there would need to be special ports of math-related software 
for the RPi -- and there are not.

Post a reply to this message

Am 18.08.2012 00:14, schrieb Dave:

>    The SoC is a Broadcom BCM2835. This contains an ARM1176JZFS, with
> floating point, running at 700Mhz, ...
>
> Not sure what a "SOC" is, but a Google for 'ARM1176JZFS' leads to:

System on a Chip. Meaning that besides the actual CPU, the silicon die 
contains a host of other stuff that a classic desktop computer would 
have on the mainboard.

Post a reply to this message

Am 18.08.2012 00:14, schrieb Dave:

>    20.2.1 An IEEE 754 standard-compliant implementation
>    The VFP11 hardware and support code together provide VFPv2
> floating-point instruction implementations that are compliant with the
> IEEE 754 standard. Unless an enabled floating-point exception occurs, it
> appears to the program that the floating-point instruction was executed
> by the hardware. If an exceptional condition occurs that requires
> software support during instruction execution, the instruction takes
> significantly more cycles than normal to produce the result. This is a
> common practice in the industry, and the incidence of such instructions
> is typically very low.
>
> Since the RPi runs Debian Linux (the 'Wheezy' version? I'm not familiar
> enough with Linux to tell you what that means). Anyway, the package
> repositories are not built expressly for the RPi but for 'armhf' (again,
> I can't tell you what that means). What I would deduce from this is that
> from a programmer's viewpoint, IEEE floating point is supported,
> otherwise there would need to be special ports of math-related software
> for the RPi -- and there are not.

That's all nice to read, but /something/ must be going wrong, and I 
still suspect the floating point arithmetics (if only because of the 
difference that openEXR makes).

I've just ordered one of those tiny little brats myself to further 
investigate the issue. Don't hold your breath though - delivery is 
estimated to take 15 weeks.

Post a reply to this message

On 8/17/2012 5:45 PM, clipka wrote:
> I've just ordered one of those tiny little brats myself to further
> investigate the issue. Don't hold your breath though - delivery is
> estimated to take 15 weeks.

Ouch... I thought they'd ramped up production by now. I got two of them 
at the end of July.

Be sure to use a decent regulated power supply. Initially my brother and 
I were using a phone charger. He had reliability issues with his when he 
used various USB peripherals (BTW, except for video/sound/wired 
ethernet, you need USB peripherals). He suspects that the voltage drops 
enough under load that the RPi had issues. I am still on the charger but 
I've only got a usb wireless kbd/mouse dongle plugged in and am using 
wired ethernet. It >is< an interesting little toy!

Oh, and use a fast SD card. I found a $20 32G HP class 10 SDHC on amazon 
and it's working fine. As it is though, it takes about 6.5 hours to 
compile povray. It's like 1990 and a 386! :-)

Anyway, as far as the FP unit -- I'm sure that it's using "hardware 
floating point" but >I< couldn't define that precisely.

Good luck.

Post a reply to this message

Le 17/08/2012 23:26, Dave nous fit lire :
> On 8/17/2012 2:58 PM, Le_Forgeron wrote:
>> Le 17/08/2012 20:28, Dave nous fit lire :
>>> pnginfo displays the same info for both PNG's:
>>
>> Nothing shocking here, the platform & compiler are in the comments, but
>> not the configure's options.
>>
> 
> I took all defaults. povray --V (for the openexr version) gives the
> output below. The only thing I added for the non-openexr version was
> '--without-openexr':

My bad. I was stating that the image-info/comment only uses the build
architecture and the compiler, not any other configure option.

I trust you about the fact that both png had the same comments, and it's
rather normal. (due to the fact that povray does not push into the
comment any data about it's configure's option)

Post a reply to this message

Le 17/08/2012 23:26, Dave nous fit lire :
>> Have you tried another output format ?
>>
> 
> I reran with PPM output. Results look the same.
> 
> povray+exr +ipovray-3.7.0.RC6/scenes/advanced/biscuit.pov +fp
> +obiscuit-exr.ppm   -d +p +v +w320 +h240 +a0.3
> povray     +ipovray-3.7.0.RC6/scenes/advanced/biscuit.pov +fp
> +obiscuit-noexr.ppm -d +p +v +w320 +h240 +a0.3

Yep. Strange. Always the same spot.
I do not see how having more code would change so drastically the result
of code that do not use the additional code... stack rolling over code ?
pointer interpreted within page context ?

Post a reply to this message

Dave, from your comment about using -mfloat-abi=hard I deduce you're using
Raspbian Wheezy, which is a RaspberryPi specific hardfloat port of Debian
Wheezy.
The official Debian armhf needs ARMv7. The raspi is ARMv6+vfp2
So debian armhf is not compatible with Raspbian armhf.

Regards
Aydan

Post a reply to this message

On 8/20/2012 7:36 AM, Aydan wrote:
> Dave, from your comment about using -mfloat-abi=hard I deduce you're using
> Raspbian Wheezy, which is a RaspberryPi specific hardfloat port of Debian
> Wheezy.

Yes, that sounds like what I've read on the RPi forums. I downloaded and 
am running their 'wheezy' image; not sure a uname identifies it as such:

$ uname -a
Linux PIblack 3.2.27+ #6 PREEMPT Sat Aug 18 15:05:48 BST 2012 armv6l 
GNU/Linux

> The official Debian armhf needs ARMv7. The raspi is ARMv6+vfp2
> So debian armhf is not compatible with Raspbian armhf.

I've always preferred FreeBSD to Linux so I'm (as of now) unclear about 
what you just said means. I know I've been doing 'apt-get' and it 
downloads & installs stuff that runs on the RPi. When I do a 'dpkg -l', 
a few of the packages mention 'armhf'...  I've now exhausted my 
knowledge here! :-)

Post a reply to this message

Dave <use### [at] iamdaveATglidefreecom> wrote:

> > The official Debian armhf needs ARMv7. The raspi is ARMv6+vfp2
> > So debian armhf is not compatible with Raspbian armhf.
>
> I've always preferred FreeBSD to Linux so I'm (as of now) unclear about
> what you just said means. I know I've been doing 'apt-get' and it
> downloads & installs stuff that runs on the RPi. When I do a 'dpkg -l',
> a few of the packages mention 'armhf'...  I've now exhausted my
> knowledge here! :-)

Oi, coming from the x86 world, the ARM ecosystem is a complete mess. Any modern
x86 processor you buy now is going to have at least the following: 64-bit
architecture with SSE2, x87, etc.

In the ARM world, everything but the main integer execution core is optional.
Any device you buy with an ARM-based processor may or may not have any of the
following: thumb, vfp (and its variants), neon, etc. The official Debian 7.0
(wheezy armhf) requires at least an ARM processor that uses ARMv7 instruction
set and has a VFPv3-D16 floating point unit. The other option is to use Debian
7.0 armel, which is requires ARMv5 (I think) but not a floating point unit. Very
annoying. A theoretical FreeBSD for ARM distribution would have to tackle the
same problem.


Reminds me of back in the '80s when you could buy an 8088 computer and
plug in a third party floating point coprocessor, with resulting code not
compatible with other third party FP coprocessors.

Post a reply to this message

On 8/20/2012 11:29, jhu wrote:
> In the ARM world, everything but the main integer execution core is optional.

In part, this is because the ARM is a core, while the x86 machines are chips.

A "core" is a hardware design that you integrate onto a die along with the 
other stuff you want. So a core vs chip is like a chip vs a board. As far as 
I know, ARM does not actually sell chips themselves, only VHDL 
specifications for chips.

I'm wondering why nobody is building Raspberry.pi like devices from these 
http://opencores.org/

-- 
Darren New, San Diego CA, USA (PST)
   "They're the 1-800-#-GORILA of the telecom business."

Post a reply to this message

Am 18.08.2012 00:45, schrieb clipka:

> That's all nice to read, but /something/ must be going wrong, and I
> still suspect the floating point arithmetics (if only because of the
> difference that openEXR makes).
>
> I've just ordered one of those tiny little brats myself to further
> investigate the issue. Don't hold your breath though - delivery is
> estimated to take 15 weeks.

Here's what I get /with/ OpenEXR enabled. Note that it's exactly what 
Dave reported /without/ OpenEXR.

I swear I'm gonna find out what's going on here...

Post a reply to this message

Attachments:
Download 'biscuit.png' (595 KB)

Preview of image 'biscuit.png'

Am 12.12.2012 20:30, schrieb clipka:

> I swear I'm gonna find out what's going on here...

Apparently there's something fishy happening with the phong highlighting.

Post a reply to this message

Am 12.12.2012 20:56, schrieb clipka:
> Am 12.12.2012 20:30, schrieb clipka:
>
>> I swear I'm gonna find out what's going on here...
>
> Apparently there's something fishy happening with the phong highlighting.

Further investigations suggest that the Pi isn't happy with denormalized 
values, at least not in single precision.

I'll try to throw together some simple C test program, and if that 
confirms my observations I'll file it as a bug to the Pi people.

Post a reply to this message

Am 12.12.2012 22:03, schrieb clipka:
> Am 12.12.2012 20:56, schrieb clipka:
>> Am 12.12.2012 20:30, schrieb clipka:
>>
>>> I swear I'm gonna find out what's going on here...
>>
>> Apparently there's something fishy happening with the phong highlighting.
>
> Further investigations suggest that the Pi isn't happy with denormalized
> values, at least not in single precision.
>
> I'll try to throw together some simple C test program, and if that
> confirms my observations I'll file it as a bug to the Pi people.

Apparently the problems are related to the -ffast-math compiler option; 
I'll try whether turning that off will help.

Post a reply to this message

Am 13.12.2012 00:24, schrieb clipka:

> Apparently the problems are related to the -ffast-math compiler option;
> I'll try whether turning that off will help.

Well, no, not really. No success, except that now the color of the 
artifacts is inverted.

Post a reply to this message

Attachments:
Download 'biscuit.png' (164 KB)

Preview of image 'biscuit.png'

Am 13.12.2012 08:52, schrieb clipka:
> Am 13.12.2012 00:24, schrieb clipka:
>
>> Apparently the problems are related to the -ffast-math compiler option;
>> I'll try whether turning that off will help.
>
> Well, no, not really. No success, except that now the color of the
> artifacts is inverted.

Turning off /all/ optimizations does give the expected results. I don't 
consider this an option though, so I guess we'll have to wait for 
feedback from the raspbian team.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 13.12.2012 08:52, schrieb clipka:
> > Am 13.12.2012 00:24, schrieb clipka:
> >
> >> Apparently the problems are related to the -ffast-math compiler option;
> >> I'll try whether turning that off will help.
> >
> > Well, no, not really. No success, except that now the color of the
> > artifacts is inverted.
>
> Turning off /all/ optimizations does give the expected results. I don't
> consider this an option though, so I guess we'll have to wait for
> feedback from the raspbian team.

I just compiled 3.6 on the Raspberry Pi and it has the same issues.

Post a reply to this message

Am 01.02.2013 17:14, schrieb calhjh:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 13.12.2012 08:52, schrieb clipka:
>>> Am 13.12.2012 00:24, schrieb clipka:
>>>
>>>> Apparently the problems are related to the -ffast-math compiler option;
>>>> I'll try whether turning that off will help.
>>>
>>> Well, no, not really. No success, except that now the color of the
>>> artifacts is inverted.
>>
>> Turning off /all/ optimizations does give the expected results. I don't
>> consider this an option though, so I guess we'll have to wait for
>> feedback from the raspbian team.
>
> I just compiled 3.6 on the Raspberry Pi and it has the same issues.

I would have expected that. The Pi seems to have a general problem with 
denormalized (i.e. very small) single-precision floating point values.

Post a reply to this message

Am 13.12.2012 14:48, schrieb clipka:

> Turning off /all/ optimizations does give the expected results. I don't
> consider this an option though, so I guess we'll have to wait for
> feedback from the raspbian team.

I've received feedback at last: The problem /may/ be solved with 
gcc-4.7; I'm currently recompiling POV-Ray on my Pi.

Raspbian Wheezy's standard gcc package is still at 4.6, so I had to 
manually install the gcc-4.7 and g++-4.7 packages, and force the 
./configure script to actually use gcc-4.7 via the "CXX=gcc-4.7" option.

We shall see in a couple of hours whether that actually solves the issue.

Post a reply to this message