@joerg
Quote:
As said before env variables aren't the most convenient way for QEMU. Adding a text config to kickstart.zip is much easier. These may be preffered on real machine but for QEMU it's not easily available or easy to set.

I did some more benchmarking to get more understanding of the problem instead of trying to base solutions on theories. I've posted the results on the qemu-ppc mailing list Looks like dcbz isn't the biggest issue but AltiVec is. So for now you may get better results with -cpu g3 or some other G3 variant that don't use AltiVec. For accessing RAM AltiVec sometimes helps a little but for VRAM access it does not. For this dcbz isn't the biggest problem (for RAM access it's measureable though). I still don't know what AltiVec ops to check, I can get a disassembly and look at what opcodes are used but I don't really want to do that. Maybe if a smaller test case could be written with just one loop or even an assembly one that may be easier to check and optimise. By a quick look these don't use many AltiVec instructions though, most are different loads and I've seen vperm and nothing else so just checking how those are translated by QEMU might be enough but I let somebody else try to do that.

@joerg
What does IGNOREMASK=Yes do?

@NinjaCyborg
With passthrough or on real machine? Some are passive cooled, most have a fan: link to examples I happened to find one cheap and close which seems to be an HP OEM card and it has a fan.

@kishigo
I don't know about X5000 but on other systems it's setenv os4_commandline serial then saveenv. If you have a U-Boot menu maybe it can be set from that as well. stdout sets the output of U-Boot not the AmigaOS kernel.

@themamboman
https://www.amigans.net/modules/newbb/ ... id=153755#forumpost153755
I also have this link on my page:
https://www.amigaos.net/content/4/where-buy
which I hope is still valid. The one US distributor listed there seems to have only pegasos2 and sam460 versions. Pegasos2 version should also work with some more tweaking but same performance as amigaone version. The emulation of amigaone and pegasos2 is almost the same in QEMU so only difference is the north bridge and whatever differs in AmigaOS.

@Hans
Quote:
I think it would not be workable in practice. Problem with nvram.resource is that users would need access to pegasos2 version too to get it which they probably don't have if they have another version and also using it means the newly added NVRAM support in amigaone would not work with that so it's better to have a separate config file for gfx drivers.

Quote:
In case you have access to the source of nvram.resource used on pegasos2 I guess you can find it in there. The API did not change for other modules on pegasos2 as it is just emulating an NVRAM which gets data from a text file instead of the firmware but the way to get a text file from the kicklist should be there.

Quote:
On real hardware sure but I meant for QEMU with vfio-pci. I don't even know if it would work currently so maybe it's not top priority over other possible improvements. But adding a config for it helps testing it in any case.

Quote:

They say optimists are oblivious pessimists But it does look like from my perspective that your work is just going into a black hole. You had working 2D virtio-gpu driver a year ago and we still have nothing of that (maybe you even have 3D now which we still can't try). Neither the fixed pegasos2 kernel was released which I could at least work around but vfio-pci passthrough would be easier with a fixed kernel. So that does not make me too optimistic about it unless you can release a test driver yourself.

@Hans
The way that the pegasos2 version of nvram.resource uses also works on amigaone and sam460ex as I've tried that before to set env vars using the nvram.resource module from pegasos2 before NVRAM emulation was added to amigaone. So your drivers could do the same to check a config text file added to Kicklayout. This may not be standard but at least already exists in some versions so you can promote it to a standard hack status.

But for dcbz you can't just add a conditional around it as that may make it slower so you may need to patch it on load to something else based on the CPU or config. For most CPUs used in latest AmigaNG machines dcba might be better or according to the Apple sources Joerg found maybe even nop so if you can test that having dcbz there helps at all maybe it's simpler to just remove it completely.

I don't know how much GART matters but if we also have an interrupt issue fixing that first may be needed.

Problem is with any modifications you make is that we'll never get them. I can't even get an answer for the simple question about releasing virtio.library interface. So I'm still interested in improving dcbz in QEMU which is beneficial of existing old code, also those that you cannot change because they are in some other closed source stuff like MacOS or third party apps. And if dcbz is still used for clearing memory because it helps on real machine QEMU has to handle that anyway. Adding config options for these in the driver may help to test these ways also on real machines so for that it's still useful.

I have tried just DVI connected and I get no picture from that even with Linux. The U-Boot screen outputs to both VGA and DVI outputs and Linux detects monitor connected to either port but only get picture if only VGA is connected. With only DVI I get no picture in Linux and with both DVI and VGA connected I get out of range signal on VGA. With AmigaOS I get splash screen on VGA only then black screen and no output on DVI, although the EDID data is dumped on either port so it detects the display but seems to stop when reaching SetCDEnv on the install CD. I've tried editing the tool type in System/Devs/Monitors/Radeon to set INTERRUPT=No on the install CD but it does not seem to be loaded with the boot CD so I think that's ineffective. Maybe on installed system it's checked but I don't have an installation to test.

The card I'm trying is an ASUS EAX550 with PCI IDs:
Advanced Micro Devices, Inc. [AMD/ATI] RV370 [Radeon X300] [1002:5b60]
Subsystem: ASUSTeK Computer Inc. Device [1043:011e]

Anybody with such card and a real machine can confirm it should work with AmigaOS ATIRadeon.chip driver?

@white
It is possible to set up vfio to work with non-root user as well but I did not mention that in the docs to keep it simple and not confuse people more. Besides changing the access mode to allow a group to write to the appropriate vfio files (which is best done from an udev rule) you may also need to dump the ROM of the card and pass that with romfile to vfio-pci on QEMU command line as it may not be able to use the ROM of the card when not running as root. But you can't dump ROM with vfio-pci so you have to unbind vfio-pci driver first then dump the ROM then bind to vfio-pci again (or get the ROM before assigning to vfio-pci). I don't think you can manage to do this from any short description I could write so just try the -audio option I've written above in post #90 which should also fix the sound issue without changing anything from what already works.

@joerg
But results so far did not prove that faster CPUs should be better for using real cards with passthrough. At least I got the impression that the Gfx2DBench results were more dependent on something else than host CPU speed. But the thread where I've asked people to collect results went nowhere so I don't have data to compare.

I'm also not sure that number of registers plays the bigest role in emulation performance. We know that FPU, MMU emulation, exceptions and dcbz are all factors that if something hits any of these a lot it will get slow. If something hits multiple of them it may be even worse. Compared to that having to move data to/from registers is probably less of an issue given that modern CPUs are much faster and this should still work from cache so this may have less of an effect than the other issues. Trying to optimise those may help more. I've tried cleaning up exceptions before but it did not help that much. MMU is not easy to improve. For FPU there was a design that could be implemented but nobody tried it and I've also tried dcbz but again nobody cared about it enough so these aren't solved still. I guess dcbz would not be too difficult as it's just one small part that somebody could learn in a few weeks and make a patch but there weren't many people wanting to try that so far.

@white
When did you check my qmiga.codeberg.page the last time? Recently I added a page on VFIO passthrough. But it's not really possible to write a step by step guide because each distro is a bit different and every motherboard, BIOS and graphics card has its own quirks so it's likely that it would break somewhere then you will have to find out how to fix that on your system. For example nobody else got the sound problem you had so that's just something about your host Linux or QEMU config that others don't have so would be missing from a guide written by somebody who did not meet that problem.

Some more progress with this.

I've checked that "ATI Radeon RV370 X550" appears in ATIRadeon.chip so this might theoretically be supported and work.

I was getting errors in host's log saying that card refused to enter D3Hot state from D0 but then the guest said card is stuck in D3 state especially when trying to start QEMU the second time. This is solved by adding disable_idle_d3=true option to vfio-pci. Looks like this card does not like PCI power management and cannot be powered down. Now I can run QEMU multiple times as long as the AmigaOS driver does not touch the card. After it hangs in AmigaOS that it will hang the host on second try.

I was still getting out of range VGA output after an OS started and only U-Boot was displaying. Then connected an older monitor to VGA but got the same result. Then disconnected the DVI and that solved it, the VGA now is in range for the monitor. Then connected the VGA back to the newer monitor without connecting the DVI and then it works there too. So it seems having the DVI connected was also causing the VGA port to try larger resolution even when DVI did not display anything. Now with only VGA port connected I get output on VGA with Linux radeonfb (only console, did not try X) and can also run this multiple times without freezing the host.

Then tested AmigaOS again and while it loads and seems to find the card I don't get picture from it. The ATIRadeon.chip has no debug messages at all so it does not tell me anything but with the debug kernel I also don't see any errors so it seems the Radeon driver loads just does not work. I see the bootimage (fade in splash screen) then it goes black and stops loading. With loglevel=11 and debug kernel I still see logs from page_sweep at the black screen so it's not completely frozen but nothing else seems to progress. If I stop QEMU at that point the host still works but as soon as I start QEMU again the host freezes when the U-Boot tries to run the card's ROM or enables the card. Maybe the card is not reset correctly or the ROM is not meant to run more than once but I'm still interested to find out why it freezes the host. (Well, the ROM can run multiple times as I can boot Linux guest more than once and that goes through the card init in U-Boot but after it hung in AmigaOS it will hang the host when the card is next touched by U-Boot.)

My theory now is maybe I could reprocude the INTERRUPT issue (I'd have to make an install and try setting the tool type to test that) but could it be that the card raises an interrupt and AmigaOS tried to acknowledge it but it does not get to the card so it's stuck with the interrupt raised and that's why it stops? On the amigaone and pegasos2 the north bridge has some interrupt acknowledge addresses that the guest has to read to clear interrupt. In QEMU this is now reading the ISA pic where PCI interrupts are also routed but maybe the graphics card also needs some way to clear PCI interrupts? How is this supposed to work? What and where should poke to acknowledge and interrupt from the graphics card? I'm not sure how can I test this and what logs should I try to check for this to see what happens.

@kas1e
Quote:
We are discussing GPU pass through in this thread and people said before that maybe it would be faster with faster CPU but then all people who tried whatever CPUs they had got similar slow or even slower results that does not seem related to CPU speed to me. So while faster CPU is better for emulation this may not be the main reason for the GPU slowness we see or it's not proven what effect it might have. So until that's understood I would not say it matters for GPU performance as that's just an assumption without being confirmed.

@Maijestro
Does the e5500 support little endian? Newer POWER (BookS) CPUs have LE mode and can run ppc64le version of Linux which probably works better as the problem with newer drivers may be that they were not tested for big endian machines. Much the same problem as with newer web browser engines. AmigaOS is big endian but Linux has both versions and nowadays ppc64le is the only one still somewhat supported.

@joerg
Quote:
We can exclude hardware and U-Boot from that but not sure about kernel. The nvme.device may used its own routines while the graphics stack may use something from the kernel so I would not exclude that yet.

@joerg
Quote:
By what benchmark? You said before that benchmarks are useless so how do you know that Ryzen is faster than Intel for this? So far the only somewhat reliable measure seems to be some application benchmark like running Quake timedemo or different apps that use some functions which is a better measure than synthetic benchmarks.

@white
Quote:
Maybe because this script is not relevant to your problem. As I said before the sound issue is not related to vfio therefore also won't be fixed but anything vfio related. Joerg said that HDMI audio does not work in AmigaOS so the only other way left is using different audio backend for QEMU that does not connect to a sound server. Try -audio alsa,id=audio0,out.try-poll=off option. This is mentioned on the AOS problems page of my docs.

@white
No idea but there's a documentation link at kernel.org then look for Administration, kernel boot parameters or something like that, all of these are documented there. (In any case won't help sound problems.)

@white
I'm not trying to explain, it would take too long. In short, sudo means run as root user. The root user is normally allowed to do everything but maybe not always. Your Linux distro has security settings to only allow connections to your X session as the user who is logged in so other users cannot connect to the sound server. To solve it probably the simplest is to use the passed through audio function of the Radeon card (the -device vfio-pci,host=05:00.1 part in your command) then set in AmigaOS to use HDMI output and then it should go where the picture goes so on the TV or monitor where the Radeon is connected. At least assuming that HDMI output works on AmigaOS and also works with this setup which is untested. If that does not work you can try using different audio backends in QEMU but that's harder to explain.