POV-ray

Refering to Kuemmel’s post (1/12/2011) in "Announcements / PIK – Pandaboard … ", I was interested to see a compiled version of the ray tracer program POVray mentioned, (by Chris Gransden). Which version of POVray was compiled? Is this available for download for BBxM?

Render time comparisons of teapot.pov scene file at 1024×768 a0.3 :

Pentium 3.2GHz Vista POV3.6.1 (Ian) 32 sec
Pandaboard xM 600MHz (Kuemmel) 91 sec
BB 600MHz (Kuemmel) 179 sec
A7000+ RO4.02 POV3.1g (Ian) 1208 sec
RPC600SA RO4.39 POV3.1g (Ian) 3087 sec

I can’t access my BB/PB for a week, but I think it was version 3.6.1.

One thing is that the BB/PB can be much faster, but the gcc isn’t yet be able to compile to the fastest version for these CPU’s, as written in other posts. On the other hand there are multi-core versions running (later than 3.6.1) of course much faster on multi-core platforms, what Risc OS can’t do by now.

Was POVray built with hardfloat? that might get some performance boost there too.

No, according to Chris, ‘softfp’ was used for the Risc OS version. Until now he was not able to use the ‘hard’ option, may be it’s not even implemented. As seen in other posts it would give quite a push, especially to povray.

But people should not mistake softfp, as it would use only software fp emulation. It’s hardware fp, but with ‘slow’ calling conventions. I hope Chris or somebody else finds a way so that the ‘hard’ option can be used some time in the future.

Yet Chris built a version of the LAME encoder using the hard fp…

The tests I have run here show it makes a big difference.

What is the issue? Could we have a little more detail please?

Although built to use hardware floating point it’s using ‘abi=softfp’. It would be much faster if it was using ‘abi=hardfp’. The issue is that it is not yet possible to produce executables using ‘abi=hardfp’.

Here’s some more comparisons of the render time for teapot.pov at ‘1024×768 +a0.3’ using POVray 3.6.1. The fpa/softfloat version can be downloaded from here.

Pandaboard ES (1500Mhz neon/vfp) 15 secs
Pandaboard ES (1500MHz fpa/softfloat) 123 secs

Pandaboard ES (1200Mhz neon/vfp) 18 secs
Pandaboard ES (1200MHz fpa/softfloat) 150 secs

Beagleboard xM (800MHz neon/vfp) 113 secs
Beagleboard xM (800MHz fpa/softfloat) 339s

RPCSA RO 4.02 (233MHz fpa/softfloat) 2003 secs

That’s a pretty impressive performance gain for the VFP/NEON version on the Pandaboard. Do you know what kind of math its using? (single precision floats, double precision floats, or NEON)

I believe it’s nearly all double precision floats. I assume that’s why there’s such a large performance gain.

I’m also pretty sure it’s double precision floats…I found some statement on the povray website →

“…while POV-Ray needs (yes, it needs) double precision numbers. Single precision is not enough (this has been tested in practice)”

That would fit to my findings regarding the results for the Mandelbrot VFP. The A9’s VFP unit is just so much faster than the one of the A8.

The difference in speed using neon/vfp between the PandaBoard & Beagleboard is considerably more than the difference in clock speed, doesn’t the Beagleboard support double precision floats?
The ARM data sheet for the ARM11 in the Raspberry Pi mentions VFP but then refers you to Generic ARM documentation. Are there different implementations of the VFP and what can be expected of the Raspberry Pi?
And is R-Pi VFP the same as neon/vfp?

There’s an explanation of the difference between Cortex-a8 (Beagleboard) and Cortex-a9 (Pandaboard) here.

Cortex-A9 has a full VFPv3 FPU, whereas Cortex-A8 only has VFPLite. The main difference being that most float operations take 1 cycle on Cortex-A9 but take 10 cycles on Cortex-A8! Therefore VFP is very slow on Cortex-A8 but decent on Cortex-A9.

I believe the R-Pi has VFPv2 but no NEON.

There are quite a few different variants of VFP (and NEON). The two you’re most likely to find in RISC OS machines are:

• VFPv2 – as used in the Raspberry Pi
  • 32 single precision and 16 double precision registers (although the register files do overlap – i.e. if you use S0 or S1 to store a single precision float, it overwrites whatever’s in D0)
  • Supports vector maths
  • Supports hardware exceptions for division by zero, etc.
  • Rather simplistic pipeline – there’s (IIRC) one arithmetic unit, one load/store unit, and one square root/divide unit.
  • Each unit can only execute one instruction at a time, and since all the instructions take several clock cycles to execute, a big block of VFP instructions will take a lot longer to execute than a similar-size block of ARM instructions.
  • It’s possible that there are better VFPv2 implementations out there, but I haven’t seen any!
