QEMU GPU-PCIe AmigaONE

@white

I didn't write such obvious things that the amigaone installation CD must contain the Silicon Motion driver.
It must.
If you want you can install from the ES2 installer or do it manually (drivers alone)

I'm very sorry but I don't have the skills to write detailed guides/HOWTO and I can't give you everything step by step.


qemu-system-x86_64 = QEMU PC System emulator
Try to run a "second ubuntu x86_64 iso" on your installed Ubuntu, but to benefit from vfio-pci.
Same vfio-pci data as you run qemu-system-ppc. Preferably without the "kvm" option (Kernel-based Virtual Machine)
You will find examples of how to do this everywhere. I don't want to paste the exact command line for you because I have no way of checking it at the moment.

The steps are basically the same.
What I get written in the qemu window for the sound is this after many checks:
Once I try to save Prefs/AHI/AC97 stereo++ etc. etc.

couldn't open play stream: Non-existent file or directory
sndio: failed to open device
audio: Could not create a backend for voice `via-ac97.out'

once the RadeonHD.chip are activated in kicklayout
the sound disappears

using the original ones from AHI and not those from ES 2.2

@white
I have something like this and it works.




Still try this ubuntu via qemu X86_64 for peace of mind with GPU passthrough.
I can't think of anything else.

@white
Which audiodev backend are you using? What was the configure output for audio_drv_list? The errors don't make much sense as I don't think it should use sndio on Linux and I can't find the error before that that says "couldn't open play stream" in QEMU so no idea where that comes from but maybe it has something to do with you have to run QEMU as root for passthrough and maybe it can't connect to your sound server in that case? This may be different on every distro so I don't know what to do with that but may try using option. This is normally not recommended if you have a sound server and does not always work well but as a fall back it may work until you find out the issue.

I'm starting to think that my card only works with Composite 2D and with the (2.1 drivers) on Amistore.
here is my GfxBench:

https://hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS/Result/2937

My GPU:
Sapphire Radeon R9 280X TOXIC

here is the driver on Amistore with the description:



and my R9 Tahiti 280x card is listed

@Hans
are these the drivers that I have to use the 2.1 ?

I imagine that if they are still present on ( Amistore ) it means that they have not been discontinued.

Thanks,
it's a simple question to the author of the drivers I think it's right to receive support after purchase.


Here a discussion about this chip Radeon is not exactly the same but it is R9 580x :

https://www.amigans.net/modules/newbb/viewtopic.php?post_id=134499

@white

Quote:
I can't comment on specific graphics card models. In general, a Radeon R9 280x is a Southern Islands GPU, and that's supported by the RadeonHD.chip driver all the way up to v5.

I see no reason why you'd have to use specifically v2.1.

Hans

P.S., For 3D you need Warp3D Nova. Best get NovaBridge too for legacy 3D support (i.e., old MiniGl & Warp3D games).

@white
Have you perhaps checked what @Balaton wrote ?
You ask a lot of questions to which you get answers.
But there is also sometimes no feedback as to what you tested and what the result is

Thanks for your help

ps
- if you had checked "qemu-system-x86_64" you wouldn't have to reinstall AOS4. It would show that it is not a problem with the RadeonHD driver under AOS4.

@All
I'm sorry, but the suggestions provided by you and @Balaton do not work.
installing the drivers as you suggested the card is not recognized with Hardware acceleration for example Emotion does not work in YUV and is without acceleration.

The feedback is interesting the audio continues not to be heard.
And I can't blame anyone.

The only thing that I regret is that no one tries to help those who are trying to carry on with this emulation.

@smarkusg
Now I don't see dozens of people who are doing this emulation.
I only have 2 examples yours is that of @germann

I don't see other examples.
And so it is clear that you are trying to share what you have managed to do.
I have been using KMV for a long time I have also emulated FS-UAE with Amilator with a single card and other systems.

I don't want software or programs or licenses.

I just need to understand the steps you have done.
All the other answers are useless.

I'm sorry but it's like this.
I have always demonstrated that I have no problems sharing what I do and even more than what I do.

I need a .raw file without any license without updates but that starts since there are no tutorials.

Mine is a polite answer and is free of any offense towards anyone.
And only my answer to the answers try this way or try this other way.

At least a basis is needed, if this is not there, everyone can say what they want but it is unfounded.

I just can't figure out what it means do these steps:
1) example
2) example
3) example

etc. etc.

it doesn't seem difficult to me.

Other example Radeon RX:
https://amiga-ng.org/static.php?op=Polaris-X1000.html&npds=1

OR I said I want to get another GPU
Advice is welcome this is the only site to ask about AmigaNG

@balaton
Quote:

Btw, why not do some tests with AROS x86. If one downloads a live distribution like "AROS One 2.4" one can use it directly with



and does not need to install anything and with it's vesa driver it shows you the framebuffer address (sys:system/hardware/pcitool) and it comes with gcc so you could directly type in some benchmark that pokes and peeks directly in VRAM and run it.

You could then see the difference between emulated cpu (qemu default? smiliar to cpu emulation of PPC hardware?) and hardware virtualiziation/cpu emulation (start qemu with -enable-kvm).

And I guess the AROS vesa driver should work with passed through radeon gfx card? So you can then compare those results with AOS4 with same passed through radeon gfx card.

In case this kind of tests is more difficult/annoying in Linux guest and/or Linux host ...

@Georg
Quote:
I guess that could be done with a Linux guest as well but testing x86 guest may not bring much.

Quote:
I guess that could also be tested with trying to run a Windows guest with TCG if somebody already has one set up or a Linux live CD or anything but this won't give too much info on VRAM speed or PPC emulation. I'm quite sure the problem is not with VFIO as that's used for gaming setups but much more likely either something with PPC emulation (using optimisations that are not optimal on QEMU) or something unusual the AmigaOS gfx driver does and is not optimal on these machines.

Quote:
I don't want to make it work at all costs and just interested in if it's possible so I will do as much testing as I feel like and have time for so if others do tests and share results it may help, otherwise it may take a while for me to find it out alone.

Quote:
I think it would be easier to test with a Linux guest than with yet another OS that is not directly comparable to what AmigaOS does. I already have the benchmark compiled for Linux (I think I've posted it somewhere on the QEMU list a while back) and used that to test with qemu-ppc which was optimised for RAM but not VRAM. I could try the same with qemu-system-ppc but I had no time for that yet.

@white
We don't know why sound is broken on your machine so can't really help. You said it worked until tried to use passed through card. I said it may have to do with running QEMU as root so you could try removing passed through card and run it with -device sm501 first as normal user and confirm sound works then as root and see if you get the issue. If so it has nothing to do with the pass through card but with running as root. Then if that's the problem find out how your distro handles that. If that's not the problem I have no idea. I don't even have pass through set up so can't try and works for smarkusg with sound and he never had this problem so what do you expect? How could we know how to fix it?

I dug up the benchmark we got before that does what the Gfx2D benchmark does and did a quick test on current QEMU. This is just copying between two malloc regions, not to actual VRAM but it can test the emulation overhead.

Running with just CPU emulation with qemu-ppc (user emulation that runs a Linux executable complied for different arch) I've got:


Running same executable under qemu-system-ppc -m pegasos2 booted with Linux I've got:


So whatever tricks FromVRAM does can slow it down and I think that was dcbz.

Looking at the benchmark it looks like ToVRAM uses dcbt which does nothing on QEMU so no problem but FromVRAM does dcbz which is still a problem. Maybe it does not really need to zero the destination before overwriting it but could be that dcbz was supported on more CPUs so that's why that's used and not something else that may not be available everywhere. In any case I think dcbz is also the same issue why the Tricky test in RageMem is bad and it also affects MacOS so this should be solved for all.

If somebody wants to help fixing this start here:
https://lists.nongnu.org/archive/html/ ... ppc/2025-04/msg00297.html
I may come back to this one more year later as I have lot of other things I can do so don't wait for me to fix it, start contributing.

@balaton
Quote:Ideally it should use dcba instead like for example my newlib memcpy() and IExec->CopyMemQuick() implementations did on supported CPUs without AltiVec.
No idea if any of my old code is still in use in current newlib.library and/or ExecSG versions.

On CPUs with AltiVec the vector streaming instructions should be used instead.
As an alternative simply using 2 successively 128 bit AltiVec register writes to RAM, without any other CPU instruction between them, and without using the streaming instructions, works as well.

All 3 methods avoid the read cache line, modify cache line, copy back cache line cycle, which is used on 32 bit PPC CPUs for all smaller (32*8 bit char, 16*16 bit short, 8*32 bit int and 4*64 bit double) accesses to write a complete 32 byte cache line to RAM and just write the data to RAM, which is important on real PPC CPUs, but all 3 methods should work with QEmu without slowdown as well, unlike using dcbz.

dcbz has to be used as replacement for dcba on some CPUs which neither support dcba nor AltiVec, but it's additionally wrongly used for "security reasons" as dcba replacement even on CPUs which do support dcba.
Even if it may not be stated in the PPC user documentations dcba doesn't only allocate a cache line, which could be a possible security problem if old contents would still be in it, but does clear it to 0 as well, just like dcbz does. At least on all 32 bit PPC CPUs supported by AmigaOS. The only difference is that dcba is a no-op on cache inhibited memory like VRAM while dcbz causes an exception and is emulated by the kernel exception handler, which is of course very slow.

@joerg
According to QEMU dcba is available on embedded CPUs (440, e500, e5500) and G4 so only G3 and classic Amiga accelerators might need dcbz. But that also means that all old software will likely use dcbz so even if it's fixed in AmigaOS now (which then we will also need to get as an update eventually) it won't fix all problems with existing software, and the same problem also exists with MacOS running on QEMU. So the dcbz needs to be optimised in QEMU anyway for those.

I'm not sure about the exception you mention. I did the test on Linux guest, no AmigaOS so unless that would do the same this isn't the problem. Also target/ppc/mmu_common.c#L322 says it will do nothing so I'm not sure the guest would get an exception on QEMU. It's just the current implementation of the dcbz helper goes through probe_write or an even slower loop which is very inefficient. It might be faster just to translate dcbz to a loop writing cache line size zeros which my patch attempted and without being too much optimised it was a bit faster. Some of that inspired some optimisations that at least helped the user emulation case but also means my patch does not apply any more and I don't want to redo it. Somebody interested in this could do that, QEMU is open source and anybody could contribute, it's not something that only I could fix.

The benchmark is in the message I've sent to QEMU list linked above so anybody could also modify it to test VRAM on any guest OS they like and see if that's worse or same as accessing RAM (to verify how much of it is dcbz and how much is the overhead of smaller transfers). That's also not something that only I could do. That's why I'm sending these to here and to the QEMU list so if somebody wants to help this is open for experimenting and sharing ideas and even code with open source. I may do it eventually if have nothing better to do but it would be faster if more people helped.

@balaton
Quote:Benchmark tools like RageMem and GfxBench2D, with own implementations of such functions, are very rare exceptions, 99.99% of the AmigaOS software simply uses the C library bcopy()/memmove(), memcpy(), ... or kernel IUtility->MoveMem(), IExec->CopyMem[Quick](), ... or IGraphics->ReadPixelArray(), IGraphics->WritePixelArray(), ... functions instead of trying to implement more than 5 different versions of each of those functions for the various different PowerPC/POWER CPUs themselves.

Quote:Strange. At least Apple's G4 code uses dcba as well, not dcbz, and in a similar way than I did in my AmigaOS 4.x C library and kernel functions: https://git.saurik.com/apple/xnu.git/b ... k/ppc/commpage/bcopy_g4.s
(Main difference: My functions were 99% C code, with only some asm inline("dcba"), asm inline("dcbt"), etc., instructions, while Apple's slightly slower code is 100% assembler instead.)

Just make sure you use a suitable CPU for MacOS PPC emulation as well, and not some junk like the 7400 as you initially did for the Pegasos2 emulation