@broadblues

I can point you to this thread in which there are talks about altivec recompilations of Blender

_________________
PowerMac G5 2,7Ghz - 2GB - Radeon 9650 - MorphOS 3.14
AmigaONE X1000, 2GB, Sapphire Radeon HD 7700
FPGA Replay + DB 68060 at 85Mhz

@bernd_afa

Yes, we need more benchmarks about PA6T. I hope it's better testable around next summer.

But I doubt PA6T is much behind G4 per Mhz per core. If it's slower at all.

I think PA6t could be the best PPC we can have nowdays, if the chip source/manufacturer is reliable enough. It would have enough performance for anything I can imagine on a modern desktop (+I hope we get the OpenCL one day).

offtopic: DesignCon February 1 – 4, 2010, perhaps we hear more after that.

Last edited by KimmoK on 26-Jan-2010 at 08:31 PM.

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

Quote:

Tuxedo wrote: @jPV Nice results! just for curiosity...tested same Blender versions on MacOSX?

Well.. I don't have OSX on that 1.5GHz mini, but here's the results on Mac mini 1.42GHz with Blender 2.46:

OSX Tiger: 06:44:49
MorphOS: 06:49:29

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

On Blender2.5alpha0 and MorphOS/MacMini-1.5GHz/64MB, I can't render below 6'27'' (by playing a bit with process/thread priorities).

I'm currently trying to build using same options as given in the thread given by K-L.
I'll giving my results when it's build.

[edit]
Not better.. same kind of time (between 6' and 7'). My build was already compiled with -maltivec. I've just added -mtune=G4, but it don't bring some much to the renderer engine.

So, I'm trying to re-write by hand some routines directly in Altivec: I think GCC is not able to introduce clever Altivec code by itself.

Last edited by Yomgui on 27-Jan-2010 at 08:44 AM.

@Karlos

>There are SSE2 optimisations available. Apple produced some fairly detailed >documentation on how to migrate altivec code to SSE, I wonder if it could be >applied in reverse as a hint as to what to optimise and how?

The problem of PPC altivec is it is too unprecise for very complex and accurate calculation because it can only use 32 bit float at maximum.

when use the FPU and use 32 bit float then you have too only 32 bit, but inside the FPU the calculation is still more than 32 bit.But with altivec you get every calculation step a round to 32 bit.when use SSE2 (which can use 64 bit float) you get only when store the float to ram a 32 bit the round.

@bernd_afa

I've seen real-time ray tracing demonstrated on GPU using only 32-bit precision arithmetic that wasn't even completely IEEE754 compliant, so I don't think the precision is as much of an issue for this particular application.

_________________
Doing stupid things for fun...

@bernd_afa:

Please check Blender code first: many rendering code use 'float' ... yep, single precision!
SSE optimiz is simple precision also (_mm_xxx_ps()).

Some of parts have been ported to double. but not everything... and somethime they mix everything (bad).

But yes, some builds exist for 64bits machines also, but it's only compiler flags, not the code.

Last edited by Yomgui on 27-Jan-2010 at 02:15 PM.
Last edited by Yomgui on 27-Jan-2010 at 02:12 PM.

@Yomgui

>Please check Blender code first: many rendering code use 'float' ... yep, single >precision!

yes, but seem you not understand what i mean.

when for example the CPU load some float data and calculate the CPU registers calc in 64 bit see here the little PPC example

lfs fr0,scalevalue(r2),
lfs fr1, coord(r2)
fmul fr0,fr1,f1 --> result is 64 bit precision.
lfs fr0,pan(r2)
fadd fr0,fr1,fr1 --> still 64 bit precison
lfs fr0,screenscale(r2)
fmul fr0,fr1,fr1 ->still 64 bit precision.
sfs result(r2),fr1 ->only here truncate to 32 bit precision.

so when you do the calculation with altivec you loose accuracy on every calculation step.

And this can result as can see often in PC games in Gaps between polygons.

32 bit float have only exact number of 7 digits.(24 bit mantissa 8 bit excponent)

this mean when have number
1024.456

all numbers behind the 6 are unprecise.and when round every calc operation give lots inaccuracy thats maybe good enough for a game but not for a animation,

Last edited by bernd_afa on 27-Jan-2010 at 07:06 PM.

@bernd_afa

What you are describing are errors in geometry transform for setting up a scene. That's fine, for rendering you'd use double precision for that if you wanted perfection in terms of vertex placement and the like.

However, that's only a small part of the rendering process. Ray tracing can use double precision to work out where a ray intersects a surface but it doesn't really need it for the most part (edges probably benefit though). Beyond that, most of the calculations performed for the ray involve calculating the amount of a given colour a particular surface contributes to a pixel after a ray originally cast from the "camera" through that pixel has eventually reached that point on the surface in question (perhaps after many bounces along the way). 32-bit floating point values of R/G/B are more than adequate for this process and it's the actual ray tracing that takes the majority of the time.

Last edited by Karlos on 27-Jan-2010 at 07:25 PM.

_________________
Doing stupid things for fun...

@thread

Still no Amiga benchmarks...

_________________
AmigaOne X1000

here with Pegasos2 G4@1000, 2gb ram, ATI Radeon 9250 AGP, OS4.1.1, time 09:45.60 :)

@ddni

Quote:

ddni wrote: @thread Still no Amiga benchmarks...

