Project - hardware to run AOS4 for 35 euro on QEMU 10 + GPU  passthrough

@imagodespira
@samo79
Quick test - Spencer works

video -> https://youtu.be/Ri2G7giR1lw

@balaton
Quote:The usual CPU benchmarks, something like https://os4depot.net/?function=showfil ... ty/benchmark/cpubench.lha : Dhrystone, Whetstone, Sieve, Quicksort.

It's not VRAM related at all, neither on real hardware nor with vfio pass through on QEmu, but faster CPU (emulation) speed should help anyway.

x64 CPUs aren't relay suitable for PPC emulation anyway, way too few registers, emulation is only fast if the host CPU has more registers than the emulated guest CPU, for example as it's the case with the m68k emulators of AmigaOS 4.x:
m68k: 16 integer registers, of which 8 can only be used for data, and 8 only for pointers, and 8 FPU registers - but those were 80 bits, not the usual 64 bits of current FPUs. The 80 bit 68882 results from real m68k FPUs were used for example for the newlib math library code tests, and of course nearly all of them failed, with more or less errors.
PPC: At least 32 32 bit integer (GPR) and 32 64 bit FPU registers (some CPUs have more, CPUs with AltiVec additionally 32 128 bit registers, or may have less but larger ones like the 64 bit instead of 32 bit GPR/SPE registers on the A1222).
m68k emulators on PPC can use a 1:1 register mapping of host and guest registers, and still have 16 integer and 24 FPU resisters left which can be used by the emulator code.

For example ARM based CPUs, like the Apple M4, and MIPS based ones should be much better at PPC emulation than x64 CPUs are.

@joerg
But results so far did not prove that faster CPUs should be better for using real cards with passthrough. At least I got the impression that the Gfx2DBench results were more dependent on something else than host CPU speed. But the thread where I've asked people to collect results went nowhere so I don't have data to compare.

I'm also not sure that number of registers plays the bigest role in emulation performance. We know that FPU, MMU emulation, exceptions and dcbz are all factors that if something hits any of these a lot it will get slow. If something hits multiple of them it may be even worse. Compared to that having to move data to/from registers is probably less of an issue given that modern CPUs are much faster and this should still work from cache so this may have less of an effect than the other issues. Trying to optimise those may help more. I've tried cleaning up exceptions before but it did not help that much. MMU is not easy to improve. For FPU there was a design that could be implemented but nobody tried it and I've also tried dcbz but again nobody cared about it enough so these aren't solved still. I guess dcbz would not be too difficult as it's just one small part that somebody could learn in a few weeks and make a patch but there weren't many people wanting to try that so far.

@smarkusg
Quote:

If you doesn't mind, can you enable in options of spencer "fps show" , set everything to maximum as well (shadows, light, resolution, etc), and check what FPS you have when in the menu walk a bit (the middle value), and what FPS you have in the first level, when staying at beginning and do nothing ?