Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
26 user(s) are online (17 user(s) are browsing Forums)

Members: 0
Guests: 26

more...

Support us!

Headlines

Forum Index


Board index » All Posts (balaton)




Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@HansQuote:
I've also said repeatedly that any developer who wants to use the virtio.library should ask Matthew at A-EON for the developer files. Matthew is very busy with other projects (e.g., the A600GS), so if nobody asks, he's unlikely to think about it. If you have trouble getting a reply, then reach out to me via email. If you don't ask, then you won't receive.

How can I contact Matthew? I could not find an email address but heard he is hard to reach but I could give it a try if I knew where to write.

(This forum seems to be slow from here this year. Is there a problem or change with hosting it?)

Go to top


Re: A1222 support in the SDK and problems
Quite a regular
Quite a regular


@sailor
According to gcc docs aligned attribute is for structs so maybe you could try putting your vars in a struct? Something like
struct vars {
  
double T1,
  
double T2
__attribute__ ((aligned (8)));
struct vars globals;
...
globals.T1 1.0;

or the doc also mentions it might work for typedef so you can try
typedef double spe_double __attribute__ ((aligned (8)));
spe_double T1;


(Quick English lesson for blondes: It works -> it does work -> it does not work -> it doesn't work. "Not works" does not work in English. )

Go to top


Re: GCC disabling the instructions reordering ?
Quite a regular
Quite a regular


@thellier
Quote:
(I am very pleased when my C is exactly like ASM )

Why don't you just use inline asm for these then? Other idea may be compiling the file with -O0, maybe there's a way to switch that off for that function or file.

Go to top


Re: A1200NG motherboard appears at AmigaKit
Quite a regular
Quite a regular


Quote:
trixie wrote:@ferrels

Quote:
It's a backplane board for an R Pi 3 that fits into an A1200 case.

Isn't RPi3 a bit long in the tooth? I'd expect an RPi5 instead.


It's not an RPi but some Allwinner H618 board, probably this Orange Pi Zero 3.

Go to top


Re: gcc autovectorization feature - Altivec
Quite a regular
Quite a regular


I don't know the answer but I noticed in your result tables that the Avg/Min/Max times are about half for Copy with AltiVec, yet the Best Rate seems to be the same or slightly less. This seems inconsistent but I don't know what these numbers really mean.

Go to top


Re: Can a Power PC-based Amiga emulate a Power PC Macintosh?
Quite a regular
Quite a regular


@tlosm

I think e6500 is based on e5500 which comes from e500 and thus BookE too.

Running BookE code on BookS with KVM is known not to work. What might work is running BookS on BookS but then best results would be with same CPU so running G4 or G3 code on G4 host could work (using 64 bit host for 32 bit code is also problematic so anything newer than G4 might not run G4 code correctly,in particular different cache line size with dcbz and similar operations might cause problem).

Running BookE code on BookE host might work too but also untested so maybe does not work any more.

KVM is in the Linux kernel so any bugs should be debugged there not in QEMU most of the time.

It might be possible to run KVM on top of emulated PPC CPU in QEMU and experiment with that to find and fix bugs but it's very slow so nobody would want to do that so this should be tested and debugged by somebody with real PPC host and interest to run it.

Go to top


Re: Can a Power PC-based Amiga emulate a Power PC Macintosh?
Quite a regular
Quite a regular


@Hypex
Quote:
In your video there are a few crashes on boot. Surprised it keeps going Thought a kernel crashing on boot would end up in a kernel panic.

Depends on what's crashing. I think on pegasos2 Linux kernel has an error about some network related things which may also happen on real machine because the network driver uses some function it should not be using so the kernel warns about that. But it should not matter as the on board network card is not emulated anyway so it's not used.

Quote:
So I managed to get it booting and crashing in firmware with INT errors and some x86 crash. Was confusing as it looked like x86 code crashing inside emulation which should have segfaulted QEMU. But I tried your line and got further. And got into GRUB.

All of the AmigaNG machines have a problem with the BIOS emulator in their firmware which crashes on the default QEMU VGA ROM as it is compiled for i386 (because gcc does not support older x86) but the BIOS emulator can only run 16 bit x86 code. This is only a problem that you won't get firmware output on VGA but you could still boot by blindly typing the boot command or you can redirect firmware to serial by typing
" /failsafe" io

note the space after first quote, it's needed! Or disable default vga with -vga none and when adding a VGA device disable its ROM with ,romfile="" propery then you would not get that crash. Or you can use a real mode VGA BIOS compatible with the VGA device you are using via the romfile property. All this is noted on my qmiga.codeberg.page pages.

Quote:
It seems to boot but was taking so long I gave up.]/quote]
What are you running this on? Maybe the CD emulation can be slow but should be faster when installed on a disk image.

