@nikitas I think perf inject is not supported by QEMU and not sure --call-graph makes sense with perf mem so maybe try only perf mem record -z --pid=<QEMU's PId> to capture a memory access profile and export that with perf mem report --stdio. The files you've sent don't show anything that could explain the slow access but I don't know if these were mangled by --call-graph or inject so retry without those.
UNHANDLED INT 10 FUNCTION 0300 WITHIN EMULATION
UNHANDLED INT 10 FUNCTION 1301 WITHIN EMULATION
UNHANDLED INT 10 FUNCTION 0300 WITHIN EMULATION
UNHANDLED INT 10 FUNCTION 1301 WITHIN EMULATION
entering main read/eval loop...
UNHANDLED INT 10 FUNCTION 0300 WITHIN EMULATION
UNHANDLED INT 10 FUNCTION 1301 WITHIN EMULATION
UNHANDLED INT 10 FUNCTION 0300 WITHIN EMULATION
UNHANDLED INT 10 FUNCTION 1301 WITHIN EMULATION
Then I blindly type:
" /failsafe" io
To get the firmware's "ok" back.
Then I tried the following which did not work:
boot hd:0 vmlinuz
It can't follow the symlink?
Anyway, then I tried the following:
boot hd:0 vmlinuz-3.16.0-6-powerpc root=/dev/sda2
Which tries to boot but it ends up with a Kernel panic error:
zImage starting: loaded at 0x00400000 (sp: 0x00762fa0)
Allocating 0x8a1ec0 bytes for kernel ...
OF version = 'Pegasos2,1.1'
Trying to claim from 0x400000 to 0x76edfc (0x36edfc) got 400000
gunzipping (0x01800000 <- 0x0040c000:0x00761c62)...done 0x743000 bytes
Linux/PowerPC load: root=/dev/sda2
Finalizing device tree... using OF tree (promptr=01003ad0)
OF stdout device is: /failsafe
Preparing to boot Linux version 3.16.0-6-powerpc (debian-kernel@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 Debian 3.16.56-1+deb8u1 (2018-05-08)
Detected machine type: 00000500
command line: root=/dev/sda2
memory layout at init:
memory_limit : 00000000 (16 MB aligned)
alloc_bottom : 020a6000
alloc_top : 20000000
alloc_top_hi : 20000000
rmo_top : 20000000
ram_top : 20000000
instantiating rtas at 0x0fbfd000... done
Fixing up missing ISA range on Pegasos...
Fixing up IDE interrupt on Pegasos...
Fixing up IDE class-code on Pegasos...
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x020a7000 -> 0x020a7746
Device tree struct 0x020a8000 -> 0x020b3000
Calling quiesce...
returning from prom_init
@nikitas Are you sure you're running the right Linux kernel version for pegasos2? Or does it need an initrd which has the necessary drivers? It looks like it lacks the IDE driver that's why it cannot read the root volume. I don't know how this Debian version is supposed to work on pegasos2 but is there a boot loader such as grub or yaboot that you should boot with? There should be some install guide somewhere on the CD that documents this but I haven't checked.
The perf mem profile at least looks like a valid profile now but nothing stands out to me in it. There are some AltiVec instructions at the top so maybe try if -cpu 750cxe changes anything (is is slower/faster with that or no change). I still don't understand why it's slow and to me it looks like it's not slowing down within QEMU but I can't tell what could be the cause of slowness.
Ok, so, we leave the VFIO RX550 + AOS4.1FE experiment here, I suppose.
Things I forgot to mention: - In AOS4 ScreenMode if you check "Enable Interrupts" the system is even more slow and it eventually freezes. - In AOS4 ScreenMode if you check "Allow Fake Modes", a warning appears in the serial output when using RadeonRX.chip.debug. And the option never gets saved (even after the required reboot). - IN AOS4 Ranger I get the CPU synchronized at 999Mhz. In other systems I've seen in this forum or in youtube videos, the Cpu clock syncs at 1.2Ghz or more. - IN AOS4 Ranger --> Exec --> Resources, the RadeonRX_RM.resource & RadeonRX_DPM.resource are the only ones to have the Type as "Unkonwn" instead of "Resource". If it means something. (Ranger screenshot: https://ibb.co/vQZ7S49).
In general the guest system is stable. Programs working properly, MPEG videos are playing in Emotion Player with FORCESOFTWARE=FALSE. But everything very very slow, and the video works with very frequent "hiccups" both audio & graphical. And of course as I already wrote before in every single thing I do the CPU is 100%. If I let it idle drops to 61% or 40%.
Regarding the DebianPPC, I've downloaded/installed the iso that has the exact same name as in QEMU docs and initiated the "install/pegasos" file. The installation was completed successfully. 3 partitions have been created. Anyway, I'll see what I can do, hopefully I'll get it working.
Edited by nikitas on 2024/6/13 22:59:54 Edited by nikitas on 2024/6/13 23:00:35
Ok, so, we leave the VFIO RX550 + AOS4.1FE experiment here, I suppose.
I haven't given up but don't have any more ideas currently on how to find the cause of the issue with AmigaOS so maybe reproducing it with Linux guest could help. Quote:
Things I forgot to mention: - In AOS4 ScreenMode if you check "Enable Interrupts" the system is even more slow and it eventually freezes.
I think it's supposed to be faster not slower with IRQs but if it also freezes then maybe there's some issue with handling IRQs from different PCI buses. I've said before that I think all devices on default bus=pci.1 should work better, bus=pci.0 is not well tested but I think you tried that and it did not work for some reason so had to use pci.0. But with IRQs disabled this should not be a problem. Quote:
- In AOS4 ScreenMode if you check "Allow Fake Modes", a warning appears in the serial output when using RadeonRX.chip.debug. And the option never gets saved (even after the required reboot).
I don't know what this does, where it tries to save it and what error you got so I have no idea. Quote:
- IN AOS4 Ranger I get the CPU synchronized at 999Mhz. In other systems I've seen in this forum or in youtube videos, the Cpu clock syncs at 1.2Ghz or more.
I also don't know where this comes from. Are you using any -cpu options? I think it depends on that and maybe on the pegasos2.rom version but otherwise is probably not related to actual speed of emulated CPU which only depends on your host CPU. Quote:
- IN AOS4 Ranger --> Exec --> Resources, the RadeonRX_RM.resource & RadeonRX_DPM.resource are the only ones to have the Type as "Unkonwn" instead of "Resource". If it means something. (Ranger screenshot: https://ibb.co/vQZ7S49).
In general the guest system is stable. Programs working properly, MPEG videos are playing in Emotion Player with FORCESOFTWARE=FALSE. But everything very very slow, and the video works with very frequent "hiccups" both audio & graphical. And of course as I already wrote before in every single thing I do the CPU is 100%. If I let it idle drops to 61% or 40%.
Is this CPU usage in the guest or on the host? If in the guest why it did not show on the Tequila or whatever top like tool you tried which showed ~60% idle if I remember correctly.
I haven't given up but don't have any more ideas currently on how to find the cause of the issue with AmigaOS so maybe reproducing it with Linux guest could help.
First of all you need to get host speed, for example with the method Georg mentioned here and here (vesa X11 framebuffer driver with ShadowFB 0 and compositor disabled).
All guest results are useless as long as you have nothing to compare them to.
All guest results are useless as long as you have nothing to compare them to.
Not necessarily. If the problem does not reproduce with Linux guest then we know it's likely something that AmigaOS does differently than the Linux driver. If the problem reproduces then we need host results to compare to or at least we know what the driver is doing so we could investigate more easily than with AmigaOS.
To get host results somebody would need to remove vfio and configure the card on the host then do some tests. Then set up vfio and repeat same tests with a Linux guest. It would be best if this could be done by somebody who ran Linux and X on real machine so can be tested with a known working setup. Otherwise we don't even know if the Debian 8.11 we know at least should boot was working with real pegasos2. Does anybody know what Linux versions worked on real pegasos2?
Does anybody know what Linux versions worked on real pegasos2?
Debian 8.11 is the one i install and use 2 months ago on my real pegasos when we test bridges in peg2/radeonhd thread you may remember. But you should not use netinstall.iso as it have bug on installation (not fully finished post install steps resulting in non booting system), so you had to use the one called debian-8.11.0-powerpc-DVD-1.iso instead, which installs and works fine on my real peg2
Not necessarily. If the problem does not reproduce with Linux guest then we know it's likely something that AmigaOS does differently than the Linux driver.
Of course X11 and the Linux amdgpu drivers are working completely different to the AmigaOS gfx API and it's Radeon drivers, the results are not comparable at all. For example on Linux GART can be used to speed up copies between DRAM and VRAM by using large DMA transfers, on AmigaOS it can't be used because 2D rendering and such copies aren't done by the GPU but by the CPU.
For comparing Linux guest to AmigaOS guest you have to do exactly the same as you have to do on the Linux host to get VRAM speed and compare that to the VRAM speed on AmigaOS: vesa framebuffer driver instead of amdgpu/radeon driver, ShadowFB, compositor, and anything else which may result in DRAM cached accesses instead of direct VRAM accesses, disabled.
The PPC linux kernel(s) do not support the RadeonRX GPU`S at all. PPC Kernel support stopped somewhere around the HD7950 (SI series). Few newer cards like the R7 250 can use PPC linux using the FBdev driver (so no GL hardware acceleration) Radeon RX support for PPC Linux is just a no go. I would opt for using a Radeon HD regarding the Qemu stuff.
AmigaOne X5000 -> 2GHz / 16GB RAM / Radeon RX 550 / ATI X1950 / M-Audio 5.1 -> AmigaOS 4.1 FE / Linux / MorphOS Amiga 1200 -> Recapped / 68ec020 ACA 1221ec / CF HDD / RetroNET connected to the NET Vampire V4SE TrioBoot RPI4 AmiKit XE
@Skateman Linux radeon/amdgpu drivers must not be used anyway if you want to use Linux guest VRAM speed as reference to the AmigaOS guest VRAM speed. You have to use for example the vesa framebuffer driver instead (which is of course as unusable slow as AmigaOS is on QEmu G3/G4 with VFIO gfx cards), which should still work on Linux PPC?
@Skateman You won't get 3D or advanced features but getting just plain frame buffer working may enough to do the tests. But true it might not be as easy as with contemporary cards as the RX card is newer than what that Debian version supported and doing it on PPC is additional complexity as it might need some x86 emulation for the VGA BIOS. But I had no better idea than trying to test this under Linux guest as we could not find out the cause with AmigaOS.
In the other thread it came up that AltiVec may be used on G4 CPU for some copies and I've seen it used in a profile so maybe try AmigaOS with -cpu 750cxe and see if there's any difference in speed with that.
Yes, indeed, I managed to install Debian 8.11.0 on QEMU Pegasos2 using the DVD image (as @kas1e said). The RX550 is passed through, I see it with lspci, but there is no amdgpu driver so when I try to start X Server with "radeon", "ati" "fbdev" drivers it fails with several different errors. I could post xorg log file, if it would be useful.
@balaton Regarding the CPU 100% thing I maybe mislead you. On the host is always 100%. On guest, using cpu_watcher I get CPU 100% & CPU 60% load when I remove the focus from the cpu_watcher window. Using tequila there is idle task 70%.
The QEMU documentation page reports only the Debian-8.11.0 that can work with Pegasos2.
I read that Pegasos2 (real machine), is supported also by: - Void Linux PPC - Gentoo Linux
I don't know if it is worthy to try though. If they are maintained or just include the "amdgpu" driver.
Regarding the Debian 8.11.0 which comes with Kernel 3.16, I don't know if I can upgrade the Kernel to 4.20, which, I read, that contains the "amdgpu" driver.
@balaton Regarding the -cpu 750cxe option, it might improve the performance a little or it might be a placebo effect, can't be sure.
The fact that when I "Enable Interrupts" on AmigasOS4 "ScreenMode", and the performance is getting even slower rather than faster (as expected to be faster), what this could mean, I wonder.
Yes, indeed, I managed to install Debian 8.11.0 on QEMU Pegasos2 using the DVD image (as @kas1e said). The RX550 is passed through, I see it with lspci, but there is no amdgpu driver so when I try to start X Server with "radeon", "ati" "fbdev" drivers it fails with several different errors. I could post xorg log file, if it would be useful.
I think radeon and ati drivers don't support RX cards so those won't work, fbdev might work but I don't know how to set it up. I think it may need some Linux FB driver. There's also vesa driver that might work but probably needs to boot with nomodeset Linux kernel option and don't know if it works on non-x86 machines as it might need the card's ROM. Maybe fbdev also needs nomodeset and installing some Linux FB driver which may not be compiled in Debian 8.11. Quote:
@balaton Regarding the CPU 100% thing I maybe mislead you. On the host is always 100%. On guest, using cpu_watcher I get CPU 100% & CPU 60% load when I remove the focus from the cpu_watcher window. Using tequila there is idle task 70%.
If something busy waits in the guest you'd get 100% CPU usage on the host but this does not mean it's slowing down just there's always some guest code running. If you get 70% idle in the guest then there's still free CPU to run tasks. Quote:
The QEMU documentation page reports only the Debian-8.11.0 that can work with Pegasos2.
I read that Pegasos2 (real machine), is supported also by: - Void Linux PPC - Gentoo Linux
I don't know if it is worthy to try though. If they are maintained or just include the "amdgpu" driver.
I've only written about Debian 8.11 in QEMU because that's the only one I've tested. If others work on real machine they should also work on QEMU but I haven't tried them. If those are newer maybe it's better to try those. Quote:
Regarding the Debian 8.11.0 which comes with Kernel 3.16, I don't know if I can upgrade the Kernel to 4.20, which, I read, that contains the "amdgpu" driver.
It might be difficult unless there are some packages for it as it may have some dependencies or you may also need newer Xorg which will then be difficult to compile. So if there's a newer distro that supports pegasos2 then trying that should be easier. Two recent PPC Linux distros I know about are Finnix and Adélie but these may not support pegasos2 only other PPC machines. Quote:
@balaton Regarding the -cpu 750cxe option, it might improve the performance a little or it might be a placebo effect, can't be sure.
You'd need to repeat the benchmark test to compare the numbers to see if VRAM access is faster without AltiVec or the same. Quote:
The fact that when I "Enable Interrupts" on AmigasOS4 "ScreenMode", and the performance is getting even slower rather than faster (as expected to be faster), what this could mean, I wonder.
I don't know what that option does or what does the driver use it for. Maybe @Hans can tell but if the problem is because of slow VRAM access then this option may not do much about that.
OF stdout device is: /failsafe
Preparing to boot Linux version 5.15.132-mc6-easy (builder@ppc64) (gcc (Adelie 8.5.0) 8.5.0, GNU ld (GNU Binutils) 2.41) #1 SMP Sun Nov 12 07:51:09 UTC 2023
Detected machine type: 00000500
command line: BOOT_IMAGE=(ieee1275/ide0)/kernel-ppc root=live:LABEL=Adelie-ppc rd.live.dir=/ rd.live.squashimg=ppc.squashfs
memory layout at init:
memory_limit : 00000000 (16 MB aligned)
alloc_bottom : 05e0e000
alloc_top : 20000000
alloc_top_hi : 20000000
rmo_top : 20000000
ram_top : 20000000
instantiating rtas at 0x0fbfd000... done
boot cpu hw idx 0
Fixing up missing ISA range on Pegasos...
Fixing up IDE interrupt on Pegasos...
Fixing up IDE class-code on Pegasos...
copying OF device tree...
Building dt strings...
Building dt structure...
Device tree strings 0x05e0f000 -> 0x05e0e0a4
Device tree struct 0x05e10000 -> 0x00000000
Quiescing Open Firmware ...
Booting Linux via __start() @ 0x03800000 ...
Linux/PPC 5.15.1
But it stays there forever. At the end of the serial output there is an:
@nikitas I think Adélie also does not support pegasos2, mainly only PPC Macs maybe. So what you could try for now is measure the card on the host as @Georg described to know if it's limited by PCIe access or is there some overhead somewhere else. I think it's still not completely proven that the cause is slow VRAM access through PCIe but it seems likely. The test with vesafb and ShadowFB off seems to reproduce that access pattern so that could be used to check this. If you get the same speed on the host than with passed through then there's not much that can be done without changing AmigaOS which is not really possible so then the only way may be to look for other cards or hosts where direct VRAM access is faster. Maybe there are some measurements somewhere that show which cards are better in this and which are slower that could give a hint what cards to try. It may also depend on the host so your options may be trying other cards or trying the same card on other host machine.
When I'll have time I can try to improve PCIe emulation on sam460ex to be able to test with that too but that might take a while so we'll have to come back to this then.
When I'll have time I can try to improve PCIe emulation on sam460ex to be able to test with that too but that might take a while so we'll have to come back to this then.
It can only help if you additionally can change the 4x0 DMA emulation from memmove() to host DMA. Without that the much larger DMA copies between VRAM and DRAM used by AmigaOS will still be split into tiny, slow 64 bit host CPU accesses on QEmu and it can't be faster than G3 emulation.
@joerg You are basing your analysis on unproven assumptions. Without knowledge on how AmigaOS accesses the card I'm not sure yet the problem is really because of fine grained access to VRAM so this is still something to verify. The ways for that could be measuring host performance with x11perf and see if it reproduces with that and trying different cards and hosts which have different access speed and see if the AmigaOS performance with pass through correlates to that. Otherwise we just assume that's the problem because we know this case is slow but it could be anything else with the pass through card.
I'm also not sure the PPC440 DMA engine on sam460ex is used for this. I know it uses it for something because I had to add emulation of that because I saw AmigaOS using it sometimes but it only uses it infrequently, e.g. you can boot AmigaOS without it accessing the DMA engine at all and it only happens with some programs so I don't know if this is really used for graphics. That's another unproven assumption which could be tested if I fix the PCIe emulation to work (or find out why the PCI bus fails on sam460ex) so the point of fixing it would be to test it not because I think that would solve the problem. I don't know what causes to problem so I also don't know what would fix it. But at least sam460ex might give more possibilies also because it could support newer cards but the CPU emulation is slower so not ideal in any case.
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
Donate
