if so can you send me the AC97 configuration preferences files because I don't know how to edit them by hand and I don't even know where they are.
Also tried the DVI to HDMI cable same result the audio is not heard the same with the jack
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
Ok, here such a video can be seen speed has been achieved. I must say that the audio is not good does not feel and it is absurd. However I am satisfied. I thank everyone for the numerous advice you have given me. But honestly now stops everything. I got tired of doing absurd tests for audio while it should work without problems.
After all, I am 56 years old is I want to spend my time to have fun a little with the pc I have all the backups, it is I can go back to it.
But humbly my knowledge is limited with Linux Install Arch is to make VFIO-PCI it was easier than configuring the audio.
That irony
@Balaton Thank you
@Joerg Thank you
@smarkusg You are not a bad person but you should share more, so my most sincere wishes.
Notes: I would also spend 100 euros to have drivers written by those who know Amigaos.
But basically friends the PCI Passhrough worked.
@Balaton thanks again. Regardless of everything, it is from the 3.0 version of Qemu with an i5 2400 that I followed your emulation.
I like to share the steps that I make the mistakes and solutions when I find them. Well that's all
I used a cell phone that is about 10 years old so the focus is not perfect, it flickers, I use it on a tripod
Ah the video so you can see the speed of emulation
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
@white You don't need to install any via-ac97 driver as it comes with AmigaOS 4.1 FE so you should already have it. Maybe the problem is not on the emulated system but on your host. Does audio work on your host with other apps and you can hear sound from host OS? Is QEMU compiled with the appropriate audio backend and using that? You can try qemu-system-ppc -audiodev help to list available audio backends.
I have demonstrated that GPU passthrough is possible. Now with AmigaONE emulation it gives me AC97 in the "mixer" instead with the real GPU it gives me VIA686B which is still AC97 but probably it is not up to me to correct this error. And probably not even to you.
Anyway I installed Arch with grub on a 500gb SSD disk So not in dual-boot And there it is ready to be reused.
I removed the Radeon and put Nvidia back on the other slot when I try again I will only have to change the addresses in IOMMU.
Now I will stop here.
Clearly more people are needed to do GPU passthrough.
But as long as everyone does not say anything to the others. It is a project that is not for me.
You are a person who in addition to having programmed qemu for AmigaOS you share it, other people do not do it and this is not good for projects like this. Other people people should imagine that if you programmed qemu to emulate AmigaOS and you would not have shared today no one could do this emulation just think about it. It does not take much.
DOCET ( Ancient Latin ) Aaron Swartz
The summary is this.
@Balaton thanks again for your work your sharing of the project and your advice.
@Joerg gave me precious advice as I said above
Oh I forgot @Maijestro He shared the discovery of the "silicon" driver and this is also a shared piece
I will come back to it anyway but now a break I spent a week reading asking and doing tests
I see "Black Mirror season 7" I'm curious to see the sequel of USS Callister
Edited by white on 2025/4/17 14:13:38
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
currently the only audio that works on ARCH is Starship Matisse HD Audio Controller I should probably redirect the audio to that device in qemu
list:
[white@Amiga Scaricati]$ ./test-iommu.sh IOMMU Group 0: 00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Root Complex [1022:1480] IOMMU Group 1: 00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 10: 00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 11: 00:08.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484] IOMMU Group 12: 00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller [1022:790b] (rev 61) 00:14.3 ISA bridge [0601]: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge [1022:790e] (rev 51) IOMMU Group 13: 00:18.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 0 [1022:1440] 00:18.1 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 1 [1022:1441] 00:18.2 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 2 [1022:1442] 00:18.3 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 3 [1022:1443] 00:18.4 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 4 [1022:1444] 00:18.5 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 5 [1022:1445] 00:18.6 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 6 [1022:1446] 00:18.7 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Matisse/Vermeer Data Fabric: Device 18h; Function 7 [1022:1447] IOMMU Group 14: 01:00.0 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] 500 Series Chipset USB 3.1 XHCI Controller [1022:43ee] 01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 500 Series Chipset SATA Controller [1022:43eb] 01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 500 Series Chipset Switch Upstream Port [1022:43e9] 02:00.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:43ea] 02:08.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:43ea] 02:09.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Device [1022:43ea] 03:00.0 VGA compatible controller [0300]: NVIDIA Corporation AD107 [GeForce RTX 4060] [10de:2882] (rev a1) 03:00.1 Audio device [0403]: NVIDIA Corporation AD107 High Definition Audio Controller [10de:22be] (rev a1) 05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller [10ec:8125] (rev 04) IOMMU Group 15: 06:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti XT [Radeon HD 7970/8970 OEM / R9 280X] [1002:6798] 06:00.1 Audio device [0403]: Advanced Micro Devices, Inc. [AMD/ATI] Tahiti HDMI Audio [Radeon HD 7870 XT / 7950/7970] [1002:aaa0] IOMMU Group 16: 07:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function [1022:148a] IOMMU Group 17: 08:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP [1022:1485] IOMMU Group 18: 08:00.1 Encryption controller [1080]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP [1022:1486] IOMMU Group 19: 08:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller [1022:149c] IOMMU Group 2: 00:01.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] IOMMU Group 20: 08:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487] IOMMU Group 3: 00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 4: 00:03.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 5: 00:03.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge [1022:1483] IOMMU Group 6: 00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 7: 00:05.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 8: 00:07.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge [1022:1482] IOMMU Group 9: 00:07.1 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] [1022:1484] [white@Amiga Scaricati]$
Maybe I should add this to the blacklist too ?
IOMMU Group 20: 08:00.4 Audio device [0403]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller [1022:1487]
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
The only audio available on Arch is this one in the red square. I should probably use this device for audio ? It's the only one currently active with Arch
The HDMI / DisplayPort AD107 is the one from the Nvidia GPU
Edited by white on 2025/4/18 8:41:24 Edited by white on 2025/4/18 8:44:06
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
@white It's hard to help you if you don't follow advice. I've asked before:
- Does sound work with other apps on the host? - What does qemu-system-ppc -audiodev help return?
Instead you've posted a lot of other info but still no answer for the original questions. So I have no idea what you're doing and cannot help much with it but hope you can figure it out.
Sorry, I didn't read the command line you suggested I was busy with the configuration and modifications to make AmigaONE work
[white@Amiga ~]$ qemu-system-ppc -audiodev help return Available audio drivers: none alsa jack oss pa pipewire sdl spice wav
---------
Yes applications like Youtube and everything else work with sounds etc. on Arch
with: Starship/Matisse HD Audio Controller audio output
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
@white OK so you have all audio backends available, unfortunately I don't know what your Arch Linux host uses. Most distros use pa, newer ones may use pipewire. I don't know how those work and what settings they may need. If other apps work then QEMU should work with the same setting. This works for me:
I had already tried yesterday unfortunately it doesn't work and yet Even after installing ( Enhancer ) you can see the "GREEN" volumes that do the test but no sound is played. Patience
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
@white Did you try as I wrote above with just the install CD and not with the installed system? This is to find out if any changes made on the installed system could broke something. If it does not work with just the install CD then problem is probably not on AmigaOS side but on the host.
Maybe I'll get the same card as @smarkusg It was available when I bought the R9 580x I thought it was faster
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
@white GfXBench need to be analyzed carefull : you may have bigger scores, but for example by raw CPU writepixelarray/readpixelarray, or by copy mem routines, while, at the same time, 3d scores can be faster. I.e. not necessary "overall score" shows that 3d is worse or better, need to check every function. In your case it's indeed those read/write to/from VRAM functions are good enough with silicon, and dead death with 280x
silicon:
Operation MiB/s
Copy to VRAM 4,549.62 Write Pixel Array 2,277.99 Copy from VRAM 1,913.38 Read Pixel Array 2,601.16
vs r9: Operation MiB/s Copy to VRAM 75.60 Write Pixel Array 15.35 Copy from VRAM 11.28 Read Pixel Array 5.09
See it not just slow, but dead strange slow. Thousand times. While chunk operations with R9 a bit better (when you copy big enough blocks like 512x512 and bigger).
We meet with same issues when Hans tried to optimize bridges settings of controller to have at least something sane, but still, we didn't reach even half of what real radeon9250 gives.
Same issue happens (if i remember correctly) with Virtuo driver too: silicon 502 gives much better results in those copy functions.
Maybe it's something we hit all the time : bandwidth issue of unknown cause. We meet with it when lighting in use in 3d games, when just many textures on screen at time, we meet with them with WPA/RPA always (check any gfx bench results). At least that the impression i got for now.
Thanks, I would like to buy another card but at this point I don't know what to choose. I would need some advice on the purchase. Because they don't cost much but I can't collect GPUs
Which one do you recommend ?
@Hans
What do you also recommend for vfio ?
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
With SM501/502 QEmu emulation it's not VRAM (there is none), but DRAM (frame buffer of the emulation) access speeds, and of course they are much faster.
Quote:
vs r9: Operation MiB/s Copy to VRAM 75.60 Write Pixel Array 15.35 Copy from VRAM 11.28 Read Pixel Array 5.09
With SM501/502 QEmu emulation it's not VRAM (there is none), but DRAM (frame buffer of the emulation) access speeds, and of course they are much faster
Of course, just numbers are so high, while when we use virtio driver, or real radeons drivers, thigs much slower in this regards.
I haven't tried the Radeon r9 580x GPU with qemu Pegasos2 yet but I imagine it's the same with audio.
Anyway at least I understood the layout of the GPUs only one way ACS works for IOMMU the cards must be in specific slots. If I reverse them ACS fails to work
What do you see when you close your eyes ? I see light, lots of light I see you, dad And I see mommy too And I see me and we are together And we play forever.
Of course, just numbers are so high, while when we use virtio driver, or real radeons drivers, thigs much slower in this regards.
It's the same on any other OS as well, accessing VRAM with the CPU simply is very slow, and there is next to nothing (except for using 128 bit AltiVec, or at least 64 bit FPU instead of 32 bit integer accesses) you can do to to make it faster. Other gfx systems, for example X11, avoid most VRAM accesses using a shadow frame buffer in DRAM. AmigaOS doesn't support anything like that. Nearly all other OSes use GPU based DMA (GART) instead of the CPU to copy data between VRAM and DRAM, which is much faster.
On some real AmigaNG systems, like the Sam4x0 and X5000 (maybe the X1000 and A1222 as well, not sure), the embedded CPU DMA engine can be used for copies between VRAM and DRAM, which is faster, but not as fast as GPU based DMA transfers, than CPU copies. AFAIK on QEmu that's not used, any maybe even can't be. QEmu probably doesn't even emulate 128 bit AltiVec assesses using 128 bit host CPU accesses, but uses slower 64 or even only 32 bit ones instead.
@Georg posted some X11 results with ShadowFB disabled, converted from MB/s to MiB/s by Hans:
read ( 20.4 MiB/sec)
write( 306.1 MiB/sec)
Faster than geennaam's VFIO results were, but by far not "Thousand times." as you wrote, and compared to @smarkusg's results
Copy to VRAM (=write) 188.06
Copy from VRAM (=read) 26.23
not a very big difference.
Edited by joerg on 2025/4/19 20:31:49 Edited by joerg on 2025/4/19 20:40:28
With SM501/502 QEmu emulation it's not VRAM (there is none), but DRAM (frame buffer of the emulation) access speeds, and of course they are much faster.
Sure but the question is what do you use the numbers for. If the benchmark combines the score based on actual usage statistics having faster VRAM copy may mean better overall experience. If it does not meet experience then maybe the weighting in the overall score is wrong or not matching the usage. It's hard to make one number describe all usages so likely it's better to compare individual results.
However there are some points I don't understand. First, SM502 seems to be fast but virtio-gpu slow even though both use emulated device. Or does virtio-gpu actually map VRAM? If not then maybe 3D drivers do something that's very inefficient and create a bottleneck where SM502 does not have that.
Second, some results with vfio-pci seems to be fast (geennaam, smarkusg) while others slower (white, nikitas and others). What does that depend on? Motherboard, GPU, BIOS, what else? This is not explained by slow VRAM access as they use same AmigaOS drivers and QEMU so inefficiencies in those would be the same, only hardware is different so understanding that may help finding out where the slowness comes from.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