[quote]Last night I also tried it on my X1000 but couldn't get it to work. I used my X1Boot editor to make it easier on my self. At first I added a new boot entry with a standard 5.15 kernel and ramdish using the boot args. But it couldn't find root device and dropped to initramfs.

Does this kernel have driver for the IDE controller or whatever the disk with the root file system is on? Or does it load that from the initrd in which case does the initrd contain the right driver?

Go to top


Re: A1222+ memory interleaving
Quite a regular
Quite a regular


@sailor
Did you ever get the U-Boot sources for A1222+? Where can I get the sources of this U-Boot version?

Go to top


Re: Can a Power PC-based Amiga emulate a Power PC Macintosh?
Quite a regular
Quite a regular


By PowerPC based Amiga do you mean an AmigaNG machine or classic with PPC card? On an AmigaNG you could install Linux on it and run MacOnLinux. I don't think MacOnLinux can be ported to AmigaOS as it uses KVM which is a Linux kernel feature. It might be a challenge to find a PPC distro that still supports those machines though and still has MOL so maybe it would need to be an older distro which again might be hard to find now.

Go to top


Re: qemu 200% host CPU usage at idle?
Quite a regular
Quite a regular


I think performance counters of PPC CPUs aren't emulated with TCG and it's proabably not easy to implement as it runs JIT compiled code so it does not know how many guest instructions it corresponds to which the performance counters should count. A sampling profiler that does a backtrace periodically should work but tools that rely on performance counters won't work. I think this was discussed before.

QEMU has one thread per vcpu and a main thread. If the vcpu always runs code it will be busy. If it also does some IO like accessing emulated hardware registers then the main thread will also have to run. This may explain why waiting for IO may lower the vcpu usage as then the vcpu may sleep instead of running the idle loop.

It looks like this may also be an issue on real machine which would use more power and keep the system run hotter instead of letting the CPU sleep when idle so maybe it should be fixed for the real machine too independent of QEMU. (Unless it does use something that works on real machine but not emulated by QEMU.)

Go to top


Re: What the fastest possible x64 emulation way of OS4 today ?
Quite a regular
Quite a regular


@Redlion
AmigaOS version numbers and updates are confusing. There was original 4.1 then up to 6 updates to that then came 4.1FE (Final Edition) that contained all previous updates but then 4.1FE also had update 1 and 2. So it may be trying to install 4.1FE Update 1 and then 2 if your CD is the latest 4.1FE version. I don't think there was a release after 4.1FE but I could be wrong. I can't comment on errors during the update but it may be due to the lack of nvram emulation. If NVGetVar command from shell crashes you may need to replace it with some script that does nothing together with NVSetVar to avoid the errors or replace the nvram.resource.kmod in Kickstart with the Pegasos2 version (which can be found in the Updates) that does not try to access nvram. Or maybe just check what the update script does after it tries to access nvram and finish those steps by hand.

Sound works on amigaone and pegasos2 by default but the on-board sound of sam460ex is not emulated so for that machine you need to add a sound card with -device ES1370 which works with the SoundBlaster128 driver (then you may need to set it up in AHI prefs; there's some quirk in that pref that some uints need to be assigned to audio.device while some others to the SoundBlaster128 driver to get mixing working so more than one app can use sound at the same time but I don't remember which unit needs what; I think you'd leave those which are already use audio.device unchanged and change only those that are set to none or SM502 or similar to the SoundBlaster128 driver).

The sam460ex firmware has a bug that it does not boot with a USB drive attached so you should remove the "-usb -device usb-ehci,id=ehci -device usb-storage,bus=ehci.0,drive=usbdisk" options and only leave the "-drive if=none,id=usbdisk,format=raw,file=amigahd.img" option that defies the drive. Then after booting enter QEMU monitor with Ctrl+Alt+2 and issue "device_add usb-storage,drive=usbdisk" command which should plug the USB device that should then appear in AmigaOS (you can change back to the virtual machine with Ctrl+Alt+1).

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@nikitas
I don't see anything extraordinary in the log (but I also don't really know what to look for). It seems using legacy interrupts may disable mapping of BARs so it may use slower I/O to access those but that still does not explain the slow speed you got also when others already manged to get better results.

