@sundown


Here on G4@1131 I get 14,50 secs to render the blender pool scene...
So seems that X1000 was only 1,5x faster than G4 in that bench...

_________________
Simone"Tuxedo"Monsignori, Perugia, ITALY.

@vision

Quote:

And if my grandma had wheels, it would be a bicycle

Order one today. OS4 version of the test doesn`t support Altivec, so it can be
hardly called fair comparison, but yes everyone that has Altivec should use one as it boosts performance much more then MMX/SSE.

PA Semi also has it, it is just not enabled by software, so the PVR performance might also boost in this test when we have such Lame.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@Seiya

Quote:

i see I7 920 at 2,6 ghz much faster than i7 950 at 3 ghz

OS, RAM, board (FSB, chipset) and Blender version do their share of influence, even that CPU is crucial. These are the results and don`t feel that AmigaOS is beyond knowing how strong x86 CPUs are on paper compared to PPC. Lets see where single core X1000 and SAM460 will be (both not listed)

Last edited by vox on 02-Feb-2012 at 11:16 PM.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@cheesegrate

Quote:

I think you smoked too much, It has been explained time and time again by all the knowledgeble coders in the community, that smp on an amiga os is impossible without breaking compability. And if it dosn't run aos programs then its hardly amiga.

No, this is quite time where ganja is hard to find. Snowy icy season at least in Europe and not in country where its much legal to grow or shop.

I ve read about problems even I`am neither developer or programmer.

Even MOS planned move to sandboxing with A-Box to Q-Box transition?
Original Quark had goals of SMP.

So the MOS team decided to drop it because it brakes 68k compatibility, but maybe is possible to make such sandbox and leave to OS to schedule CPU time. It doesn`t have to be real SMP, performance boost would be if any kind of activation of 2nd core could be done.

We will see what kind of solution will be provided, even if its sandboxing.

Just mentioned it because it was also officialy mentioned as goal for OS4 and now is hardware worth doing it here. So there is much room for tests to improve in both software optimization for PA Semi (64-bit, Altivec) and dual core use.

The point of this is not to fight to death, but to say that currently we don`t see full potential of PVR as it can be up to 2-3 faster in main CPU use (mem results are great).

Contrary, these are unique single core tests of it in early phase of AmigaOS adaptation of it, so should be understood as that, while G4 has been around quite a while and reaches it max.

Last edited by vox on 03-Feb-2012 at 12:38 AM.
Last edited by vox on 02-Feb-2012 at 11:21 PM.

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@cheeesgrate

Quote:

@vox: I think you smoked too much

Last edited by djrikki on 02-Feb-2012 at 11:19 PM.

_________________

@vox

The lame test was usig Altivec according to the original poster. Thing is the PA6T is based on some intel design and not on a Freescale one. Freescale's Altivec of e600 is unreached for performance/clock.
And lame is not benefitting from the fast bus of the X1000, so it's not too surprising a G4 can outclass the PA6T in this discipline. Do other tests where Altivec is a lesser benefit but fast I/O is important and the X1000 will rule that test.

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

@djrikki

Quote:

I think you smoked too much

Seems like answer to everything, but isn`t

_________________
Future Acube and MOS supporter, fi di good, nothing fi di unprofessionals. Learn it harder way!

@Tuxedo

Quote:

Here on G4@1131 I get 14,50 secs to render the blender pool scene...So seems that X1000 was only 1,5x faster than G4 in that bench...

Looks like it just a difference in clock speed, not surprised.

_________________
Hate tends to make you look stupid...

@vox

yes its always who you know, the young people always know though :)

Re your statement well in that case it is AMP not SMP which is what all the wise devs have been saying all along. But let us not pretend os4 will magically get SMP.

Last edited by cheesegrate on 03-Feb-2012 at 03:36 AM.

_________________
"ICE CREAM, ICE CREAM!" - Speedball 2.

"Look behind you, a three-headed monkey!" - Monkey Island

@vox

It is very slow
Wazp3D is only software and no hardware

_________________
Amiga600/Vampire2/PrismaMegaMix

