Invalid write at addr 0xFE000080, size 1, region '(null)', reason: rejected
Invalid write at addr 0x80, size 1, region '(null)', reason: rejected
These should not cause any issue. This port is either used for debugging or some drivers may use it for small delays so accessing it may be normal. As this was seen regardless of the graphics card it may not even be related to it.
Quote:
invalid eieio using bit 6 at @fff063dc
Entering IKARUS low level console
This should not happen. It either means that your pegasos2.rom is somehow corrupted or is a version not supported or your host machine has some issues so maybe run memtest on the host and some stress test such as compiling a Linux kernel to make sure the machine works OK. Which version of pegasos2.rom do you have and if you have extracted it from an updater does it match if you get the updater again end extract it again to make sure it's not corrupted?
What in the world could be happening with my machine... Every power management is disabled in UEFI. And I followed instructions to disable every PCIe power management on Ubuntu 24.04. I'll investigate further though.
One thing is to disable power management on the host and then another to configure the guest to also not try to use it. I'm only guessing but maybe it is a problem trying to use PCI power management on a PCIe card. We're passing through the PCIe card as PCI so the guest may not be able to access all features. Or if the guest tries to use PM while it's disabled on the host that may cause issue. So either set the guest to also not use PM or allow it on host?
Quote:
In the worst case, I will keep the cards and I'll throw the PC into the sea. I might get one with a Ryzen CPU.
I would like to advise me if you know what mobos + CPUs combinations serve best QEMU/KVM, QEMU PPC, and virtualization in general.
I don't know, I don't have much experience with vfio pass through. Generally for these AmigaNG virtual machines the faster a single core is the better and Intel CPUs used to be better in that while AMD may have more but slower cores but QEMU will only use 1-3 cores and only one to emulate guest CPU (it can do one thread per vcpu but AmigaOS only runs on a single CPU core and these machines are single CPU anyway, hence having one fast CPU core is better than having lots of slower ones). For vfio you'd have to read on the net. It can depend on a lot of things including motherboard and firmware so maybe some boards are better than the others but I don't know which might those be. It may depend more on firmware quality than Intel vs. AMD. Also may check if your host machine's firmware is the latest in case some bugs were fixed.
This should not happen. It either means that your pegasos2.rom is somehow corrupted or is a version not supported or your host machine has some issues so maybe run memtest on the host and some stress test such as compiling a Linux kernel to make sure the machine works OK. Which version of pegasos2.rom do you have and if you have extracted it from an updater does it match if you get the updater again end extract it again to make sure it's not corrupted?
But qemu in "standard" mode works with that rom. I can launch pegasos2 emulation without any issues. And i've compiled qemu on host without issues (and it stress the machine a lot..). I don't think host machines has issues.
Edit: I had that problem because memory was set to 2GB with pegasos2.rom and it doesn't work. Now the system is loading but it is slow as hell.. Loading kickstart components takes ages, while with normal pegasos2 emulation it is really fast
Edit2: Removing port forwarding fix the problem and both pci.0 and pci.1 worked without any problem. But even if the system starts I don't know how to see the exteral monitor since ,x-vga=on doesn't work. So I have no display.
Edited by afxgroup on 2024/6/28 8:39:23 Edited by afxgroup on 2024/6/28 8:53:14
@balaton Applied your patch and recompiled. Radeon R7 240 on PCI 0 does not work. I'cant say why, because the host system freezes completely. In pci.1, it works with the same slow VRam <=> RAM issues.
Then I replaced Radeon R7 240 with RadeonRX 550 by attaching it to the uppermost PCIe slot of my host machine.
In pci.1 it falls into the known endless loop. In pci.0 it boots, and I got the best Gfx2DBench results ever with an overall score of 300 (almost!) and FillRect operations/s at 172 instead of the previous RX test in which FillRect operations/s were at 100.
Despite the improved results: - The gap between this and the expected results is still chaotic. - Radeon RX 550 is still slower than R7 240 on drawing. R7 240 had 470 operations/s on FillRect (if I remember correctly), in contrast with RX550's 172 FillRect operations/s. - RadeonRX 550 is very slow but much faster on VRAM <=> RAM operations compared to R7 240.
Does the above mean that the RadeonHD.chip is doing better than RadeonRX.chip in general?
@balaton Along with the latest patch you've published, should I also apply the previous two patches you posted on this thread and recompile?
@Hans In order to have a better view, I'd like to know the host machine specifications of those who tried QEMU PegasosII + AmigaOS4.1FE + VFIO'd RX550/R7 240 and got much better Gfx2DBench results than I did.
@afxgroup OK, just wanted to make sure there're no issues with the host. If you could cpmpile QEMU on it it should work. My second guess would have been memory as I've only seen that error when problem with memory happened but you've already found that too.
As for x-vga=on I don't know if it's needed or not, I think @nikitas got it working without it too but if it's needed maybe something is using that on the host. If you still see anything on screen from the host then the GPU is not isolated completely. The host should not use the GPU at all which might not be simple to do on a laptop. On a desktop machine you'd pass through a secondary card while the host is using either the embedded graphics or another card. Also you may need to check vfio groups and if the GPU can be passed on its own or there are other devices in the same group that may need to be passed through as well. I think you should check docs on vfio pass through and test with a Linux guest to see if it works before trying AmigaOS.
@nikitas OK, thanks for testing. It at least fixes the IRQ problem so you don't have to disable it. This helps but that's not all of the problems. Also now pci.0 should be the same as pci.1 because I've asked to test with pci.1 to check IRQ problems. (Unless the driver does something different for PCI and AGP in which case using pci.1 might still be better but the issue with the driver would need to be fixed for that. I can't do that so @Hans will need to check if your driver version is already fixed or this is another case that needs a fix.)
Quote:
Along with the latest patch you've published, should I also apply the previous two patches you posted on this thread and recompile?
You can try that, these patches change different things. The first 3 patch series change AltiVec to use 128bit instead of 64bit so it may help with VRAM access with the default G4 but not with -cpu 750fx (or whatever is a good g3 CPU now). The other dcbz patch might help a bit with the same VRAM access but also with G3 cpu but I'll make a new version of that trying to improve it a bit but had no time for that yet. For now you can try these patches and see if they make a difference.
As for x-vga=on I don't know if it's needed or not, I think @nikitas got it working without it too but if it's needed maybe something is using that on the host. If you still see anything on screen from the host then the GPU is not isolated completely. The host should not use the GPU at all which might not be simple to do on a laptop. On a desktop machine you'd pass through a secondary card while the host is using either the embedded graphics or another card. Also you may need to check vfio groups and if the GPU can be passed on its own or there are other devices in the same group that may need to be passed through as well. I think you should check docs on vfio pass through and test with a Linux guest to see if it works before trying AmigaOS.
But why? I have two cards here. the Intel and the RadeonRX. And I can see them also in System Details:
So if I isolate the Radeon, the first graphic card works in any case and I can see everything. And if I add the radeon to vfio, in system detail the card is not shown anymore. So everything seems correct Now i have found something. qemu show me an error:
qemu-system-ppc: vfio-pci: Cannot read device rom at 0000:3b:00.0
Device option ROM contents are probably invalid (check dmesg)
Skip option ROM probe with rombar=0, or load from file with romfile=
@Hans And Nikitas's benchmark results above say "RadeonRX.chip 2.12" so maybe an update is needed for it to work with pci.1. I don't know it that would help but at least we have an explanation for the error we get now and a possible fix to try. Which update includes v2.16 RX driver?
@afxgroup OK if this laptop has both integrated and discrete graphics then you can pass through just the radeon chip but there may be issues:
- How are these connected? Normally both of these GPUs would drive the internal screen but the firmware or OS would switch between them. So it could be that when the Radeon chip is not used the integrated GPU is connected so you won't see the output of the Radeon chip. Is there a way to configure it to drive the display connector while the integrated GPU drives the laptop screen? If not you may need to enable discrete GPU so it's connected to the screen but not use it from the host and pass it through to the guest. I don't know how to do all that but maybe there are some tools or Linux settings to control the discrete GPU in such machines. I think the doc I've found was using a laptop with integrated Radeon GPU that it passed through to the guest so this problem with which display it's connected to was not a question in that case.
- The AmigaOS driver may need the BIOS but a GPU in a laptop might not have it's own BIOS as it could be part of the system firmware. I don't know what to do in that case. You could pass a ROM image with romfile property but it can't be any random ROM but something that matches the settings for the internal GPU (otherwise you may break it if it tries to program with wrong values not suitable for the chip; I don't think it allows to overdrive and permanently break the chip but likely won't work with just any ROM from a similar graphics card but it has to match the memory and clock settings of the internal chip). If the internal card has it's own BIOS ROM then maybe it's enough to add rombar=1 and maybe run QEMU as root.
Btw, if guest has access to VRAM of pass through gfx card => qemu process has to have access, too. Maybe if you know (real) address of VRAM you can compile a small vram benchmark function into qemu . Then run qemu with gdb, break into gdb, "jump my_vram_benchmark_function". To see what kind of transfer rates native code (instead of emulated, jit-ed PPC code) has with such a pass-through gfx card.
Regarding the RadeonRX.chip version, I own the AOS4.1 Pegasos Edition and the Enhancer Software v2.2. I've also run the Enchancher's updater. The RadeonRX.chip 2.12 is the most updated version I get.
Regarding the RadeonRX.chip version, I own the AOS4.1 Pegasos Edition and the Enhancer Software v2.2. I've also run the Enchancher's updater. The RadeonRX.chip 2.12 is the most updated version I get.
I'll have a chat with beta testers & A-EON about getting it updated. That won't solve the performance issues, though.
Could you try running a statistical profiler like hieronymus or Tequila when running GfxBench2D? I don't know how accurate they'll be under emulation, but it would be useful to know how much emulated CPU time the driver is taking.
Run GfxBench2D with -nm -nc -nr to skip the memory, compositing and random tests.
I'm trying to think about what bottlenecks could be possible: - Slow access to graphics card registers? If so, why? IIRC, the register accesses use PowerPC endian-swapped read/write instructions - Clearly there's slow VRAM access, but Geennaam's RAM<=>VRAM copy results were worse, yet his blitter performance was way better - The GPU tells the driver what operations are done by writing a value back to a spot in VRAM (or RAM if GART is enabled). Is there a problem with reading back this value? - What else?
I'll have a chat with beta testers & A-EON about getting it updated. That won't solve the performance issues, though.
Even if it won't solve the issue it would allow testing with pci.1 to make sure it's not working differently with different PCI buses.
Quote:
I'm trying to think about what bottlenecks could be possible: - Slow access to graphics card registers? If so, why? IIRC, the register accesses use PowerPC endian-swapped read/write instructions
If those instructions are badly emulated maybe could cause slow down but I don't expect that to explain such huge bottleneck.
Quote:
- Clearly there's slow VRAM access, but Geennaam's RAMVRAM copy results were worse, yet his blitter performance was way better
That was with an HD card although Nikitas got the same slow result with an HD card too so maybe something with his host machine/firmware or Linux?
Quote:
- The GPU tells the driver what operations are done by writing a value back to a spot in VRAM (or RAM if GART is enabled). Is there a problem with reading back this value?
Is there a way to test that?
Quote:
- What else?
Power management issues that leave the card in lowest power setting as you suspected before? Where can one see the GPU clock value in the test results or where did you get this info from? With Linux guest there was also a PM related error.
But I think Nikitas also ran the Windows version of the benchmark and that worked so maybe it's something PPC specific.
@nikitas Can you repeat the test with Windows using KVM, then the same Windows with adding '-accel tcg' to disable KVM and also with PPC Linux guest with x11perf if you can get any Linux version see the card and use vesafb instead of amdgpu which likely won't work or not present in the older Linux versions that boot in AmigaNG?
Not really. Normally if readback of the execution ID fails, then the graphics acceleration hangs because it ends up waiting forever. I can't think of any way to check if a cache regularly returns a stale version or not.
Quote:
Power management issues that leave the card in lowest power setting as you suspected before? Where can one see the GPU clock value in the test results or where did you get this info from? With Linux guest there was also a PM related error.
The dpm unit did switch the sclk up one notch at one point (according to nikitas' log), so the dpm does appear to be functioning normally. Commands are being submitted so slowly that there's no need for it to increase the clocks.
Nikitas also reran the test with power management set to high to no effect.
I'm watching your posts, but I didn't respond because I was on an 11-hour marathon with Qemu/AOS4.
In order to rule out the possibility that my host machine is not working as expected for QemuPPC/VFIO GPU/AmigaOS4.1FE, I prepared a new setup on a new machine with ArchLinux as the host OS. The ArchLinux installation was unimaginably complex (as it has nothing preinstalled and preconfigured). In fact, I installed every package I needed, including any configuration from networking to Xorg to display manager, etc, by hand, thanks to its fantastic documentation. Anyway.
New machine's Specifications: - AMD Ryzen 3200 CPU - ASRock Motherboard - Integrated VEGA 8 GPU - 32 GB RAM - I plugged the Radeon RX550 (planning to use it as a secondary GPU for Vfio passthrough).
Yes, it is (much) slower than my previous host machine in terms of CPU performance. But I hope it can handle a single-core OS like AOS4 well enough. And indeed until now I don't see any difference...
(I will update the specifications, providing more details later)
It seems to go faster, but it might be a placebo effect. So, I run the GPU tool right now and will post the results.
For now, I think I want to inherit Amigans Defender's signature.
On chip caches: - L1: 32 kB, 8-way associative, 64-bytes line size - L2: 512 kB, 8-way associative, 64-bytes line size - L3: 4 MB, 16-way associative, 64-bytes line size
Motherboard ASRock A320M-HDV R4.0 Bios American Megatrends Inc. P4.00 07/16/2020 Chipset: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge
Operating System - Arch Linux - Kernel: Linux 6.9.7-zen1-1-zen
RAM - 2 x 16GB
PS: @balaton Quote:
Can you repeat the test with Windows using KVM, then the same Windows with adding '-accel tcg' to disable KVM
I changed the domain type from kvm to tcg. It didn't start, but I didn't try anything more. I'll unplug the RX550 from the New host, replug on the Old host and I will try things, and it will work eventually. But I don't know if it is needed anymore after the latest news...
You could try your R7 240 on the new host, if it doesn't have the same extremely slow VRAM access speed as on the old host it might be usable, or at least closer to geennaam's results.
But the overhead that is being introduced by VFIO GPU passthrough in contrast with the emulated sm501 can't be justified.
VFIO PCI just passes the control of the device to the guest. The QEMU process, as I read, does only this thing.
Also, there must be a difference in RadeonHD.chip and RadeonRX.chip on how they handle the GPU resources, because R7 240 VRAM <=> RAM collapses, as @Hans mentioned, but the drawing is faster.
I'm ignorant of GPU resource handling and development, but my humble thought is that it does not make sense for a much, much inferior card to perform better on drawing.
Another thing that makes the difference is the compositing effects switch. If I use GPU passthrough and have this enabled, the AOS4 freezes at some point completely, no matter what GPU I use.
If I disable GUI --> compositing effects, I have a slow but working environment.
I mentioned before that the zTools package I got from Amistore contains a Sysmon app. In the GPU view, there is a "compositing" field. The value of this field is "inactive." Of course, in this emulated environment, trusting the guest organs (Ranger, Cpu_watcher) has already been proven wrong.
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
