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