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