POVRay - Come to Fish Together | page 1 2 3 4 5
|
---|
|
---|
| | Kymon Erec Zonias
Posts 7 29 Jan 2021 13:11
| Hi Darren. I know that the MatzeTK060 runs sufficient at 90MHz (atm). Did you read my Tip regarding the OxyronPatcher 3.14. or in your Case you can even use the CyberPatcher. This should give you more realistic numbers. Regards. Darren Eveland wrote:
|
Henryk Richter wrote:
| A good old 68060 is still able to give a good punch. Total Time: 0 hours 25 minutes 54.0 seconds (1554 seconds) EXTERNAL LINK |
Interesting this result is more than 2x faster than my 100MHz 060 on my Cyberstorm MK2. It must be that povray is very memory intensive, because with the same clock speed the only difference is that the Matze TK060 has much faster memory interface than a CS MK2 with the 100MHz hack (memory running @ 50MHz). Does the TK060 run it's memory @ 100MHz?
|
| |
| | Darren Eveland
Posts 103 29 Jan 2021 20:29
| Yes thanks, I'm going to try with CyberPatcher and OxyPatcher, hopefully to get better numbers. I have to re-install that system first as I am getting lots of errors/freezes due to SFS. It's an old hard drive in there and it has been formatted using SFS. I'm going to re-do the drive with Coffin (hopefully) but it will take some time. If I can get it to boot stable first I may try a re-test with at least Cyberpatcher as I do have that on the system.
| |
| | Henryk Richter (Apollo Team Member) Posts 128/ 1 30 Jan 2021 10:09
| The TK060 is a fully synchronous design: both towards the mainboard and also the installed 6ns SDRAM. That's why it is somewhat limited in terms of clock speed settings (currently either 50 or 100MHz) but also explains why it reaches faster mainboard access and better memory performance than other 060 cards. There is a 68060 binary of POVRay 3.1 available. That one (which I've used) eliminates the need for the likes of Cyberpatcher/OXYPatcher/MuRedox. Those are useful with Lightwave, though.
| |
| | Andy Hearn
Posts 374 03 Feb 2021 14:30
| aha. an 060 specific version of povray31. ok cool. downloaded that from povray.org and ran the povray benchmark... V1200 G2.13 RC3 build 7717 core x12 @85Mhz:- 060 version 24mins and 02 seconds FPU version 23mins and 53 seconds (the version on coffin) guessing the FPU version has a more complete FPU instruction set to play with, hence slightly faster on a CPU that can support it? will get some true 060 numbers with the 060 version in due course.
| |
| | Darren Eveland
Posts 103 04 Feb 2021 03:54
| Where do you download the 68060 version of POVray? I can't find it on Aminet or on the web....must be blind. Thanks Darren
| |
| | Andy Hearn
Posts 374 04 Feb 2021 11:31
| no worries :) main site EXTERNAL LINK old versions - you want 3.1 as that's the last Official Amiga release set of archives EXTERNAL LINK there is a "no-fpu" version there too as well as fpu/040/060 versions, so have ordered an A1200 ramcard that should be arriving today to generate some "stock A1200/020" numbers. should be amusing. i may have to run a "drive click silencer" so the wife doesn't go mad with it running for... i'm guessing *days* to do this :D
| |
| | Andrew Miller
Posts 352 04 Feb 2021 13:32
| Or you could just put a blank disk in.
| |
| | Darren Eveland
Posts 103 05 Feb 2021 19:30
| Thanks found it. Will test!
| |
| | Andy Hearn
Posts 374 09 Feb 2021 20:06
| A1200 EC020@14Mhz 882@40Mhz, 8Meg fast ram povray31 fpu version off coffin r58, but booted of a workbench3.1 floppy to maximize ram - compared to a full r58 boot 13hours, 7minutes, 31secondsam going to try the "nfp" integer version. but given the first time i tried it, didn't do anything for a few days - i don't hold out much hope.
| |
| | Markus (mfro)
Posts 99 26 Feb 2021 08:31
| Renaud Schweingruber wrote:
| Ran with those parameters : povray31fpu +A +W720 +H486 +Ipovray31:scenes/advanced/fish13/fish13.pov +Lpovray31:scenes/advanced/fish13 +Oram:test.tga Anyone can run it with other Moto's CPUs ? |
Sure. Firebee (ColdFire v4e m5474@264MHz, running latest FreeMiNT):
Total Scene Processing Times Parse Time: 0 hours 0 minutes 1 seconds (1 seconds) Photon Time: 0 hours 0 minutes 0 seconds (0 seconds) Render Time: 0 hours 15 minutes 45 seconds (945 seconds) Total Time: 0 hours 15 minutes 46 seconds (946 seconds)
| |
| | Grzegorz Wójcik (pisklak (Apollo Team Member) Posts 87 26 Feb 2021 09:05
| I think that 68080 might be the fastest available CPU core that can run inside low cost FPGAs. Interesting would be comparasion of other cores (MicroBlaze/PicoBlaze/Leon and some OpenCores CPUS)rendering the same scene in POVray :) BTW. Nice Firebee score. Prehaps in new generation of FPGAs 080 can reach that high clock. 260 Mhz 080 would rock !
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 26 Feb 2021 09:34
| Markus (mfro) wrote:
| Sure. Firebee (ColdFire v4e m5474@264MHz, running latest FreeMiNT):
|
Running a different binary and on a different OS makes it useless as benchmark. Where do you know that the OS or the different binary not make this score?
| |
| | Markus (mfro)
Posts 99 26 Feb 2021 09:42
| Grzegorz Wójcik (pisklak wrote:
| ... BTW. Nice Firebee score. Prehaps in new generation of FPGAs 080 can reach that high clock. 260 Mhz 080 would rock !
|
Not entirely sure results are 100% comparable as I only have povray 3.6 available (maybe somebody could try this version on a V4?).Wanted to upload the resulting image for illustration also - how am I supposed to do that on this forum?
| |
| | Markus (mfro)
Posts 99 26 Feb 2021 09:46
| Gunnar von Boehn wrote:
| Where do you know that the OS or the different binary not make this score?
|
I do not, certainly (see my other post). But that wasn't requested - it was only requested to provide scores for other m68k - that's what I did. (and I apologise if the result doesn't really suit you)
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 26 Feb 2021 09:58
| Markus (mfro) wrote:
| Not entirely sure results are 100% comparable as I only have povray 3.6 available
|
I think we can assume that using a different version of the program will give different scores. And even using the same version, with a different compiler or just different compile flags can result in major differences. Actually we have seen the big effect of the compiler just recently. Last when working on our OS, compiling our Apollo-OS SDCARD driver with a different GCC version. One GCC version reached a performance of 1.5 MB/sec SDCARD speed - and another version of GCC reached 4.6 MB/sec SDCard speed. As you see the impact of the compiler was enormous here. 3 times faster or 3 times slower just by using another compiler! I think you need to use the same binary - if you want to see the CPU part. If you want to compare different cars then you need to run them on the same race track - running different cars on different tracks make comparing impossible.
| |
| | Markus (mfro)
Posts 99 26 Feb 2021 10:18
| Of course you are right in general, but I wouldn't assume huge effects with different compiler versions or different povray versions with that complex piece of software that povray is (at least I didn't hear about any huge performance gains with latest povray releases, otherwise everybody would use them). If you look at the numbers available, they pretty much scale with CPU frequency. I agree, there are sometimes huge differences when it comes to tight loops moving data (as I would assume you observed in your SD card example) but unfortunately it appears that later gcc versions are even getting worse regarding possible m68k optimizations. At least that's my personal experience, gcc 2.95 was a lot more willing to generate optimized movem.x sequences or dbra instructions while later versions need to be tricked to do so. What troubles me a little is that you come up with your arguments only after there is some better score showing up - apparently it didn't bother you before?
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 26 Feb 2021 16:50
| Markus (mfro) wrote:
| Of course you are right in general, but I wouldn't assume huge effects with different compiler versions
|
Its just a fact that compilers can have huge impact. Just look at Aminet and download there some different LAME EXEs and compare their MP3 encoding time. The different compile LAME version have huge performance difference created by different compile flags and different compilers. Markus lets by clear here. Such benchmark makes only sense when all use the same executable.I find it little strange that you question this even.
| |
| | Markus (mfro)
Posts 99 26 Feb 2021 17:40
| I don't even know which compiler version was used to create the Amiga executable, so this is all just speculation anyway. We don't really need to argue about a minute better or worse when my Linux machine can do the fish in less than two seconds ;)
| |
| | Gunnar von Boehn (Apollo Team Member) Posts 6258 26 Feb 2021 21:45
| Markus (mfro) wrote:
| I don't even know which compiler version was used to create the Amiga executable, so this is all just speculation anyway.
|
Markus the point of the benchmark is that all run the same EXE. Running a different EXE is only one thing = cheating. You should know this.
Markus (mfro) wrote:
| We don't really need to argue about a minute better or worse when my Linux machine can do the fish in less than two seconds ;)
|
You sound like someone who was caught cheating and now tries to make all kinds of silly excuses. - You did not know the exact version - You did not know the used compiler - You did know that different compiler make different code. It would be nice if you can stop this.
| |
| | Andy Hearn
Posts 374 23 Mar 2022 17:58
| Icedrake (8695x12), coffin r59 total time 24 minutes 28 seconds V1200V2 (8594x12), coffin r59 total time 25 minutes 25 secondsIcedrake (8690x15), coffin r59 total time 20 minutes 29 seconds
| |
|