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