|
|
|
|
|
|
| |
| |
|
|
From: Dave
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 17 Aug 2012 17:26:45
Message: <502eb715@news.povray.org>
|
|
|
| |
| |
|
|
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)
|
|
| |
| |
|
|
From: Dave
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 17 Aug 2012 18:14:38
Message: <502ec24e$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: clipka
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 17 Aug 2012 18:38:40
Message: <502ec7f0@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: clipka
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 17 Aug 2012 18:46:06
Message: <502ec9ae$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Dave
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 17 Aug 2012 19:26:03
Message: <502ed30b$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Le Forgeron
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 18 Aug 2012 03:35:52
Message: <502f45d8$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Le Forgeron
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 18 Aug 2012 03:48:44
Message: <502f48dc$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Dave
Subject: Re: 3.7rc6 on Raspberry PI, with/without openexr image artifacts
Date: 20 Aug 2012 13:42:36
Message: <5032770c$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |