Until there are some reasonable benchmarks with actual software that depends on the FPU, it's somewhat academic. I don't expect greatness from anything approximating trap and emulate but perhaps that isn't how it works. If it's implemented by trap and patch, similar to say oxypatcher, then it might not be as bad.

Obviously candidates for test would be any 3D games, blender, that sort of thing.

_________________
Doing stupid things for fun...

@Karlos

Judging by guide posted in another thread, 3D games (Quake, Jedi Knight) are unplayably slow, if they work at all. There are also some performance problems with AmiCygnix. Most other software apparently doesn't stress FPU that much, so speed may be fine.

@Karlos

yes and yes, it also recompiles it when it when its loaded, but that does not allways work, so there is a black list

Last edited by NutsAboutAmiga on 22-Jul-2023 at 11:10 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Karlos

Quake used a special trick, it depended on FPU and CPU working in parallel, I don’t see that being possible when the SPE is using the same registers as the CPU, but maybe code can be optimized for SMTD instructions to leverage parallelism this way. In that case the code needs to be rewritten. in that case benchmarking a none optimized std PPC game, does not really tell you anything, because it’s all relative. The bigger question I have is, who is going to optimize everything.

If this product is just going to be dumped into the market, then I can only hope there will be new people who are able to optimize code, and are willing to spend the time to do it, who are going to buy it.

Last edited by NutsAboutAmiga on 22-Jul-2023 at 11:46 AM.
Last edited by NutsAboutAmiga on 22-Jul-2023 at 11:31 AM.
Last edited by NutsAboutAmiga on 22-Jul-2023 at 11:23 AM.
Last edited by NutsAboutAmiga on 22-Jul-2023 at 11:21 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Kronos

Quote:

Digging an extra foot into the hole you are stuck in is the exact opposite of "a fresh start". That would have required to ditch the Tabor at some point in the past to make place for someone/something going into a different (less brain farty) direction.

A series of errors have lead to Tabor failing to achive it's goal of providing a lower cost of entry for OS4.

1. Starting a new hardware project when the X5000 wasn't out of the door and fully supported.

2. Choosing an SOC that the Amiga user base had already warned against a few years earlier when the Ultimate PPC project was first revealed.

3. Not getting all 1000 boards made when they had the opportunity to do so at a unit price of under $300 + the price of the P1022.

@NutsAboutAmiga

Quote:

As for the FPU emulation, I guess developers worked on it learned something from it.

Yes, that full hardware FPUs are faster and less hassle!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hammer
Quote:

FYI, my user name was named after AMD's K8 codename i.e. Sledgehammer. Sledgehammering PowerPC bots is my favorite pastime.

AMD, Intel, it's all the same crap to me.

@Kronos
@Rob

Ok, maybe it will never be a win, but maybe some thing might come from it and a few systems may bring some joy.

The real issue as I mentioned is that the OS/development environment/apps are just stagnant. That is the real issue to me. Worrying about dual processor support and other fancy things, should be done after you have a better offering.

Maybe its me, I would much prefer, email, web browser, crm, dtp, and other productivity native apps. There are lots of games to choose from for sure, not anything else and that dimishes what you can do with it. I think Homebank is one of the few shining examples of a native app thats really good and bespoke to OS4. Sure some of the old 68k stuff can get the job done, but not well in most situations.

In a funny way it reminds me of when the Amiga was first released, it needed a lot of apps to make it useful, and that took a bit to see that.

@Matt3k

Quote:

Matt3k wrote: ... The real issue as I mentioned is that the OS/development environment/apps are just stagnant. That is the real issue to me. Worrying about dual processor support and other fancy things, should be done after you have a better offering. ...

On this, you and I are in violent agreement. Software should be the focus.

_________________
All the way, with 68k

@agami

I would think by now, this product (AmigaOS 4) would be tied to an actual viable platform that doesn't cost an arm and a leg, and which if not died already is on the verge of dying and driving even more the costs up, still people still seem to see it as the only viable platform... which is sad. how cool and we'll placed would it be to have it running in a tiny little raspberry pi board, where one could play to its strengths!

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

@Karlos

Quote:

Obviously candidates for test would be any 3D games, blender, that sort of thing.

The illustrious spinning cow manages a dizzying 83fps on my machine.

EDIT: 83 fps is with the Warp3D version. The Warp3D Nova variant spins the cow at ~2010 fps.

Games that have been compiled for the SPE (e.g. ,Tower57) do perform well. We can't expect everyone to make SPE variants of their games, though.

@NutsAboutAmiga

Quote:

yes and yes, it also recompiles it when it when its loaded, but that does not allways work, so there is a black list

The load time emulation is faster than the trap based emulator. However, it'll never be able to come close to native performance. The SPE uses the same GPRs used by the integer unit (extended to 64-bit). So, it has to branch out to the emulated instructions, save any registers that it uses, load the FPU registers from a virtual register set in RAM, and then it can perform FPU operations. Then the original registers need to be restored before branching back out of the emulated code.

I personally think a full on JIT recompiler would be the best way forward. As a bonus, it might open up the possibility to recompile to another ISA later...

@Matt3k

Quote:

The real issue as I mentioned is that the OS/development environment/apps are just stagnant. That is the real issue to me. Worrying about dual processor support and other fancy things, should be done after you have a better offering. Maybe its me, I would much prefer, email, web browser, crm, dtp, and other productivity native apps. There are lots of games to choose from for sure, not anything else and that dimishes what you can do with it. I think Homebank is one of the few shining examples of a native app thats really good and bespoke to OS4. Sure some of the old 68k stuff can get the job done, but not well in most situations.

Yes, more apps are very much needed.

Hans

Last edited by Hans on 23-Jul-2023 at 11:40 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Matt3k

Just giving an honest appraisal of the current situation. I really do hope that manage sell well enough for A-EON to make back their investment but it's going to be more difficult due to the passage of time and the icreased price over that which was origonally projected.

From a performance perspective it seems like a capable system from the videos I've seen of it in action. Dan's videos of SPE versions of his games show a big peroformance boost over Sam460. Also in the comments under the EntwicklerX video it's mentioned that programs with little or no FPU code can run upto 60% faster on A1222. With the right video card you also get the ability to play 4K video.

I think it will be a nice system for those prepared to pay the asking price.

@Hans

Does Nova perform the T&L on the GPU?

_________________
Doing stupid things for fun...

@Hans

Quote:

I personally think a full on JIT recompiler would be the best way forward. As a bonus, it might open up the possibility to recompile to another ISA later

I suggested the idea of 68K => 68060 JIT on EAB recently, based on the historic precedent set by Dynamo on the PA-RISC 8000. It was a thought experiment and got some pretty mixed (but mostly skeptical) responses.

_________________
Doing stupid things for fun...

@Karlos

Paying with outer performance hits, like having to flush JIT cache & instruction cache, and regenerate code, the problem with JIT is unexpected performance hits at random places.

perhaps, if its only on application per application bases, it be useful improve speed of the worst performing applications.

I guess its harder on 680x0 as has different length of instructions, so JIT compiler will actually need to know all instructions, while PowerPC to PowerPC jit, can ignore almost all instructions as they all are 4bytes long.

Last edited by NutsAboutAmiga on 23-Jul-2023 at 08:09 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@Karlos

Quote:

Does Nova perform the T&L on the GPU?

Yes. Hence the huge performance difference.

Quote:

I suggested the idea of 68K => 68060 JIT on EAB recently, based on the historic precedent set by Dynamo on the PA-RISC 8000. It was a thought experiment and got some pretty mixed (but mostly skeptical) responses.

My biggest question would be whether there are enough 68060's and software needing a JIT to make the whole effort worthwhile. From a technical standpoint, a well written JIT can sometimes generate code fr a specific CPU that's faster than code statically compiled for the same ISA (but intended to run on any CPU model).

Quote:

Paying with outer performance hits, like having to flush JIT cache & instruction cache, and regenerate code, the problem with JIT is unexpected performance hits at random places.

Isn't that only a problem for self-modifying code?

Quote:

I guess its harder on 680x0 as has different length of instructions, so JIT compiler will actually need to know all instructions, while PowerPC to PowerPC jit, can ignore almost all instructions as they all are 4bytes long.

Unfortunately, the PPC to PPC SPE JIT would have to process everything (from at least he first FPU instruction it encounters). The SPE uses the GPRs instead of a separate FPU register file, so the JIT has to redo the register allocation.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

From a technical standpoint, a well written JIT can sometimes generate code fr a specific CPU that's faster than code statically compiled for the same ISA (but intended to run on any CPU model).

You should read the papers, they are quite interesting.

The speedup you get if you do for example 68k JIT re-compile to 68k (or any other ISA onto itself for that matter) is not due to the re-compiler having a better code-generator but rather that at run-time you have a lot more data available to you to optimize code-flow than you have at compile-time.


For example, in the sources you may have a conditional. A classic compiler needs to generate code to implement this conditional which is then evaluated and run every time that code is executed.
But at runtime it may be that the condition is never true so the JIT can simply delete all that code.

This means less code to execute which is obviously faster. It also means smaller code which means better utilization on instruction cache.

I.e. think of it as dead-code removal but it is done at run-time. It is actually a genuinely brilliant idea.
This is one optimization that you can do at run-time but not at compile-time. There are others too.

Last edited by V8 on 24-Jul-2023 at 09:11 AM.
Last edited by V8 on 24-Jul-2023 at 09:01 AM.
Last edited by V8 on 24-Jul-2023 at 08:59 AM.

@ppcamiga1

Quote:

ppcamiga1 wrote: So 68k trolls I want to give 68k a chance. I want nothing special just something that was standard 25 years ago. Show Me where can I buy 68k Amiga computer with: - 68k cpu with speed at least 90 Pentium - real 68k cpu no emulators - 68k cpu only no other cpu - working compatible MMU - working compatible FPU - 2D at least as fast as S3 PCI cards - 3D at least as fast as VooDoo 1 Whole 68k Amiga computer Under 1500 Euro. Show where can I buy such thing or accept that Amiga NG was success.

1. The "Commodore-Amiga" is more than just the DraCo's only "AmigaOS 3.1 68K" half-Amiga clone. Look in the mirror with your own hypocrisy.

2. The "big core" 68K clone is AC68080 V2 and it exceeds the Pentium 90 i.e. AC68080 V2 and V4 are in the Pentium MMX era.

3. The real 68060 has a dual instruction decoder front end that translates variable 68K complex instructions into fixed-length RISC counterparts. AC68080 effectively evolved from the canceled 68060B project.

Emu68 is a single-task bare-metal decoder software implementation for the ARM CPU core that is closer to Transmeta's Code Morph Software approach's bare-metal X86-to-VLIW translation approach. Emu68 bare-metal doesn't have host Linux OS overheads.

The Amiga market doesn't have $$$$ to customize a powerful ARM out-of-order big CPU RISC core with a 68K front end.

AMD K12 is an ARMv8-A (AArch64) clone that recycled Zen R&D.

https://www.notebookcheck.net/Zen-architecture-pioneer-Jim-Keller-feels-AMD-was-stupid-to-cancel-the-K12-Core-ARM-processor.629843.0.html

Jim's plan with the K12 was to work on a new decode unit since the cache and execution unit design for ARM and x86 were almost similar, but AMD had other plans after he left


https://www.youtube.com/watch?v=OvgdU5FkG-0&t=1525s
In the talk, available online via YouTube, Keller discusses how when planning the Zen 3 core – he and other engineers realized that much of the architecture was very similar for Arm and X86 "because all modern computers are actually RISC machines inside," and hence according to Keller, "the only blocks you have to change are the [instruction] decoders, so we were looking to build a computer that could do either, although they stupidly canceled that project."


Due to AMD CPU's chiplet design, AMD could easily replace X64 Zen CCDs with ARM clone Zen CCDs.

AMD's re-entry into the ARM market is with a partnership with Samsung's Exynos 2200 (with RDNA 2) and incoming Exynos 2300 SoC (with RDNA 3).

4. S3 Trio 64U 2D performance target is easy for PiStorm Lite RPi 4B's Broadcom VI P96 RTG.
Phase 5 CyberVision 64 (S3 Trio 64U) is limited by Zorro III bus.

Eat that.

Last edited by Hammer on 25-Jul-2023 at 07:18 AM.
Last edited by Hammer on 25-Jul-2023 at 03:45 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)

@toRus

Quote:

toRus wrote: @Hammer Quote: FYI, my user name was named after AMD's K8 codename i.e. Sledgehammer. Sledgehammering PowerPC bots is my favorite pastime. AMD, Intel, it's all the same crap to me.

Offer an alternative.

_________________
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)

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @Karlos Quake used a special trick, it depended on FPU and CPU working in parallel, I don’t see that being possible when the SPE is using the same registers as the CPU, but maybe code can be optimized for SMTD instructions to leverage parallelism this way. In that case the code needs to be rewritten. in that case benchmarking a none optimized std PPC game, does not really tell you anything, because it’s all relative. The bigger question I have is, who is going to optimize everything. If this product is just going to be dumped into the market, then I can only hope there will be new people who are able to optimize code, and are willing to spend the time to do it, who are going to buy it.

Quake also exploited Pentium FPU's limited out-of-order FDIV feature in addition to concurrent integers and floating point execution. The FDIV instruction is put on another lane while continuing execution.

For Quake, the pixel workload is mostly integer while the geometry is floating point.

PowerPC's GPR and FP data exchange penalty shows IBM's non-gaming background.

Another problem for PowerPC is stack-based function calls that are prevalent with C/C++ and the X86 competition is optimized for stack-based computer languages.

_________________
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)