@smp

No one has detailed about why smp can not be done.

Surely it will be done. When, thats another question.

For x1000 sales it would be superb to see at least raw demo of aos4 smp/amp
asap.

Is it already working in alpha form @hyperion headquaters?

Last edited by KimmoK on 03-Feb-2012 at 09:29 AM.

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

I would suggest some test involving only hd video decoding, using MPlayer (better use "MUI-MPlayer" on OS4, to have comparable results).

mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none [file]

With say a 1080p H264 clip like: http://downloads.dvdloc8.com/trailers/divxdigest/prometheus-trailer.zip

The output will show the time spent in the video decoder.

On this test, the X1000 should show the true power of the PA6T, so please do it. :)


EDIT:
Here are my results from a Pegasos 2 and a Mac mini (that happens to have an uptime of 36 days), so i wouldn't mind other results to consolidate the values anyway. :)

Pegasos 2 / G4:
BENCHMARKs: VC: 153.620s VO: 0.021s A: 0.000s Sys: 2.313s =155.955s
BENCHMARK%: VC: 98.5032% VO: 0.0136% A: 0.0000% Sys: 1.4832% = 100.0000%

Mac mini 1.5GHz:
BENCHMARKs: VC: 84.626s VO: 0.009s A: 0.000s Sys: 0.679s = 85.314s
BENCHMARK%: VC: 99.1935% VO: 0.0111% A: 0.0000% Sys: 0.7954% = 100.0000%



And a bit off-topic, but on the Mac mini, with skiploopfilter=all, i get:
BENCHMARKs: VC: 69.425s VO: 0.009s A: 0.000s Sys: 0.679s = 70.113s
BENCHMARK%: VC: 99.0183% VO: 0.0134% A: 0.0000% Sys: 0.9683% = 100.0000%

Considering the clip duration is 69 seconds, the mac mini result gets rather interesting: it can actually decode the video stream in realtime. Of course, with additional audio AAC decoding and video blit, it wouldn't make it, but it's not *that* far away (the blitting routine is quite optimized in MPlayer).

And after a test with display enabled (using overlay output, -vo cgx_overlay):
BENCHMARKs: VC: 69.429s VO: 17.409s A: 0.000s Sys: 0.688s = 87.526s
BENCHMARK%: VC: 79.3235% VO: 19.8905% A: 0.0000% Sys: 0.7861% = 100.0000%

Last edited by Fab on 03-Feb-2012 at 11:06 AM.
Last edited by Fab on 03-Feb-2012 at 10:56 AM.
Last edited by Fab on 03-Feb-2012 at 10:56 AM.
Last edited by Fab on 03-Feb-2012 at 10:53 AM.
Last edited by Fab on 03-Feb-2012 at 10:51 AM.
Last edited by Fab on 03-Feb-2012 at 10:22 AM.
Last edited by Fab on 03-Feb-2012 at 10:21 AM.

@Fab

great idea :)
a good test .

_________________

@-Sam- Quote:

From previous posts I thought I would be able to put in a CD32 CD and play it - not so. There doesn't seem to be UAE or RunUAE built in as I was expecting. I have downloaded UAE but it doesn't run CD32 discs.

