While running the GPU test, I see in the host isolated core that the "Local Timer Interrupts" number is growing by about 5000 per second. Does this might indicate that the CPU core is used heavily during the GPU test?
@geennaam had mentioned that
Quote:
Anyways, it works. So if someone is really dedicated to qemu then he could buy a mobo with two x16 slots and a Ryzen 7800X3D and enjoy a fast system.
I'm using a much inferior Ryzen 3200G with x8 PCI slot. I wonder if the usage of a much powerful CPU + doubled PCI lanes solves the problem or just hides it.
i have been wanted to go down this road my self and do some testing.. but i fear it is difficult to setup. my main pc is ryzen 9 7900x with radeon 7900xtx with 64gb, i also have sam460ex.. and got a few gfx card to test with, old 7979 3gb 470x 8gb, vega 56. i will home in 3 weeks because of work.. if anyone willing to guide me i can can test thing out on this machine
nox
Sam460ex 2GB 120Gb SSD&1Tb HD7750 Envy24HT A-Eon Drv 2.10+Warp3D New Uboot Apollo v4 Standalone
No, R7 240 is much slower in this host. It's not being able to start the Workbench components like Amidock. It took 3 minutes to load the workbench completely.
@nikitas Why are you using taskset to limit qemu to a single host core? Even if qemu is single threaded in most parts I don't understand how that's supposed to make it faster instead of slower, and I don't remember geennaam mentioned using it.
Using Pegasos2 instead of AmigaOne emulation might be an additional problem, since it doesn't work on real hardware either, but geennaam used Pegasos2 emulation as well.
While running the GPU test, I see in the host isolated core that the "Local Timer Interrupts" number is growing by about 5000 per second. Does this might indicate that the CPU core is used heavily during the GPU test?
I'm not sure what to make of that. While the driver does use microsecond delays when polling certain registers, the timer device doesn't use interrupts for that.
I have no idea where those timer interrupts would be coming from, or why there are so many.
The scope of this problem is so broad that somebody could write a 20-page technical report only to sum up all the possible implications, including combinations of the cases that have already been tested, along with the detailed results so that they can be assessed afterwards. I don't think such a process can occur in public (or private) forums.
In addition, the Amiga OS and GPU driver copyrights raise a barrier that does not leave much room for forming any kind of hobby cross-party team.
The complexity of this issue gives me the impression that it resides in the "Amiga" side (that fragmented into a thousand pieces of companies & copyrights thing) to form a team of devs with qualifications similar to yours and @balaton 's (and possibly a hobbyist-volunteer beta tester like me!), to write code both on QEMU & OS/GPU driver sources in order to support it (like Microsoft, RedHat(IBM), etc, do). The opposite may not be a viable solution for this particular problem as it might need to be approached with a well-structured "Assess-Plan-Do-Reassess" procedure.
Ah, if he's running Tequila/heironymus for profiling, then that could explain it.
This discussion makes me wonder how MicroDelay() behaves under emulation. I have no idea how that function works, but the driver does use it for very short delays. Longer delays use a timer interrupt.
@nikitas
These "needle in a haystack" searches tend to be slow and time consuming. They're faster when developers have direct access to the hardware in question, but you never know how long it'll take to finally find the root cause.
They're faster when developers have direct access to the hardware in question
Yes, I can understand that. If this is the case, as an extremely ultimate and desperate try, I would propose that you and @balaton take control of my desktop via Anydesk/Google Meet/Teamviewer when you are available. You can also view my hardware and UEFI settings in real-time using my mobile phone camera and direct me accordingly. Due to my job obligations, I can only be available in the afternoons and weekends.
If you judge that this approach could help the situation, you tell me.
As long as it's not proven it's caused by hardware or the host's firmware the rest is software we can modify so it should be fixable once we find what causes the issue. Quote:
I need to forget.
Forget about AmigaOS for now but if you still have some patience left you could try setting up any machine with any card (could be the AMD one with the HD card) and configure the card with vesa driver and ShadowFB=0 as @Georg suggested and measure the VRAM access without any QEMU and vfio using x11perf. If that's faster than what we get with QEMU then set up vfio and try a Linux guest (same as the host in first step) and see if it's slower/same. If it's the same try same Linux guest with -accel tcg. Then try to make similar config with PPC Linux guest and do the x11perf test with that. This is supposed to show what point speed is lost or if these all are fast then problem is likely in what AmigaOS does.
These "needle in a haystack" searches tend to be slow and time consuming. They're faster when developers have direct access to the hardware in question, but you never know how long it'll take to finally find the root cause.
It might help if you could test this yourself but that would need you to set up a Linux host which seems you'd like to avoid. Or maybe try to search if vfio on Windows host is possible. It's a crazy idea but who knows, these days Windows can also run Linux programs.
Yes, I can understand that. If this is the case, as an extremely ultimate and desperate try, I would propose that you and @balaton take control of my desktop via Anydesk/Google Meet/Teamviewer when you are available. You can also view my hardware and UEFI settings in real-time using my mobile phone camera and direct me accordingly.
I'll pass that. I don't think this would be very convenient or I could give better advice than over this forum. I'm also a hobbyist not affiliated with any AmigaOS or QEMU companies and do this in my free time. I could try to get a card and try it myself but I have no drivers for it and still have enough to do without that so I'd prefer somebody helping doing all the testing that takes the most time. With Hans it might be an issue with time zones as he's on the other side of the globe.
Maybe some of the speed loss is really just normal because it has to go through software mmu emulation. Can't compare with UAE/AOS Classic where you usually don't have that at all.
@Georg That can only explain some slowdown, for example your VRAM results with host vesa driver and shadowfb disabled being 3.3-4.6 times faster than geennaam's results with AmigaOS guest on QEmu, but not nikitas' extremely slow results with the Radeon HD card which are more than 70 times slower than geennaam's results and more than 300 times slower than your ShmGet/PutImage ones.
@nikitas Thanks, but I don't think that remotely using your machine is workable. Maybe slow down a bit, and take a break. I've had times where I spent days to weeks trying to solve one "small" problem, and it can drive you nuts.
If you have run a statistical profiler while running GfxBench2D, then I'd be interested to see the results.
@balaton Quote:
It might help if you could test this yourself but that would need you to set up a Linux host which seems you'd like to avoid. Or maybe try to search if vfio on Windows host is possible. It's a crazy idea but who knows, these days Windows can also run Linux programs.
I don't have the necessary hardware. My laptop has an nVidia GPU (and Linux is installed on an external drive).
@Georg Quote:
Maybe some of the speed loss is really just normal because it has to go through software mmu emulation. Can't compare with UAE/AOS Classic where you usually don't have that at all.
That certainly would cause some slowdown, although it cannot explain the difference between geennaam & nikitas' results.
I've done some quick internet searches, and there are people who get really bad performance with VFIO & Windows (e.g., here, and here). They usually seem to be able to fix it by fiddling with all sorts of settings. It's not clear to me if their slowness is caused by problems accessing the GPU, or something else.
I also noticed that everyone using VFIO, is using QEmu in KVM mode, which means that the guest OS can execute code on the host CPU directly instead of via emulation. I found nothing about VFIO usage with the TCG based emulator. Looks like we're in uncharted territory.
That certainly would cause some slowdown, although it cannot explain the difference between geennaam & nikitas' results.
You mentioned MicroDelay() and it could be caused by it as it will be some kind of busy loop checking some powerpc timer register. If qemu emulation of it is not very precise (may depend on host or even host (kernel) configuration = there may be difference between running Linux distribution A vs distribution B) then this will slow things down as it will cause the delay to last (possibly much) longer than expected.
Could be tested with a little AOS4 program which for example calls MicroDelay(10) 100000 times in a loop. Should complete in 1 second. If it takes (much) longer -> problem.
@balaton About the --accel kvm --> --accel tcg on the Win VM are you sure it is so straightforward?
I converted the virsh Windows 11 VM XML to native Qemu.
Changed the --accel kvm to --accel tcg. The qemu command is very extensive and does not work from the command line. Libvirt must do some extra work before running the command.
I just got a reminder of some of geennaam's older discoveries. According to him, his Radeon R9 270x worked well provided that he didn't share part of his hard-drive with AmigaOS as a USB drive, and he also had to shut down ethernet. With either of those enabled, he got massive slowdown.
So: - Qemu 9.0.1 + vfio R9 270x: Smooth experience and all 3D features works as on a real system. See gfxbench2d result 2828 - Qemu 9.0.1 + vfio R9 270x + hdd share as os4 Usb-storage: Massive slowdown (was also the case for 8.x.x) - Qemu 9.0.1 + vfio R9 270x + Ethernet connection: Same massive slowdown
He also tried Radeon RX cards, and those were very slow. Disabling ethernet didn't solve anything.
It sounds like something is on a knife-edge. A slight change in conditions, and the thing slows down like crazy.
@Georg To help testing, could you please share your Linux kernel options and xorg.config to show how to set up vesafb and the x11perf command again so others can reproduce that test without having to find out the right config?
Also if somebody has a compiler for AmigaOS could try to compile a test for MicroDelay and check if that works. I don't have the AmigaOS SDK installed so can't make test for that at the moment.
@nikitas The -accel tcg should work with a normal QEMU command. Why don't you run Windows with a similar command as you used for AmigaOS or run a Linux guest instead of Windows. Virsh just adds additional complexity here.
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