• VFPv3 with NEON – BeagleBoard, PandaBoard
  • VFP features:
    • 32 single precision and 32 double precision registers (with the first 16 double precision registers overlaid ontop of the single precision ones, the same as VFPv2)
    • Supports vector maths
    • Doesn’t support trapped exceptions, so any code that cares about exceptions has to check the status register manually
    • In Cortex-A8 implementations (e.g. BeagleBoard) it’s still a rather simplistic pipeline. But in Cortex-A9 (PandaBoard) I believe it’s been vastly improved and is now fully pipelined – hence the big performance boost visible in POV-ray.
    • One way you can boost performance on Cortex-A8 is to enable “runfast mode”. This allows the VFP instructions to execute in the NEON pipeline. But there are several limitations in place (can’t use vector maths, can’t use double precision floats, (IIRC) must use specific rounding mode), so not all programs will be able to benefit from it.
  • NEON features:
    • Register file is overlaid ontop of the VFP register file. Registers can be accessed either as quadwords (16 in total) or doublewords (32 in total), with a large number of data types (8/16/32/64 bit signed/unsigned integers, or single precision floats)
    • All instructions operate on vectors. In VFP the vector length is specified in the control register (and changing vector length can be quite slow, since it has to flush the pipeline). But with NEON the vector length is determined by the register size and data type in use. So if you’re using quadwords containing 8 bit ints then there’ll be 16 elements per vector. Since the register type & data type is specified on a per-instruction basis this means you can switch between operating on different vector lengths without any performance penalty (although you might find yourself forced to use longer vectors than desired, e.g. since registers are either 8 or 16 bytes you’d be forced to treat 3-element float vectors as if they were 4-element vectors)
    • No support for trapped exceptions
    • Advanced pipeline. Integer operations typically complete in one clock cycle, while floating point operations typically complete in two. Vector length rarely has any effect on performance, since it’s able to operate on each element of the vector in parallel, unlike VFP (except in Cortex-A9?) which (AFAIK) operates on each element in serial. You do get a performance boost from using the VFP vector support (compared to just doing lots of scalar maths), but it’s not as much as using NEON would get you.
    • Square root and division, which were by far the slowest operations in VFP, are very fast in NEON. One instruction will return you an approximate answer, and then another instruction will allow you to perform iterations of the newton-raphson method to increase the accuracy of the answer. For video decoding, 3D graphics, etc. an approximate answer might be all that you need, so by allowing the programmer control of how accurate the result is you can get significant performance gains compared to VFP.

TL;DR version:

• R-Pi VFP is a bit slow (but still better than FPA emulation)
• BeagleBoard VFP is a little bit better. NEON significantly better than VFP.
• PandaBoard VFP is significantly better than BeagleBoard VFP. NEON about the same as BeagleBoard?

Thanks for a very full explanation.

Re 13/3/2012: Impressive figures. I downloaded the fpa/softfloat version from the link provided plus updated my shared unix library to ver 1.11. Unfortunately I get a “No writable memory at this address” message come up when ever the povray absolute file is run/called. Could it be the OS on my BBxM also needs to be changed from 5.17 to 5.18?

Unfortunately I get a “No writable memory at this address” message come up

This often means the value of the Next slot is too small. Try increasing Next in the task manager.

Thanks Chris, bumped up WimpSlot -max from 2000k (for povray 3.1g) to 4000k (!) for the 3.6.1-1 version. Now getting cannot-find-file type errors. Making progress.

There’s a problem with one of the paths pointing to the wrong place. As a workaround you can create a folder ‘povray-3/6’ inside the !POVRay folder and copy the ‘include’ folder into this. This should stop the file not found errors.

Thanks for you advise Chris G, however it did not seem to make any difference in my case. I am running OS 5.17, maybe that has something to do with it.

I have managed to get POVray3.6.1-1 operational & this is what I did:
There are two files within the !POVray directory called povray/conf & povray/ini, POVray complains if it cannot locate these files. In a copy of !UnixHome (v1.03), located at $.!Boot.Resources I created within !UnixHome.home the following /povray.3/6 The two povray files were then copied into that last directory.

Leaving the $.!Boot.Resources dir open, I double clicked on $.!Boot then clicked on Boot, then on Look at. Click-dragged !UnixHome onto the scrollable section of the Boot at startup window. This app’s full pathname should now appear in this location. If all is well click the Set icons for both this window & the parent, Boot sequence, window.

After that I had only to create a generic obeyfile & ini-file to call & configure POVray then I was ready to go forth & render.

As far as benchmarks go, here are some comparative times for teapot 1024×768 +a0.3 +am1 +r3:
Pentium 3.2GHz Vista POV3.6.2 32 sec
BBxM MHz? RO5.17 POV3.6.1-1 425 sec
A7000+ RO4.02 POV3.1g 1208 sec

where can i download pov-ray 3.6.1 for risc os open 5?
The Homepge hasnt a download for risc os.

You can get to all the download on riscos.info here.

So according to those figures, a 1.2GHz Pandaboard using the Neon optimised version of POVray beats a 3.2GHz Pentium?

OK, so its a bit of a specific case, but still rather nice :-)

i have installed the program but clicking over the icon dosent make anything.

It’s command line only at the moment. Press ctrl-f12 and type povray.

it doesnt work it says no free mem or something similar.