You need to install RunInUAE, which is an *optional extra* that you have to install (if you don't choose to install it at the time OS4 is installed), because it is a "Third Party Contribution" (i.e. not developed by or for Hyperion).

You should have an "Extras Installer" (or similar) on the very left of your AmiDock (which is at the bottom of the screen). If it is not there for some reason, then it can be found in the iconless folder Sys:Utilities/InstallExtras/ (go into Sys:Utilities, use the menu "Window > Show > All files", and then go into InstallExtras). In the worst case, you can just download RunInUAE from OS4depot.net (it is not QUITE the same version, and until a new version is released it will cause minor problems on the X1000, so I do NOT recommend using that except as a last resort).

Last edited by ChrisH on 03-Feb-2012 at 12:03 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@Fab

Quote:

Fab wrote: I would suggest some test involving only hd video decoding, using MPlayer (better use "MUI-MPlayer" on OS4, to have comparable results). mplayer -benchmark -nosound -ao null -vo null -lavdopts skiploopfilter=none [file] With say a 1080p H264 clip like: http://downloads.dvdloc8.com/trailers/divxdigest/prometheus-trailer.zip The output will show the time spent in the video decoder. On this test, the X1000 should show the true power of the PA6T, so please do it. :) EDIT: Here are my results from a Pegasos 2 and a Mac mini (that happens to have an uptime of 36 days), so i wouldn't mind other results to consolidate the values anyway. :) Pegasos 2 / G4: BENCHMARKs: VC: 153.620s VO: 0.021s A: 0.000s Sys: 2.313s =155.955s BENCHMARK%: VC: 98.5032% VO: 0.0136% A: 0.0000% Sys: 1.4832% = 100.0000% Mac mini 1.5GHz: BENCHMARKs: VC: 84.626s VO: 0.009s A: 0.000s Sys: 0.679s = 85.314s BENCHMARK%: VC: 99.1935% VO: 0.0111% A: 0.0000% Sys: 0.7954% = 100.0000% And a bit off-topic, but on the Mac mini, with skiploopfilter=all, i get: BENCHMARKs: VC: 69.425s VO: 0.009s A: 0.000s Sys: 0.679s = 70.113s BENCHMARK%: VC: 99.0183% VO: 0.0134% A: 0.0000% Sys: 0.9683% = 100.0000% Considering the clip duration is 69 seconds, the mac mini result gets rather interesting: it can actually decode the video stream in realtime. Of course, with additional audio AAC decoding and video blit, it wouldn't make it, but it's not *that* far away (the blitting routine is quite optimized in MPlayer). And after a test with display enabled (using overlay output, -vo cgx_overlay): BENCHMARKs: VC: 69.429s VO: 17.409s A: 0.000s Sys: 0.688s = 87.526s BENCHMARK%: VC: 79.3235% VO: 19.8905% A: 0.0000% Sys: 0.7861% = 100.0000%

Here the result from the X1000.

BENCHMARKs: VC: 82.849s VO: 0.006s A: 0.000s Sys: 6.697s = 89.552s
BENCHMARK%: VC: 92.5151% VO: 0.0062% A: 0.0000% Sys: 7.4787% = 100.0000%

_________________
Amiga600/Vampire2/PrismaMegaMix

@sundown

Quote:

sundown wrote: @Seiya Quote: you should try blend.test from blender site :) I have it, but blender needs a gfx card with miniGL support as that benchmark requires it & that file can't be run in a shell. It will run with an old PCI gfx card, but those are slow, so not a true test for blender. Same goes for using Wasp3D, it would be just as slow or slower then an old gfx card. We just have to wait for the new gfx driver before testing blender speed, & since thats part of 4.2, it won't get reported.

GFX driver DOESN'T affect on raytrace rendering speed since it's used only for output, not on actual rendering.

@tommysammy

The time spent for I/O (Sys:) is a bit high (maybe you have a fragmented disk or no DMA yet). Anyway, if we substract it and only consider video decoding time (VC), this gives 82.8s for X1000 against 84.6s for Mac mini.

Can you tell me which archive of mplayer you used? To be sure altivec was indeed used (though it would "only" make a 20-25% difference, from what i remember, not as much as what we can see with LAME).

@Fab

I can tell you,that i have tested it with AmigaOS4.1.5 FC
We dont`t have there overlay ,DMA and hardware acceleration
I will check which version i have took

_________________
Amiga600/Vampire2/PrismaMegaMix

@Fab

Quote:

this gives 82.8s for X1000 against 84.6s for Mac mini.

Interesting results!

I remember MorphOS version of MPlayer was rougly 1.4x faster than OS4 version in the Obligement test (on Pegasos II). However, that was nearly 3 years ago.

@Fab

It was generic

Last edited by tommysammy on 03-Feb-2012 at 05:14 PM.

_________________
Amiga600/Vampire2/PrismaMegaMix