I posted a benchmark on that site the day blender was released.. It is still not there, so i guess they dont like us Amiga users.

Acer TM 5720 duel core Laptop
Intel Core2Duo CPU, T7100@1.80GHz (10.0x179.6 QDR), L1 2x32+32kb(d+i), L2 1x2048kb, 3.3V
System Bus Clock : 718.3 Mhz
FSB : 179.6 MHz QDR
Intel PM965/GM965/GL960 Express Processor to DRAM Controller (PCI/PCI-e)
Intel 82801HEM(ICH8M-E)LPC Interface Controller (Southbridge)(PCI-e 1.x, 2.5GB/s)
Intel PM965/GM965/GL960 Express Integrated graphics controller (384MB)
Memory Unbuffered 64bit(x16) 2GB, 2x1024MB DDR2-666 SDRAM CAS 5.0, 3ns/667Mhz
CL-tRCD-tRP-tRAS:5.0-5-5-15,tWR-tRC:5-20,Access Time 0.5ns (Crucial)

32bit Windows 7

Default Blender 2.49b
1 thread 00:04:06.10
2 thread 00:02:16.62
4 thread 00:02:11.79

OpenGL Viewport optimization 1091_VBO_r22296
1 thread - 2.13M - 00:05:56.02

Blender-2.49b SVN 24633 Py 2.6.4 - gcc- Nocona SSE3 LAA fast-math
1 thread 1.09M 00:03:10.26
2 thread 1.16M 00:02:15.53

Other link:
http://burp.renderfarming.net/

PS: My processor speed 1.8GHZ and 2 core makes for a good compare against AmigaONE X1000

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)

@Tomas

WIntel conspiracy!

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Karlos

Quote:

Karlos wrote: @bernd_afa I've seen real-time ray tracing demonstrated on GPU using only 32-bit precision arithmetic that wasn't even completely IEEE754 compliant, so I don't think the precision is as much of an issue for this particular application.

NVIDIA CUDA 1.0/1.1 device.

NVIDIA CUDA 1.3 device and ATI RV670 (and later) includes DP FP.
ATI RV870 (and later) has IEEE754-2008.

Sony Vaio VGN-FW45GJ laptop
Intel Core 2 Duo P8700 2.53 Ghz (25 watts)
-----------------
Windows 7 X64 + Blender 2.5.15 Alpha 0
Time: 00:57.41, CPU 1
Time: 00:31.65, CPU 2

Last edited by Hammer on 28-Jan-2010 at 11:32 AM.
Last edited by Hammer on 28-Jan-2010 at 11:19 AM.
Last edited by Hammer on 28-Jan-2010 at 11:10 AM.
Last edited by Hammer on 28-Jan-2010 at 10:42 AM.
Last edited by Hammer on 28-Jan-2010 at 10:36 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@ddni

At least there is an entry for MorphOS G4/1000 on that page since ages. Somewhere at about #3500 or so (~10 mins)...

_________________
My programs: via.bckrs.de
MorphOS user since V0.4 (2001)

@Hammer

Quote:

NVIDIA CUDA 1.3 device and ATI RV670 (and later) includes DP FP.

Yes, I know. I've been messing with CUDA on my GTX260 , which is a compute 1.3 class device, ever since I got it over a year ago.

What the table doesn't tell you is that double precision on the G200 is 8x slower than single precision since all double precision ops are carried out by a separate unit in each of the shader cores. Furthermore, the G200 is not fully IEEE754 compliant, meaning you don't always get the expected results when performing calculations compared to a "gold" standard carried out on the CPU.

The Fermi (G300) is the first CUDA capable device designed to address these issues. All of the shader cores are fully double precision capable and IEE754-2008 compliant. Furthermore, it uses ECC to ensure reliability. None of the earlier GPUs have this as frankly it isn't essential for graphics applications.

Last edited by Karlos on 28-Jan-2010 at 11:29 AM.

_________________
Doing stupid things for fun...

@Karlos

ATI RV870 is also fully double precision capable, IEE754-2008 compliant, includes Error Detection Code (EDC) and available since Q4 2009.

"ATI has now turned on GDDR5’s Error Detection Code (EDC) similar to ECC in DRAM. This allows GDDR5 modules to reach higher frequencies while reducing errors. This could help make video cards as a whole more stable and robust, especially as you clock memory frequencies higher" (1)

1. http://www.hardocp.com/article/2009/09/22/amds_ati_radeon_hd_5870_video_card_review/5

This error correction method was used for overclocking i.e. for playing games at O/C.

Last edited by Hammer on 28-Jan-2010 at 11:50 AM.
Last edited by Hammer on 28-Jan-2010 at 11:49 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Zylesea

"At least there is an entry for MorphOS G4/1000 on that page since ages"

i havent found that yet, but found this and wtf?:

08:36.95 - Apple Power Macintosh G4 1000MHz - MorphOS 1.4.3

pardon me?:)

If you sort the table by date you'll see that the page is updated almost daily (there are entries every day from 23rd to 28th January 2010), so that seems to suggest some problems with our entries. I'll try to contact the page maintainer about the matter.

Varthall

Last edited by Varthall on 28-Jan-2010 at 03:49 PM.

_________________
AmigaOne XE - AmigaOS 4.1 - Freescale 7457 1GHz - 1GB ram