Did you try other things that was mentioned above such as not using taskset and remove cpu isolation and irq pinning (or at least allocate 3 CPU cores to QEMU)? Or the tests Georg has described both with x11perf and in the last post above assigning the card but not loading the driver and see at which point it becomes slow (just to locate which component does something that could make is slow).

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@Hans
The QEMU vfio device should do all that managing interrupts, from the guest it should appear as a normal PCI interrupt. There could be problems however if there is a problem somewhere passing through the interrupts. But I think if other PCI interrupts work, the vfio-pci device uses the same way so it should work too on the PCI side of it. I don't know about the vfio side. We're also passing a PCIe card as PCI to the guest so it may be an unusual config that's not well tested. As long as the guest does not try to access PCIe parts it might work though. There are some traces in QEMU's vfio that could be enabled, look in qemu/hw/vfio/trace-events. You can enable all of them with -trace enable="vfio*" but that might generate a lot of logs. Some logs might also be in the Linux kernel logs as vfio is handled there. Maybe there are some clues that could be get from those?

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@Hans
Maybe the HD card could work if MicroDelay didn't have a problem with that card. This might mean these cards are slow for different reasons. It's also possible that problem with HD card is not actually in MicroDelay but could it be that something is disabling multitasking so the test runs slower even though the delay would return in time? What could do that with only the HD card but not RX card and how could that be confirmed? Maybe snoopy can log calls to Disable/Forbid and see if there are more of these with the HD card than RX card?

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@nikitas
Here's some more motivation on what we might be able to achieve:
Resized Image


While QEMU uses one thread for vcpu it is multithreaded and has another thread for other tasks and maybe also an IO thread. So confining this to a single CPU core may not be a good idea. What if you drop all the tweaks of isolating CPU cores using taskset and setting irq affinity and just run QEMU normally? The host OS should be able to schedule the threads on its own.

Using other cards on the host should not interfere as long as they are in different vfio groups. Did you check vfio groups and established that the graphics card you're passing through is in its own group (with its sound function) and you pass all devices in that group? Also re-reading @geennaam's experiment in the long thread he used multifunction=on for the graphics function to create it as multifunction device as the sound part is at the same ID and another function of the card. I don't think that matters but have no better idea now.

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@Hans
Quote:
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.

Most of the people who do this want to play games in a VM that run on Windows while they want to run Linux. So they want to have the most performance and use KVM and vfio. This may mean that using it with TCG is not tested that much and with PPC at all but that does not mean it should not work. Of course we're on uncharted territory, not many people run AmigaOS on QEMU and even less tried vfio GPU pass through so it's not something that was tested and known to work. Some people tried it before for MacOS but gave up because there the firmware is needed to run the FCode ROM of the Mac graphics card (or a suitable ROM for a PC card) for MacOS to even recognise the card but QEMU's OpenBIOS can't run FCode ROMs and real Mac ROMs don't run with QEMU. (I had patches to fix both of these but they aren't upstream so one can only experiment with it with applying patches from different places so only a few people even tried. Somebody once managed to get a Rage128Pro working but don't know if it was usable.)

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@nikitas
Only remove from the QEMU command. It was said that if the guest has a USB disk as with the ufat shared folder then it ran slower with vfio for some reason. I don't know if @geennaam ever talked about a network card. It does (or should) not matter what you have on the host, the theory is that maybe having other PCI devices in the guest like USB or network card may interfere with interrupts from the graphics card. Now they are on different bus and we had several patches to fix this but who knows. This was with an RadeonHD card and used pci.1 so it's different than what you've tried but we have not better idea at the moment. So remove all -device usb-* and -device rtl8139 from QEMU command line and see if that changes anything.

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@Hans
Nikitas did not have a USB vfat device in the commands but may try removing the network (but I think also tried that and it didn't help). On pegasos2 all these may share the same interrupt so maybe there's still an issue with these after all the patches and level sensitive setting in BBoot? Anyway trying to reproduce with Linux could avoid all these and check if the problem is only with how AmigaOS does things or independent of that.

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@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.

Go to top


Re: Qemu + VFIO GPU RadeonRX 550 + AmigaOS4 extremely slow
Quite a regular
Quite a regular


@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.

Go to top



TopTop
(1) 2 3 4 ... 33 »




Powered by XOOPS 2.0 © 2001-2024 The XOOPS Project