geennaam wrote:OK, weird, but I used a drawer mounted as USB drive to transfer data between QEMU and Linux. Now what that disabled it is definitely a lot faster.
Window resizing is a lot smoother. (compositing enabled) Running at 2560x1440@32bit now
Cow3D W3DNova manages 251 fps. That is a bit faster my SAM440-FLEX 800 MHz with the same R9 270x
- Night of the zombies 24fps menu / 10fps game /CPU 100%
Really great that you have tested this again. As far as I've been following this thread, the R9 270/x is best for passing through to Qemu.
It may sound a little crazy but I was looking at a setup today that might work with my MacStudio via Thunderbold and external eGPU adapter with R9 270/x.
The MacStudio, as well as MacOs recognize this adapter and probably also the graphics card, but MacOs itself cannot use it directly. Of course you could try to forward the whole thing to Qemu.
An external power supply unit including R9 270/x would also be required.
The R9 270 is a PCIe graphics card? The direct use of PCIe is currently not possible and everything must be made accessible via a PCI bridge? I still haven't understood it exactly.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
It also depends on if you can isolate the adapter in your iommu tree. You have to pass through everything in a group otherwise it will not work. And I don't expect that a PCIe port behind some thunderbolt controller will work
Here's my iommu tree. you can clearly see that the R9 270x is in it's own iommu group ( group 9)
IOMMU Group 0:
00:00.0 Host bridge [0600]: Intel Corporation Comet Lake-S 6c Host Bridge/DRAM Controller [8086:9b53] (rev 05)
IOMMU Group 1:
00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe Controller (x16) [8086:1901] (rev 05)
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] [1002:67df] (rev ef)
01:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere HDMI Audio [Radeon RX 470/480 / 570/580/590] [1002:aaf0]
IOMMU Group 2:
00:12.0 Signal processing controller [1180]: Intel Corporation Comet Lake PCH Thermal Controller [8086:06f9]
IOMMU Group 3:
00:14.0 USB controller [0c03]: Intel Corporation Comet Lake USB 3.1 xHCI Host Controller [8086:06ed]
00:14.2 RAM memory [0500]: Intel Corporation Comet Lake PCH Shared SRAM [8086:06ef]
IOMMU Group 4:
00:16.0 Communication controller [0780]: Intel Corporation Comet Lake HECI Controller [8086:06e0]
IOMMU Group 5:
00:17.0 SATA controller [0106]: Intel Corporation Comet Lake SATA AHCI Controller [8086:06d2]
IOMMU Group 6:
00:1d.0 PCI bridge [0604]: Intel Corporation Device [8086:06b2] (rev f0)
IOMMU Group 7:
00:1d.3 PCI bridge [0604]: Intel Corporation Device [8086:06b3] (rev f0)
IOMMU Group 8:
00:1f.0 ISA bridge [0601]: Intel Corporation H470 Chipset LPC/eSPI Controller [8086:0684]
00:1f.3 Audio device [0403]: Intel Corporation Comet Lake PCH cAVS [8086:06c8]
00:1f.4 SMBus [0c05]: Intel Corporation Comet Lake PCH SMBus Controller [8086:06a3]
00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake PCH SPI Controller [8086:06a4]
IOMMU Group 9:
02:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Curacao XT / Trinidad XT [Radeon R7 370 / R9 270X/370X] [1002:6810]
02:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000 Series] [1002:aab0]
IOMMU Group 10:
03:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller [10ec:8168] (rev 15)
Grouping doesn't always make logical sense. My previous mainboard didn't create a separate group for the gfx card. If the ethernet adapter in group 10 was also in group 9 then I would have had to detached it from the host system as well.
One of the best tools for checking CPU usage on AmigaOS4 should be Tequila(source), because a few parts of it are based on my 20 years old "top" tool
Btw, how much overhead does the tool itself cause if it relies on quite big number of (soft) interrupts per second (default: docs say 5000, source says 999). How expensive are (soft) interrupts in AOS4? Maybe not quite as much as task switches (in case they don't need to save fpu state) - you were talking about how much speed up there is in filesystems if one avoids AOS3 style app task <-> filesystem task switches.
Also the version history in the readme says "Use Forbid() instead of Disable() when reading task lists" which is wrong/bug.
It also depends on if you can isolate the adapter in your iommu tree. You have to pass through everything in a group otherwise it will not work. And I don't expect that a PCIe port behind some thunderbolt controller will work
Thanks for the information, I probably wouldn't be able to set up such an elaborate setup.
Still, it's impressive that you've managed it. Thanks a lot
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
@geennaam Thanks for the details, that should help those who want to further experiment with it. No need to write a tutorial, somebody else could do that, now they should at least have the info needed for starting with it.
Quote:
When I connect my RX560 instead then QEMU fails to start with that error message described above. Apparently this has something to do with a bad reset of the RX card. Or at least that is what you said a year ago.
I don't remember that any more but this reminds me there are some quirks in Linux kernel for some cards that don't like to be reset where the card may need to be added and the Linux kernel recompiled but I don't remember more than that. Maybe it's an issue with the BIOS emulator in SmartFirmware not able to fully run the card's ROM or something so either avoid resetting the card after the host booted to keep it in the state the host's firmware put it (which may need tweaks in the host's kernel) or try using different emulated machine like amigaone which might have different BIOS emulator version. (I mean those who are interested can try, not specifically you if you don't want to experiment with it any more.)
If you have x-vga=on you might not need -device VGA as that would result in two VGA cards mapped to the VGA registers so maybe that's why you don't get picture in SmartFirmware? Just -vga none should be enough but I'm not sure. You also may not need es1378 as the on-board via-ac97 should work and probably the addr properties are unneeded as well. Quote:
Using bus=pci.0 makes sure that the card gets connected on the virtual AGP bus for the pegasos2.
I'm not sure that helps as that PCI bus wasn't tested too much so maybe it works better without specifying bus and have everything on the default PCI bus. I'm not sure that IRQs from two buses won't collide somehow, those on the single default bus should work now. Unless AmigaOS needs the GPU to be on the other bus for some reason.
This can be caused by the fact that the shared drawer and ubuntu itself are installed on an old mechanical HDD.
But if you don't copy anything to or from that disk then it should not affect the general speed of a GPU unless there's something happening in the background that accesses that disk or the USB somehow interferes with the gfx card. So I still don't see how this USB drive can have an effect on gfx card speed and finding that out could uncover some problem.
Also even if it's the same as with real machine, understanding what causes the 100% CPU might help avoding or improving that which might also help real machines with slow CPU but fast GPU. So debugging those things might bring some improvement.
@Maijestro First of all you'd need to run Linux on your Mac because vfio is only supported on Linux. (All the search results about macOS and vfio talk about running macOS as a VM on Linux and passing through a GPU to it so I don't know if macOS supports PCI pass through and QEMU can use that.) Then it may or may not work depending on how the bridge is handled through Thunderbolt if Linux recognises that at all, although if anything then Linux has the highest chance to work with such things but on Mac hardware it may be different. This is probably more for people who run Linux on a desktop machine and run QEMU on that. For people running QEMU on some other OS the virtio-gpu driver may be an easier way.
I need a "second screen" as access to the passtrough card. So when I click on the uninitialized vga window, I can take control of the mouse pointer in Amigaos4. So when I move my Linux mouse over that vga window then I can move the mouse in amigaos. As a consequence or needs to be full screen as well.
I also need it to enter the " /failsafe" io.
Otherwise I don't know how to return to the of prompt and switch from Linux to the pass-through environment once amigaos is booted
I vaguely remember that PCI bus 1 did cause issues. Therefore I use 0. But maybe you can skip that now with all improvements due to bboot.
It did not affect the speed of the GPU directly. It affected the speed of the cpu. And therefore the speed of resizing windows and scrolling. So the speed of the system in general. Once deactivated the system came alive.
But this is no different on a real system. The GPU performance is also there limited by the performance of the cpu.
geennaam wrote: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 would have loved to see it in action, but as I mentioned it is absolutely stunning and could be an alternative to real hardware which is unfortunately a bit expensive and not very available.
This is not to say that the x5000 is a bad machine, on the contrary it is a really good NG hardware for AmigaOs4.1 probably the best at the moment.
Setting it up is probably the biggest problem at the moment and is really only for power users. But you have shown that with the right components Qemu is able to use this hardware natively.
So I still hope for Hans' solution to use AmigaOs4.1 accelerated under Qemu with the help of Vitio 3d.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I need a "second screen" as access to the passtrough card. So when I click on the uninitialized vga window, I can take control of the mouse pointer in Amigaos4. So when I move my Linux mouse over that vga window then I can move the mouse in amigaos. As a consequence or needs to be full screen as well.
I remember something about that now (it's somewhere in the other thread this was discussed before but I forgot most of that by now). Also back then I said take something other than VGA because VGA has some legacy registers so only one VGA card can be in a machine without clashing and adding a -device VGA shadows the VGA registers of the passed through card. This may cause problems initialising it and getting picture on it from firmware so just to make sure to avoid that add some other card that does not have VGA such as bochs-display or sm501 or I think that's what secondary-vga in QEMU is for. Or just pass through a USB card too with a keyboard and mouse connected or those USB devices themselves with usb-host (but that then needs a separate keyboard and mouse for the guest). Quote:
I also need it to enter the " /failsafe" io.
If you get picture withot -device VGA on the passed through card then at least for output not but for keyboard and mouse maybe still needed. Quote:
I vaguely remember that PCI bus 1 did cause issues. Therefore I use 0. But maybe you can skip that now with all improvements due to bboot.
Maybe we tried that to avoid interrupts from other devices to clash but that should be resolved now but I'm not sure interrupts from different PCI buses won't interfere. Devices on the default pci.1 bus were now debugged and should be handled but I don't know what happens if two PCI buses drive the same interrupt inputs. So maybe better to just use the default bus unless there are problems with that.
It did not affect the speed of the GPU directly. It affected the speed of the cpu. And therefore the speed of resizing windows and scrolling. So the speed of the system in general. Once deactivated the system came alive.
But this is no different on a real system. The GPU performance is also there limited by the performance of the cpu.
Is there a way to measure that? If adding a USB drive slows down the CPU even if it's idle then there's some problem somewhere. Unless you use that device why should it take CPU cycles just to have it mounted? If there's some way to show or measure this CPU slow down with the usb-storage then maybe we could find out what causes the slow down by profiling that to show where it slows down.
Btw, how much overhead does the tool itself cause if it relies on quite big number of (soft) interrupts per second (default: docs say 5000, source says 999).
In the initial implementations of my "top" there was no overhead at all, except for calculating the time differences to the previous state, percentage calculations, sorting the tasks by CPU usage, etc. and the console output, which you can check in it's own output: The CPU usage of the "top" task and the CON: task used by it for stdout. The ExecSG task scheduler updates the CPU usage of the tasks on each task switch. But there were 2 problems with that: - You need access to internal ExecSG includes not available in the public SDKs (struct ETask). - It's not supported on all PowerPC CPUs, IIRC not on 60x and 4x0, but only the ones with the CPU feature (performance monitor?) used by the task scheduler for it. On the CPUs not supporting it the task usage times in struct ETask are always 0.
In later versions of "top" I switched to using timer interrupts similar to what Tequila does. Except on very slow CPUs like the 60[34](e) used on the classic Amiga Blizzard/CyberStormPPC the overhead of the tool itself should be less than 1% (excluding the console output).
Quote:
Also the version history in the readme says "Use Forbid() instead of Disable() when reading task lists" which is wrong/bug.
Also the version history in the readme says "Use Forbid() instead of Disable() when reading task lists" which is wrong/bug.
No.
Task lists can change during interrupt. For example a Signal() in interrupt (for example a replied io request, like timer) can move a task from taskwait list to taskready list.
Task lists can change during interrupt. For example a Signal() in interrupt (for example a replied io request, like timer) can move a task from taskwait list to taskready list.
Maybe in some other exec implementations like the ones of AmigaOS <= 3.9, pOS, AROS or MorphOS.
Some versions of ExecSG used empty lists in SysBase->TaskReady and TaskWait and maybe even NULL in ThisTask, but unfortunately it was added again because some obsolete and unimportant software stopped working. IMHO there are way too much such workarounds for ancient software in ExecSG, which for example make the multi core support much more complicated than required. For example the DSI exception handler doesn't check if emulated m68k software accesses 0x4 (returning a (fake) SysBase is required) but even returns a SysBase pointer for PPC native software (not required and IMHO should fail/return NULL).
I just tried a little test in (maybe old) AOS4 for WinUAE. While in Forbid() state It counts 10000 times the number of nodes in sysbase->taskready (it is consistent with what is shown by ranger or scout). Nothing else. Then it sleeps a bit and repeats (until ctrl-c pressed). Most of the time the 10000 results are the same. Every once and then they are not!
I am not sure if you have already rebuilt your Qemu test system with r9 270, but I have a request if you are still using it could you maybe check if there are also SDL1 problems under your system?
A good test for this would be http://capehill.kapsi.fi/misc/BlitTest.lha unfortunately this information comes too late and I would have asked you earlier than you just tested the system.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
The system is transformed back to a windows PC. And I am not at home right now. So I will not be able to test. Maybe next week. Unless I am banned from this site just like from Discord #amigans .
I haven't been following the discussion. What is wrong with sdl1? Something 16bit screenmode related?
The passtrough system is using 32bit screenmodes and aeon radeonhd drivers.
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
. 