Can anyone confirm if the Pegasos-II has full memory coherence or not? The Marvell Discovery II datasheet mentions cache coherence, but I haven't seen any clear confirmation.
Maybe you can ask some MorphOS people over their forum or if you have contact to them. AFAIK PegasosII ran MorphOS first and they had contact to hardware designers so maybe they know something about that.
I was experimenting a little with Transparent HugePages and the QEMU's -mem-path -mem-prealloc. But does it have any meaning to do anyway? I don't know.
The results of the GPU test weren't any good. I might have changed some GUI settings in AOS4. But in anyway, in any test I ran, the difference between the performance I get and the performance I should get is chaotic, as @Hans also mentioned in a previous post.
Also I wanted to clarify some things on the CPU Usage on the guest (AOS4).Tequila tool is showing idle.task at 74%.
But I primarily use the CPU_Watcher tool. I have every application and window closed other than CPU_Watcher.
- Without VFIO'd GPU it reports CPU Load at 2% when I'm idle. And stays there. - With VFIO'd GPU, the minimum CPU Load is 60%, and every (approx.) half of a second, it goes 100% for a moment and then back to 60%, forming a very consistent pattern of 60% --> 100% and 100% --> 60%. Producing a "high frequency" wave diagram.
I never understood why this specific tool (CPU_Watcher) shows a minimum CPU load of 60% with VFIO GPU and a minimum of 2% without.
Lastly, by the time I started this thread, I have tried a tremendous number of combinations (UEFI, Host OS, Qemu parameters, even hardware alterations by moving RX550 upwards), running @Hans tool each time, but I never managed to get a GPU score greater than 250. Irrelevant, but disabling Intel's hyperthreading to utilize a physical core without threads gave the guest a little boost indeed, but not a GPU boost.
The worst thing is that every time I run QEMU with RX550 passed through, by the time I stop the QEMU process, the GPU never actually "returns" to the host. So, I have to reboot my system after every single QEMU/VFIO run.
Edited by nikitas on 2024/6/24 20:37:12 Edited by nikitas on 2024/6/24 20:39:03 Edited by nikitas on 2024/6/24 20:46:19 Edited by nikitas on 2024/6/24 20:47:36 Edited by nikitas on 2024/6/24 20:51:58 Edited by nikitas on 2024/6/24 20:52:19 Edited by nikitas on 2024/6/24 20:53:50
When attaching GPU on pci.1 it seems that no addresses are assigned to BARs, so it is disconnected so I have no screen:
class VGA controller, addr 00:01.0, pci id 1002:699f (sub 1da2:e468)
bar 0: mem at 0xffffffffffffffff [0xffffffe]
bar 2: mem at 0xffffffffffffffff [0xfffffe]
bar 4: i/o at 0xffffffffffffffff [0xfe]
bar 5: mem at 0xffffffffffffffff [0x3fffe]
bar 6: mem at 0xffffffffffffffff [0x3fffe]
class Audio controller, addr 00:01.1 pci id 1002:aae0 (sub 1da2:aae0)
bar 0: mem at 0xffffffffffffffff [0x3ffe]
When attaching the GPU on pci.0 it seems the CPU gives addresses to the BARs so it can boot and I have screen.
class VGA controller, addr 00:01.0, pci id 1002:699f (sub 1da2:e468)
bar 0: mem at 0xc0000000 [0xcffffffff]
bar 2: mem at 0xd0000000 [0xd01ffffff]
bar 4: i/o at 0x1000 [0x10ff]
bar 5: mem at 0xd0200000 [0x3fffe]
bar 6: mem at 0xffffffffffffffff [0x3fffe]
class Audio controller, addr 00:01.1 pci id 1002:aae0 (sub 1da2:aae0)
bar 0: mem at 0xffffffffffffffff [0x3ffe]
Although VGA controller's BAR 6 is still 0xffffffffffffffff And Audio controller's BAR 0 is again 0xffffffffffffffff
I know. I'm not intending to use it for any demanding graphics task. Just to satisfy my "Amiga GPU passing through" growing obsession. I'll take it, I think.
I never understood why this specific tool (CPU_Watcher) shows a minimum CPU load of 60% with VFIO GPU and a minimum of 2% without.
I don't know how CPU Watcher works and calculates the CPU usage, but in case it's still working on current AmigaOS 4.x versions (probably doesn't on current hardware like Sam460, X1000, X5000 and A1222, but since you are emulating ancient AmigaOne/Pegasos2 hardware it may still work for you) you may try using my CPUTemp.docky instead.
Only the CPU usage part of it, I doubt QEmu emulates the TAU.
When attaching GPU on pci.1 it seems that no addresses are assigned to BARs, so it is disconnected so I have no screen:
Is this the same with bboot or with firmware ROM? Or did you say it crashed with firmware ROM so you could not boot it? Can you post logs with firmware ROM and with bboot on pci.1 so we can check what it attempts to do. Just up to the ok prompt or starting exec is enough. Maybe you posted these before but I couldn't find them. It could be there's not enough free memory to map the card on pci.1 but I don't know what you could remove from there. You can try removing bochs-display and the network card for testing or use -device bochs-display,vgamem=4m,edid=off to make it use less memory and turn off EDID which probably isn't checked but just in case.
Quote:
Although VGA controller's BAR 6 is still 0xffffffffffffffff And Audio controller's BAR 0 is again 0xffffffffffffffff
BAR 6 is the ROM which is only mapped by the firware while running it with the BIOS emulator so probably won't be mapped after that or when not using firmware. Or the driver probably maps it while parsing AtomBIOS but unmaps afterwards. The audio part is probably not recognised by a driver so not mapped.
The above command does not work if I: - Use bus=pci.1 - Don't use the bus property at all. - I don't have the "Resize BAR" setting disabled in UEFI.
It only works when I explicitly define bus=pci.0 + having "Resize BAR" UEFI setting disabled.
Not using bus property and bus=pci.1 are the same, the default PCI bus on pegasos2 is pci.1, pci.0 is the AGP port but it's only emulated as PCI. (Actually the AGP port on real PegasosII is also only a PCI bus.) Resizable BARs probably don't work with AmigaOS, even with Linux or Windows it probably only works with UEFI guest and new enough host kernel. Also it's a PCIe feature and you're passing through a PCIe card as PCI so it probably can't work anyway so disabling it is likely how it should work and enabling it is not expected to work.
Edited by balaton on 2024/6/25 13:17:59 Edited by balaton on 2024/6/25 13:20:04
I was experimenting a little with Transparent HugePages and the QEMU's -mem-path -mem-prealloc. But does it have any meaning to do anyway? I don't know.
I don't know about these but I don't think it would make a difference unless you need at least 16GB or terabytes of guest memory. With just 2GB that AmigaOS can use it probably does not matter.
Quote:
Lastly, by the time I started this thread, I have tried a tremendous number of combinations (UEFI, Host OS, Qemu parameters, even hardware alterations by moving RX550 upwards), running @Hans tool each time, but I never managed to get a GPU score greater than 250. Irrelevant, but disabling Intel's hyperthreading to utilize a physical core without threads gave the guest a little boost indeed, but not a GPU boost.
According to your previous radeontop results where a Windows guest could fully load the GPU while AmigaOS much less there seems to be something limiting the throughput to send commands to the GPU. This could be slower CPU with TCG but then I suggested to verify that running the Windows guest with -accel tcg and see if it's still faster. I think just the slower access to VRAM may not explain this all but I don't know how AmigaOS works and what may cause it to wait between sending commands that makes it slow. So @Hans or some other expert should recommend some way to test that or say what needs to be veriified that could cause this.
Quote:
The worst thing is that every time I run QEMU with RX550 passed through, by the time I stop the QEMU process, the GPU never actually "returns" to the host. So, I have to reboot my system after every single QEMU/VFIO run.
I think it's a general problem with Radeon cards, not related to AmigaOS and a link I've posted before talked about some vendor reset kernel module for your host Linux kernel that can reset the card and solve this but it's not in upstream kernel because it's too specific to Radeon cards so you need to install it separately. Maybe you can try that if you have nothing else left to try
I know. I'm not intending to use it for any demanding graphics task. Just to satisfy my "Amiga GPU passing through" growing obsession. I'll take it, I think.
I think it's up to you if you want to spend time and money on it. Having two different cards at least could show if a problem is specific to one card or happens with both which may show it's either host related or something the same with both cards while if it works with one card then we know the issue is something that's different with the other card. So in that it could help but for actual usage it may not be much different.
So in that it could help but for actual usage it may not be much different
You mean that I will have similar drawing problems even if it doesn't (hopefully) have the bottleneck of RX550? I thought that its capabilities would be more than enough to have just the workbench working properly...
Quote:
I suggested to verify that running the Windows guest with -accel tcg and see if it's still faster
. Yes, I forgot to try this, I'll do.
Quote:
BAR 6 is the ROM which is only mapped by the firware while running it with the BIOS emulator so probably won't be mapped after that or when not using firmware. Or the driver probably maps it while parsing AtomBIOS but unmaps afterwards. The audio part is probably not recognised by a driver so not mapped.
I see... There are also those AC97 devices that are loaded and I don't want them to (if I want to passthrough GPU audio, I suppose)
Edited by nikitas on 2024/6/25 15:25:23 Edited by nikitas on 2024/6/25 15:30:22 Edited by nikitas on 2024/6/25 15:30:40
You mean that I will have similar drawing problems even if it doesn't (hopefully) have the bottleneck of RX550? I thought that its capabilities would be more than enough to have just the workbench working properly...
I don't know. You might get lucky and an HD card might work better, or if this is some issue with your host or host Linux it might work the same or even not at all if it has different issues. Likely nobody can tell so the only way to find out is if you try it but it's not guaranteed to be better than with the current RX card. Only if you happen to have a problem only affecting RX cards then maybe you won't get that with an HD card. But since we don't know what causes the problem we also can't tell if another card would have it or not.
Quote:
There are also those AC97 devices that are loaded and I don't want them to (if I want to passthrough GPU audio, I suppose)
The via-ac97 sound function is part of the south bridge so you can't disable it but you can change the setting in AHI prefs (or whatever Enhancer has instead if that works) to a driver for the sound function of the GPU if there is such driver. I don't know how that works on AmigaOS. But that the BAR was not mapped suggests there was no driver loaded for it or if there was a driver it may not have recognised it. Maybe you can check logs from AmigaOS if there are any errors regarding this GPU function.
In QEMU command, the mouse is not detached from the guest. At least for the 10 minutes that I was testing, both keyboard and mouse worked without detaching.
@nikitas I got that it does not work with pci.1 but asked for logs to try to find out why. My guess is maybe this card has a lot of memory and there's not enough free space to map it in the pci.1 window while pci.0 may have more space and no other devices use that up. But it's just a guess without seeing the logs that show what happens. I think all devices generating interrupts on pci.1 should work but I'm not sure interrupts from both pci.1 and pci.0 can't conflict somehow so that's why I want to fix it on pci.1 to see if it may work better or with interrupts enabled that way.
Yes, using input-linux,evdev should also work, then you can drop bochs-display. I didn't know about it (QEMU has a lot of features so I don't know much of it) but here is the doeumentation from the time it was added. Maybe it's also in the main docs and in some other guides. The difference is that usb-host passes through the USB device to the guest and the guest driver will drive it so the host should not access it while input-linux keeps the devices driven by the host drivers just can grab and redirect keyboard/mouse events to the guest. So then you don't need a window to do that hence no bochs-display is needed. It only works on Linux host though but so is vfio pass through where this may be needed.
SmartFirmware:
cpu0: PowerPC,74x7 CPUClock 1533 Mhz BUSClock 133 Mhz (Version 0x8002,0x0102)
no/bad nvramrc - performing default startup script
Invalid write at addr 0xFE0003FB, size 1, region '(null)', reason: rejected
Invalid write at addr 0x3FB, size 1, region '(null)', reason: rejected
Invalid write at addr 0xFE0003FC, size 1, region '(null)', reason: rejected
Invalid write at addr 0x3FC, size 1, region '(null)', reason: rejected
Invalid write at addr 0xFE0003F9, size 1, region '(null)', reason: rejected
Invalid write at addr 0x3F9, size 1, region '(null)', reason: rejected
Invalid write at addr 0xFE0003FA, size 1, region '(null)', reason: rejected
Invalid write at addr 0x3FA, size 1, region '(null)', reason: rejected
Invalid read at addr 0xFE0003FA, size 1, region '(null)', reason: rejected
Invalid read at addr 0x3FA, size 1, region '(null)', reason: rejected
channel 1 unit 0 : ata | QEMU HARDDISK | 2.5+
ATA device not present or not responding
Welcome to SmartFirmware(tm) for bplan Pegasos2 version 1.1 (20040405172512)
SmartFirmware(tm) Copyright 1996-2001 by CodeGen, Inc.
All Rights Reserved.
Pegasos BIOS Extensions Copyright 2001-2003 by bplan GmbH.
All Rights Reserved.
entering main read/eval loop...
ok
Both do not show anything on screen. And as long as I have the process open, the GPU gets crazy - all the metrics of the Radeontop are at 100% load.
Edited by nikitas on 2024/6/25 20:49:19 Edited by nikitas on 2024/6/25 20:52:02
@nikitas Does the Invalid write at addr 0xFE000080 / 0x80 show up with bus=pci.0 as well or only with pci.1? It's probably not related if it shows in both case. If the GPU is busy then something is talking to it. Do you get any logs from the driver with debug kernel and -append 'serial debuglevel=<whatever is a good number here for RX driver>' or setting os4_commandline when using the pegasos2.rom. Where does romfile=vbios-ati.rom in your command come from? Is this a dump of the actual rom of the card or does it match the card? Why do you need it at all? If it can't find the rom without that isn't rombar=1 enough? Why do you need to specify PCI IDs on the command? Aren't they found from the card?
In any case it does not seem to be a problem with PCI window size, the BARs were mapped in the bboot output at 80000000/90000000 so there's enough room for pci.1 too. How did you get unmapped BARs in 'info pci' then? Did something unmap it later (e.g. the driver failing to init the card but then why we don't get logs of that with higher debuglevel)?
I will answer your questions in detail. But before that.
I have to say wtf... By enabling the RadeonRX.chip.debug and appending:
-append "serial debuglevel=7"
(Always using pci.1, not pci.0)
My serial output goes crazy by repeating the message below forever. The frequency at which these two messages are repeatedly printed in my console must be almost every clock cycle! (Okay, that's an arbitrary assumption, but they are printed extremely fast.) Does this thing probe my GPU so hard? And that's why I see a 100% load on all Radeontop metrics? It stays at 100% forever without dropping until I stop the process. Then, all the Radeontop metrics going back to 0%.
Of course, I don't understand what these messages mean. Is there an incompatibility in the guest PCI mapping, maybe?
RadeonRX (2): Cannot enable blind prefetch for PCI:0.0,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.12,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.12,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.0,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.0,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.12,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.12,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.0,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.0,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.12,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.12,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.0,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.0,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.12,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.12,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.0,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.0,0, because this device doesn't support it.
RadeonRX (5): RadeonRX (5): Cannot print bridge configuration for PCI:0.12,0, because it is not a bridge device.
RadeonRX (2): Cannot enable blind prefetch for PCI:0.12,0, because this device doesn't support it.
I get the same behaviour even after removing some devices and (unneeded) vfio-pci properties, like this:
After removing the sudo and the taskset -c 4 for command simplicity, though I think they are not playing any role on this, indeed, I get the same behaviour:
RadeonRX (9): encoder dpms 32 to mode 0, devices 00000080, active_devices 00000080
[mediaboot] Diskboot is present. Skip mounting static devices.
[USB] INFO | "USB stack" | "" | ==========
[USB] INFO | "USB stack" | "" | USB System Software Task started
[USB] INFO | "USB stack" | "" | Starting HCDs...
[USB] INFO | "USB stack" | "New Fkt" | Attached RootHub Fkt 0x6FF96960 at level -1 on HCD "uhci.usbhcd" unit 0
[USB] INFO | "USB stack" | "New Fkt" | Attached Fkt 0x6FF96A00 at level 0 on HCD "uhci.usbhcd" unit 0
[USB] INFO | "USB stack" | "New Fkt" | Attached RootHub Fkt 0x6FF96AA0 at level -1 on HCD "uhci.usbhcd" unit 1
[USB] INFO | "USB stack" | "New Fkt" | Attached Fkt 0x6FF96B40 at level 0 on HCD "uhci.usbhcd" unit 1
[USB] INFO | "USB stack" | "" | ...HCDs started.
[USB] INFO | "USB Fkt Init" | "Init Fkt" | [fkt 0x6FF96A00] Fkt is {Vendor: 0x0000, Product: 0x0000, Class: 09.00}
[USB] INFO | "USB Fkt Init" | "Init Fkt" | [fkt 0x6FF96B40] Fkt is {Vendor: 0x0000, Product: 0x0000, Class: 09.00}
[USB] INFO | "USB Fkt Init" | "Init Fkt" | [fkt 0x6FF96A00] Fkt ("","Rear Roothub (uhci.usbhcd/0)","") initialized
[USB] INFO | "USB Fkt Init" | "Init Fkt" | [fkt 0x6FF96B40] Fkt ("","Front Roothub (uhci.usbhcd/1)","") initialized
[USB] INFO | "hub.usbfd" | "HUB" | Hub "Rear Roothub (uhci.usbhcd/0)" has TT thinktime of 8 full speed bittimes and protocol 0 (ifc 0x6FEF9E90)
[USB] INFO | "hub.usbfd" | "HUB" | Hub "Front Roothub (uhci.usbhcd/1)" has TT thinktime of 8 full speed bittimes and protocol 0 (ifc 0x6FEF9F90)
[USB] INFO | "hub.usbfd" | "HUB" | All ports are empty (ifc 0x6FEF9E90)
[USB] INFO | "hub.usbfd" | "HUB" | All ports are empty (ifc 0x6FEF9F90)
[USB] INFO | "hub.usbfd" | "Sys_EndInitialAttachmentPhase" | Initial USB Attachment Phase terminated
[bootmenu] Detected machine type = Pegasos II
[bootmenu] No preferred BootDevice specified
[bootmenu] Preferred keyboard device is "keyboard.device" unit 0
[bootmenu] PeekQualifier(): LMB is up, MMB is up, RMB is up
[bootmenu] Input handler installed
[bootmenu] Waiting 100 ticks for user input
[bootmenu] No user input detected within wait loop
[bootmenu] Removed input handler
[bootmenu] PeekQualifier(): LMB is up, MMB is up, RMB is up
[bootmenu] Continuing normal boot sequence
[strap] Begin
[strap] Skipping non-boot node 0x6FFA83E2 (type = 111)
[strap] Skipping non-boot node 0x6FFFD600 (type = 0)
[strap] Skipping non-boot node 0x6FFFDA40 (type = 0)
[strap] Device node "DH0" is boot point device
[strap] Handover to dos for "DH0"
[DOS] Starting DOS 54.112 -- Kernel debug level is 7
[DOS] Bootnode from expansion->mountlist is device name "DH0"
[DOS] "Initial CLI" process started, doslib creation task now ending.
[DOS] NOTE: CliInit()->Dev_Startup() - No handler dn_SegList for "SWAP:"
Envec=0x6FF3DA00, DosType=0x53574150 [SWAP]
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
