At least the numbers show that it is different, shouldn't it always be the same?
It should be about the same if the same thing has been run in the guest when you collect these statistics so if you always do the same and get the stats at the same point then difference shows something if they are from runs where different things happened since starting QEMU then they don't show anything.
PPC interrupt 8 is syscall when guest executes sc instruction which is done when something is calling AmigaOS services so maybe something is running in guest that does more stuff sometimes? Is there some task manager where you can check what task is using CPU time and compare that?
Thanks for the explanation, the test on both sessions always runs the same. I start Qemu Boote AmigaOs4.1 until Workbench is available and then I start Quake Timedemo1 and look at the benchmarks. Good session 32 FPS, bad session 16 FPS. So I can also determine which session with Qemu is bad and which is good. So I could assign IRQ and JIT info to the respective sessions.
A reliable CPU task manager under AmigaOs4.1 does not exist at the moment, but should not be necessary since both Qemu sessions run exactly the same.In the test nothing else is started like AmigaOs4.1 up to the Workbench and then directly Quake Timedemo1.
Edit: Believe me, I have tested this countless times. It's like when I noticed that the sound output under MacOs with Qemu and AmigaOs4.1 runs too fast, this error was also hard to reproduce until I recorded it on my handy
In a bad Qemu session I also notice that I can stream YouTube videos in 720p with MPlayer, but the FPS numbers collapse and the video plays slower, as if I had a good session with Qemu where Quake with 32 FP benchmark is available.
Since no one has tested it further, I'm not sure if it's only a MacOs problem. Or if it is due to the Mac M1 CPU which makes it sometimes faster and sometimes slower.Or maybe it is a problem of Qemu.
Edited by Maijestro on 2023/7/25 19:31:55 Edited by Maijestro on 2023/7/25 19:36:23
Top would probably help if it lists cumulative CPU time from boot like under Unix.
My "top" and "Tequila" can only display CPU times/task after they were started. The kernel records per task CPU usage times as well, but not on all systems/CPUs, some CPUs don't include the required hardware for it. I did implement a "top" version using the kernel stats instead of calculating it itself, but since it couldn't work on all CPUs I never released it. Additionally to per task CPU usage my "top" tool displays the number of IExec->SuperState() calls per second, i.e. the number of switches from user to supervisor mode and back per second, and if that's a very high number there is definitely a problem (maybe not QEmu related, can be kernel or AmigaOS hardware drivers, or even user software, related as well).
That would be enough as one can start top at boot from WBStartup or startup-sequence or similar then leave it running to collect CPU time from boot. Then hopefully running the same things might show some difference to find which task may have something to do with this. If there's no difference then it's probably not a user program but something lower level. Measuring user/supervisor transitions could be checked if it correlates with syscall exceptions in info irq too.
it is due to this: qemu-system-ppc -M pegasos2 -cpu 7447 -accel tcg -kernel /home/white/Download/bboot-0.4/bboot -initrd /home/white/Download/Kickstart.zip
Because if i use the old command that use pegasos2.rom i get the cpu at 1.5ghz
Edited by white on 2023/7/26 3:20:55 Edited by white on 2023/7/26 3:44:34 Edited by white on 2023/7/26 4:05:38 Edited by white on 2023/7/26 4:24:37 Edited by white on 2023/7/26 5:45:45
Additionally to per task CPU usage my "top" tool displays the number of IExec->SuperState() calls per second, i.e. the number of switches from user to supervisor mode and back per second, and if that's a very high number there is definitely a problem (maybe not QEmu related, can be kernel or AmigaOS hardware drivers, or even user software, related as well).
There are cases where you can get unexpected high number of taskswatches in AOS or clones even if there's no problem (assuming problem = bug). For example when multiple tasks use the same semaphore a lot (for example it could be some memory allocation lock, or something gfx related like OwnBlitter()) and ~"bad luck" causes the semaphore to get in what I call "pingpong state".
Happens when one of the test programs gets preempted while holding the semaphore. From then one at every ReleaseSem() time there will always be the other task in the wait queue causing switch to this other task (when thistask calls ObtainSem()).
I managed to build bboot on OS4 last night (in Qemu on my MacBook). I had 3 issues with the code compiling but they were all sovled in the end. I don't know if it's worth listing them because I doubt many people are likely to be building it on OS4. Just try as I might I could not easily get a cross-compiler set up.
The whole reason I'm even building it at all is so that I can at least attempt to try different things out when things don't work. Hopefully that's helpful!
Unfortunately my time continues to be limited this week and there will be no time at all soon due to vacation. But I should be good for tonight to at least check that the bboot that I built runs.
The whole reason I'm even building it at all is so that I can at least attempt to try different things out when things don't work. Hopefully that's helpful!
I don't understand what this should be good for, but everything that brings Qemu and AmigaOs4.1 further in development should be good in my opinion.
Maybe you can give some details what exactly you have in mind to understand what it can be useful for.
Sure, at the moment we don't know for sure on GPU passthrough if the register addresses (I think that's what we're talking about, I know which addresses I mean in the output / code anyway) should be left undefined as they appear to be on real Pegasos2, whether the IRQ's should be mapped when they are unassigned by firmware and so on.
I could keep coming back here, posting log output and then Balaton can make a minor change with "try this", or I could try the changes myself first. If I understand where to make the change of course. It doesn't matter if I do it exactly how Balaton would do it, or not, at least then I can say "well, I tried x and y but it didn't help, here are the logs". Etc.
Unless I'm wrong and we've exhausted all options but I don't think that is the case. I also have access to HD5450, RX550 and RX580.
One thing I will say is that I've switched to a different PC and the PCIe slots are a bit blocked by the CPU cooler so I'm a bit limited now. "New" (actually older) PC is Intel 6700K based but actually, that has a faster single core frequency than my Ryzen system so it's better for Qemu really. The IOMMU isolation is not as good however and I think it might be causing me problems.
Sure, at the moment we don't know for sure on GPU passthrough if the register addresses (I think that's what we're talking about, I know which addresses I mean in the output / code anyway) should be left undefined as they appear to be on real Pegasos2, whether the IRQ's should be mapped when they are unassigned by firmware and so on.
I could keep coming back here, posting log output and then Balaton can make a minor change with "try this", or I could try the changes myself first. If I understand where to make the change of course. It doesn't matter if I do it exactly how Balaton would do it, or not, at least then I can say "well, I tried x and y but it didn't help, here are the logs". Etc.
Unless I'm wrong and we've exhausted all options but I don't think that is the case. I also have access to HD5450, RX550 and RX580.
One thing I will say is that I've switched to a different PC and the PCIe slots are a bit blocked by the CPU cooler so I'm a bit limited now. "New" (actually older) PC is Intel 6700K based but actually, that has a faster single core frequency than my Ryzen system so it's better for Qemu really. The IOMMU isolation is not as good however and I think it might be causing me problems.
I keep my fingers crossed that they get it running decently.
Since no Amiga NG x5000 comes into question for me (too expensive) and for that AmigaOs4.1 is still too limited at the moment, I would prefer such a solution on current PC hardware.
Otherwise I'm waiting for a Qemu Pegasos 2 GFX driver for the emulated GFX, because I've also played with the idea to buy the new MacStudio with M2 Max or M2 Ultra, on such a hardware AmigaOs4.1 would probably be even faster as it already is.
Since no Amiga NG x5000 comes into question for me (too expensive) ... I've also played with the idea to buy the new MacStudio with M2 Max or M2 Ultra, on such a hardware AmigaOs4.1 would probably be even faster as it already is.
Doesn't make sense if you want to use it mainly for AmigaOS 4.1 emulation, the M2 Max costs about as much as a X5000, the M2 Ultra twice as much.
Since no Amiga NG x5000 comes into question for me (too expensive) ... I've also played with the idea to buy the new MacStudio with M2 Max or M2 Ultra, on such a hardware AmigaOs4.1 would probably be even faster as it already is.
Doesn't make sense if you want to use it mainly for AmigaOS 4.1 emulation, the M2 Max costs about as much as a X5000, the M2 Ultra twice as much.
But it makes sense, the MacStudio, I use mainly for working with MacOs it is my main system I use. AmigaOs4.1 is currently used as a 2 system.
I also don't have room for additional hardware, so I went for something very powerful that takes up as little space as possible. I don't like the clunky computers.
I already had an AmigaOneXE 20 years ago, but for the fact that I boot AmigaOs4.1 only 2-3 times a day, this space would be wasted for me and it would be a pity for the hardware that then just stands around and is not used.
2 systems on one machine would be perfect, of course. AmigaOs4.1 did not run much better on real hardware than under Qemu, and I am a bit suspicious if things have improved. At that time AmigaOs4 was still pre-release.
The NG Amiga x5000 was released in 2016 has 2 cores, which unfortunately is not supported by the AmigaOs4.1 kernel until today. For God's sake I don't want to talk bad, but the further development of AmigaOs4.1 is unfortunately very slow, as much as I love this system otherwise I wouldn't have bothered with it again after years.
I do not want to go into this topic any further either. AmigaOs4.1 is a great system for me and with a x 5000 you will of course have much more fun than with Qemu and AmigaOs4.1.
Edited by Maijestro on 2023/7/26 18:58:20 Edited by Maijestro on 2023/7/26 19:02:58
Unfortunately, at the moment Qemu is never going to work properly on my Mac Mini. The sound doesn't work with my USB Audi Interface and I don't want to route all the sound through the Mini's internal speaker to get round it. This is kind of a known thing. At one point Qemu couldn't even start a linux VM as it would kernel panic and shut off prior to login. Switch off the audio interface and it was OK. This was "UTM" but I believe it was Qemu behind the scenes.
Qemu is fine on my laptop for a bit of tinkering about but the GPU is the sticking factor there. And not the resolution, 1440x900(x2) is the native resolution of the screen but developing games is a non-starter.
So, the GPU passthrough stuff is a bit of fun to play about with but that will reach a pause when my X5000 arrives as I'll need the case the "passthrough machine" is in, not to mention the GPU.
So, the GPU passthrough stuff is a bit of fun to play about with but that will reach a pause when my X5000 arrives as I'll need the case the "passthrough machine" is in, not to mention the GPU.
To be honest I don't think much of this GPU passthrough story under Qemu. Because this setup is very heavy and not user friendly. A suitable driver for this emulation would be far more effective.
However, the information was very helpful for real Pegasos 2 hardware where it might be possible in the future to use RadeonHD and RX cards across bridges, even if this hardware is very old they would be up to date.
You contributed a lot and did it really well and I know how much time testing alone takes, I've been dealing with the Qemu emulation and AmigaOs4.1 for a year when I started testing Qemu was on mine Machine completely unusable. No sound, no network, broken graphics etc.
Congratulations on the purchase of the x5000, maybe you will also develop some software for AmigaOs4.1 in the future. I can well imagine that with them....
To be honest I don't think much of this GPU passthrough story under Qemu. Because this setup is very heavy and not user friendly. A suitable driver for this emulation would be far more effective
When it works, it should work very well. I used to run all my Windows games in a Windows VM using GPU (and USB) passthrough. Ideally there will need to be ways to switch monitor inputs and keyboard / mouse (or pass them through too). It's all possible but obviously needs extra work.
Of course, I agree that OS4 drivers is also a nice way to go and I'd see the benefit there too on my laptop.
Quote:
maybe you will also develop some software for AmigaOs4.1 in the future
I am part of a team that has created a sort of game engine but it was never completed. I intend to look to se if it could be brought to OS4 and maybe the goals re-aligned a bit so it could be completed. No public info yet and potentially may never be.
As soon as your x5000 has arrived and you have set up an AmigaOs4.1 system and all that entails I would appreciate if you could give some feedback on how things are going with this machine, it would be interesting to know.
I've spent some time tonight looking at PCI Passthrough for 5450 GFX. BBoot 0.4, Qemu Master. I can't get it to work. Boot hangs before workbench even starts to load and leaves me with a grey sceen with the text "Workbench" in the top left in an old PAL-like resolution.
Hopefully I've not omitted any info. Let me know if I have.
I've compared bboot output from using pegasos rom with my manual forth patch:
Unless you can spot anything, the only thing I could really see was that the command for bus 0:0.0 was 0 when using pegasos firmware and 7 with bboot. In addition, we know we are adding an empty assigned addresses property when there are no addresses.
I modified my bboot to match the command on PCI bus 0 but it didn't change anything:
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
