Who's Online |
11 user(s) are online ( 9 user(s) are browsing Forums)
Members: 1
Guests: 10
nbache,
more...
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 16:06
#61
|
Quite a regular 
|
@nikitas Quote: 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.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 12:14
#62
|
Quite a regular
|
@nikitas Quote: 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.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 12:11
#63
|
Quite a regular
|
@nikitas Quote: 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 
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 12:00
#64
|
Quite a regular
|
@nikitas Quote: 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 12:17:59
Edited by balaton on 2024/6/25 12:20:04
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/25 11:55
#65
|
Quite a regular
|
@nikitas Quote: 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.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/25 11:38
#66
|
Quite a regular
|
@white Quote: Because I have always had problems installing from the "Extras" CD I had to do them manually.
In practice, if I try to install the "Extras" it tries to overwrite the AmigaOS CD and it doesn't install them on "HD0"
And even through "bios" I can't give priority to "DH0" even if I choose it to boot.
And the CD is always seen as the first unit. You can try to boot without the CD inserted and insert it after the system booted to have the right SYS volume. To do that remove all -cdrom or -device ide-cd options from your QEMU command and only leave the HD. Once AmigaOS booted from HD you either have a QEMU menu item to insert a CD image or open QEMU monitor and see 'info block' this should show you have an ide1-cd0 drive and you can insert an iso image in it with the change command. See 'help change' for docs but it should work like: 'change ide1-cd0 path/to/cdrom.iso' I don't know what is the correct format for path on Windows, it may be easiest to copy the iso to the dir you start QEMU from so you can just use the name. Otherwise it may take a unix path (using /), a Windows path (using c:\) or maybe a cygwin path (using /c/ or something like that). After issuing the change command you can check with info block again if the image is inserted but it should then show up in the guest so you'd notice if it worked. (This should work with amigaone and pegasos2, maybe not with sam460ex which ohly has 2 SATA ports so for that you'd need to add an ide-cd manually, before you can change disks in it.) I don't know what are your other issues or what could be a solution for those.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/24 11:44
#67
|
Quite a regular
|
@white
You can disregard the gtk warning. It's just because it was built with gtk but does not come with some theme files it looks for. This is a problem in packaging the QEMU build so ask where you got this build from. But this does not affect functionality, maybe only some image is different in the QEMU menu or similar but it would run the same. You can try to add -display sdl in case that's compiled in, that would get rid of this warning (but also the QEMU menu and may display a bit differently).
Also 9.0.1 probably does not have anything that would help PPC or AmigaNG emulation so using 9.0 should be fine.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/24 10:47
#68
|
Quite a regular
|
@white
If you're using BBoot you need to recreate Kickstart.zip after installing an update that updated files in SYS:Kickstart. When booting with firmware it should load kernel and modules from disk so in that case I don't know what could be the problem.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/24 10:36
#69
|
Quite a regular
|
@Hans Quote: 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.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/24 10:32
#70
|
Quite a regular
|
@Hans Quote: Your trouble with interrupts being enabled suggests that some interrupts are being missed. Nikitas, can you post your command line and verify you use latest BBoot version? Interrupt problems should be fixed by that on pegasos2 but I'm not sure if using different PCI buses can't still have some issue. Maybe we should find out why it did not work without bus=pci.0 as only using the default PCI bus was tested so far.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/24 10:29
#71
|
Quite a regular
|
@nikitas
If you ask about patch 3 of the altivec 128 bit series I've linked to first then that did not apply for me cleanly either. You can try with 'git am --3way mbox' or just 'git am --skip' when you get the error for patch 3 as that is for VSX ops and the AltiVec/VMX is in patch 2 so that should be enough for us and can skip patch 3.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 2024/6/24 10:23
#72
|
Quite a regular
|
@white See here for using BBoot or here for using firmware ROM image. You'll also need AmigaOne version of AmigaOS, you cannot boot the pegasos2 version on amigaone as each AmigaOS version only contains drivers and kernel for the machine it is for. So the command you posted should work. Did you get a problem with that or what was the question?
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/23 10:22
#73
|
Quite a regular
|
@joerg Quote: But IIRC at least one of 750FX or 750GX supports DCBA. According to QEMU only embedded PPC (e200, 4xx, e5500, e6500) and 74xx have DCBA, it's not emulated for any 750 CPUs which have DCBI instead.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/23 10:13
#74
|
Quite a regular
|
@nikitas
It might take a while until my patches are merged. Until then if you want to test it you can download mbox from the patchew link and use 'git am mbox' to apply it locally. You might want to do that on a new branch (e.g. after 'git checkout -b test-branch' so you can easily delete that branch and return to master or switch between them with git checkout).
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/22 21:14
#75
|
Quite a regular
|
I've sent a patch which improves dcbz a bit but it only removes a small overhead that was an easy fix but most of the problem still remains. It seems to spend most of the time with checking the address to see if it's in guest RAM but I don't know how to improve that. Maybe somebody on the list has an idea. (One can also see from the profile in the patch description that memset on the host already uses vector instructions so it wasn't that bad if the check to see if memset could be used didn't take that long. It's still better than removing the check and memset though which runs in 9.28 seconds with the above patch that runs it in 5.83 sec.)
Edited by balaton on 2024/6/22 21:37:17
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/22 19:05
#76
|
Quite a regular
|
@nikitas, @joerg
This test with VRAMCopy was run in user mode emulation that does not use a softmmu so the overhead probably comes only from managing translation blocks (and dcbz as discussed above). In full system emulation there is softmmu but with amigaone and pegasos2 which use CPU with hash MMU the guest passes translations in a table in memory so QEMU can look up the new translation without running guest code so a TLB miss is not much additional overhead.
With sam460ex PPC440 has guest managed MMU which means when a TLB entry is missing it will need to raise an exception and have the guest set the new translation. Additionally it will also invalidate all translated blocks for the old translation when it changes and has to recompile these. Previously all blocks were invalidated on any TLB write which made it very slow, this was improved with recent versions to only invalidate the entry that changed. Maybe there's still some improvement possible but the exception overhead cannot be removed so PPC440 will always be slower than G3/G4 because of this. This is shown by the stream benchmark posted by @sailor in an A1222 SPE thread. I've tried to optimise MMU on QEMU a bit based on that benchmark but I could not get it run much faster because of the above. I still have those patches on the list and not merged yet but it would only get marginal improvement in speed. The main point was to clean up the code to be easier to understand and maybe optimise further in the future but because of the above I don't think it can be optimised a lot.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/22 18:40
#77
|
Quite a regular
|
@nikitas
I could have said use -cpu g3 but I know some of @joerg's code has some CPU checks which break with an unknown CPU that wasn't in a real machine. I knew 750cxe was in one machine and I think it was tested by others before and found working but looks like it may also have some problems. So try those @joerg suggested but I don't think it would make much difference.
The reason to test with a G3 CPU is just to see if AltiVec may be worse than not using it. As G3 had no AltiVec but G4 has. The test with @Hans's copy routines showed that AltiVec is worse for these but the full test may have other usages that might be better so overall it may help. That's what testing with both the default G4 and a G3 without AltiVec test is supposed to try.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/22 17:51
#78
|
Quite a regular
|
@joerg Quote: But even the slowest 64 bit double implementations use DCBA (DCBZ as replacement on CPUs not supporting DCBA) and DCBT, which may make it slower on QEmu than on real hardware. DCBZ is the only potentially problematic op. All others are no-op and generate no host code as there's no cache emulated to operate on. DCBZ needs to be handled because it should zero the memory (and was found to be an issue when trying to run PPC32 code on PPC64 with KVM such as 32bit code on a G5 with KVM PR because the cache line is larger so it would zero too much memory so it needs to be patched and emulated but this should not be a problem for TCG which emulates it correctly but may be slower than not using it). But DCBZ is problematic, it explains why copyFromVRAMAltivec is the slowest. Removing the dcbz call from it makes it run in 2.05 sec so looks like optimising dcbz might help as a lot of OSes use this for zeroing memory (it was found to be used by MacOS as well). However it's questionable why this copy routine uses dcbz when it's then overwriting the values so maybe it should use someting that does not zero which would be no-op on QEMU. Anyway I knew about this issue with dcbz so it's nothing new, just need to eventually do something about it. I think it could be reimplemented to use TCG vector ops which would then be compiled to host vector ops when available. I don't know how that works in QEMU but if somebody is interested could have a look and submit a patch then might get advice on how to do it better. Or I may ask on the list and maybe somebody can make a patch for it.
Edited by balaton on 2024/6/22 18:36:51
Edited by balaton on 2024/6/22 18:50:12
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/22 17:14
#79
|
Quite a regular
|
@Hans I've made some tests with the copy routines. This isn't copying from VRAM just between two malloced buffers for now:
byte loop: 2.21 sec
memcpy: 2.21 sec
copyToVRAMNoAltivec: 1.7 sec
copyToVRAMAltivec: 2.13 sec
copyFromVRAMNoAltivec: 5.48 sec
copyFromVRAMAltivec: 6.17 sec
I did not check what these are doing or what makes them slower than expected. That's something for later. There's also a patch posted on QEMU list to improve AltiVec ops to use 128 bit. This isn't final yet, there will at least be a v2 as there was a review comment. This only improves the last copyFromVRAMAltivec case a bit which is 6.03 sec with this patch (at least for the memory case, maybe it's better with VRAM but don't know how to get a VRAM buffer on Linux). But it seems there's some other issue that makes it slower to fix first and for now not using any optimisation is the best. So I ask again if there's a way to disable CPU specific optimisations in AmigaOS to test that. By the way on the x86_64 host the same code runs:
byte loop: 0.314501 sec
memcpy: 0.316951 sec
copyToVRAMNoAltivec: 0.440696 sec
copyFromVRAMNoAltivec: 0.442047 sec
So hand optimisation may not be helpful and emulation has a lot of overhead for this kind of code.
|
|
|
|
|
|
Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
|
Posted on: 2024/6/20 12:58
#80
|
Quite a regular
|
@nikitas I don't know libvirt (maybe you could search 'virtmanager enable tcg' or similiar but if it has a way to add QEMU options then adding -accel tcg should enable TCG (unless libvirt adds its own -accel option which conflicts but there should be a way to select the accelerator used). It may be interesting to see if it might be an issue with TCG code vs. native CPU causes a problem. Another option is to have libvirt tell you the command it generated, copy to a script, edit that and run it without virsh. (If it does not tell you can find it in /proc/`pidof qemu-system-ppc`/cmdline) Quote: Also I found that when I use bboot v0.7 I can get 2G of RAM but Ranger & Sysmon tools report that the CPU clock synchronizes at 999Mhz. When I use the pegasos.rom, I get 1.53Ghz. Those tools probably don't measure the CPU clock just report what's in the device tree so this does not matter. The pegasos2 firmware uses 1.53 for G4 CPU and a different value for G3 which are probably hardcoded. QEMU has hardcoded bus-speed*7.5 which is the 999MHz. This does not affect the speed of the emulated CPU though, you would get the same benchmark with SysMon independent of the clock speed reported so you probably don't need to care about this. Quote: Thanks a lot for your explanation about the GPU drivers (Windows/Amiga). I'm enjoying this process because I'm learning things. And this is more valuable than achieving the actual (QEMU/AOS4/RX550) goal. Exactly. Doing this is fun because we can learn about things we might not know otherwise. i did not even know about MorphOS, AmigaOS4 or NG Amigas before started to work on these emulations just to see where the old AmigaOS went all those years I did not follow it.
|
|
|
|
|
News feed
OS4 Feedback forum
OS4Depot Feedback 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
