I couldn't figure out if the answer was for me I guess so.
I have the ryzen 5800x so it doesn't have the integrated graphics card like the 5600x for example.
In the bios in addition to AMD V-T support i also have this option i guess is for graphics card. pci sub-system settings if system has sr-iov capable pcie devices this option enable or disable single root io virtualization support.
But I wanted to know if you need a specific adapter etc. To be able to insert one of the graphics cards you mentioned into the second slot.
Thank you.
My 5600X does not have integrated graphics, so your setup will be very similar to mine. The main BIOS settings would be to make sure that SVM Mode is on as that turns on virtualization technology for Ryzen.
You have 2 PCIe x16 slots on that motherboard, so you would put your main gfx card in the long silver x16 slot, and the gfx card you want to use for passthrough in the second x16 slot.
Any PCIe card will fit, but from the ones that we have tested the 5450 and R9 270 are PCIe cards and will not need an adapter.
If you want to use older gfx cards such as Voodoo3 or 9250 then you will need an adapter as these are most likely PCI cards.
My setup is a Radeon RX 580 as main graphics card, and then the Radeon R9 270 in the second slot for passthrough.
My reply was for anyone who needed a summary really, but yeah it also had all the info you need.
Unfortunately I don't have intimate knowledge of your BIOS, nor the time at the moment (I'm working) to download the manual and read through it. Earlier in this thread (like, much earlier) there are instructions and links for how to isolate your 2nd GPU for pass-through and there are commands there that tell you how to display the IOMMU grouping, determine which driver the card is using and that in turn tells you if it has been isolated from the host OS for passthrough or not.
You can test all of this out if you have 2 GPUs. The 2nd does not need to be supported by AOS just for this purpose. Once you know that you can isolate your GPU by itself without needing to also isolate other devices because they are in the same IOMMU group, then you can consider whether to get a compatible card or not.
Unfortunately this stuff isn't simple. It was easy for me because this is how I used to run Windows and Linux around 3 years ago and I explicitly bought my motherboard for that purpose because I knew it had very good support for IOMMU grouping. It splits more or less all devices into their own group so I was able to passthrough GPU, network, USB, all individually. It was complicated to do however. Here I'm referring to Windows of course, not AOS.
If i were to do it again, and perhaps I needed a new motherboard and new GPU just to do this then TBH, I'd probably just buy a Sam460LE or X5000.
[edit] Looks like Derfs has told you what you need to know. For reference my CPU is a 3700X and my motherboard is a Gigabyte X570 Aorus Ultra. My main GPU is a Radeon 6700 of some sort (I forget) and my secondary is HD5450 as we know.
I don't really know or want to know PPC asm (it's sooo ugly), but after a bit of google'ing, maybe the "beqlr" tests r9, because the "." suffix causes the rlwinm to update condition registers while no such suffix used for "mr" instruction, so condition registers does not change after that.
The only good thing about ppc asm is it's not x86 asm. :)
Yes, Amiga coders got into it in the 90s, since it had some useful tricks like rotate and mask in one as used here. But, it's not riding a bike like 68K. You leave 68K a few years and you can always go back to it. Learn some ppc, go away for a few years and when you come back, it's like looking at the blueprints for a bike. :D
But you are right. I know about this with address registers in 68K though that's accumulated knowledge. But on ppc op dots just don't stick to my mind. This was however in the back of my mind after I posted. I find IBM can have good resources for ppc: https://www.ibm.com/docs/en/aix/7.2?to ... emonics-branch-prediction
So, in this case, it looks like a corrupted BCPL pointer.
Quote:
Theoretically you can't be sure that the execution sequence was as shown in the disassembly above (rlnwim -> mr -> beqlr -> lwz -> crash). Could also be (even if unlikely) a jump from somewhere else to 01947B8C (the lwz instruction).
There's also a possibility the stack trace isn't as accurate as listed. One issue I brought up is the wrong process being listed when the code was inside an interrupt but it cannot tell the difference. That doesn't look like the case here.
@derfs You're right the 5600x does not have an integrated graphics card I remembered wrong.
Thanks for the reply, you cleared my doubts that I had for a long time. I've been wanting to get a second graphics card for a long time. Regardless of its performance but only to have the Passepartout for virtualization. For other projects I had in mind.
Something else to consider at the moment is that getting GPU passthrough to work is just one aspect. Sure, it's probably the biggest deal but you then need to think about keyboard and mouse and how you are actually going to handle all of this.
For example, while I do have two screens, my main one, (27" 1440p) is in front of my keyboard and mouse, my secondary screen is about 2m away and connected to my A1200 PiStorm32. So I now have the 5450 connected to a different input on my primary display. That means I need to manually press about 3 buttons to switch the input. Then inevitably I realise I didn't click inside the Qemu window so I need to go back to get keyboard / mouse to work, click the window, then go back again.
All this stuff needs sorting out.
In the world of Windows virtualisation I can't remember but I think I had a lot of this done via spice tools which of course don't exist on AOS. I also have a vague recollection that I had some script that I could run via a keyboard combination that would switch the monitor inputs for me and would need to SSH to the host from AOS to switch back.
For me, this kind of stuff is next to look at but the solution that works well for me may not be the way someone else might prefer to do it. I have a recollection seeing that there's some sort of Synergy type application for OS4 - that might be a possible solution too now that networking seems to be stable.
[edit] I spent longer than I care to admit also trying to work out why my sound no longer worked in the guest too. But of course, I was feeding sound through my monitor to my sound interface and then out to my speakers. As soon as I switched screen input the sound was no longer routed. DOH! The answer there was to physically move the cable and that's where I mean that solutions for me won't neccesarily suit eveyone. For starters I doubt everyone is running an 8 input audio interface on their computer
Likely the answer is that it wouldn't make sense to write a driver for an as-yet, unemulated Voodoo3 (at least my qemu doesn't list it as an emulated device) when you could write a driver for virtio-gpu instead or even further improve the existing ati-vga driver.
All of these things are well discussed already. I've read web pages discussing the topic in great detail going in to the pros and cons of each approach.
Whatever approach you take, you still have the exact same fundamental issue. Manpower. Writing graphics drivers isn't something some random Java developer (to pick but one example) wakes up one day and does.
As for payment, I'm guessing it either needs to be fun for someone, in which case it has to be done in spare time as and when they feel like it, or it has to be paid. I have no idea of the work involved (I can hazard a guess, it's a lot, and specialised work at that), but I know the kind of figure I'd need to be able to do it during the day as a paid gig. And you'd probably be looking at 30x that amount per month, minimum.
But that's all hypothetical, I wouldn't know how to do it anyway.
Personally I would prefer a paid "voodoo3" driver for qemu from "Hans" for example or "balaton"
Bad idea, because - Voodoo 3 only has 16 MB VRAM (Voodoo 5 up to 64 MB, but AFAIK no 3D support in AmigaOS, only Banshee and Avenger Voodoos were supported). - 3D support is limited to 16 bit screen modes, same problem as with the SM502 emulation: Most AmigaOS 4.x software doesn't support 15/16 bit screen modes any more.
OTOH Voodoo emulation is available for example in Bochs already and porting it to QEmu should be possible.
Personally I would not use this "driver" to play games I have quake 2 rtx got it on "steam" but I played with it a bit but it's been stopped for some time.
Let's say I'd prioritize this "voodoo3" driver for desktop speed even without compositing since I don't natively support it.
To a high compatibility with E-UAE (demo ect.) And at the demo-scenes. And a little bit if possible to the Browser. And to the Video Players.
I'd say it would be fine that way.
"PCemu" has the necessary documentation. through "bochs" it could be done from what I understand.
@joerg
(we wrote together)
I don't consider the games important even if with WinUAE+Voodoo3 they worked most. But I would prioritize the above list at least for my use
The idea of a Kickstarter project for a graphics card driver has been mentioned several times and I would also participate, it doesn't have to be the current drivers including Warp3d Nova. Simple 3D acceleration (MiniGL) and 32 bit Windows would be great.
Maybe @Hans has already looked into it and found it's not that easy to do and could take a lot of time. Maybe they are also afraid that Qemu with such a driver might be too much competition to real hardware, I don't know.
@Balaton told me that writing a simple framebuffer driver that allows Windows 32-bit output would take someone with experience maybe 4-5 days of work.
We could pre-fund this project and I'm sure there are some supporters already. But we can't force anything.
Is the uaegfx driver open source? Not much features either, but supports 32 bit modes and it's very well tested since years with UAE. Might be the easiest option if it can be ported to QEmu.
It would not create any competition according to my opinion because the differences are many with the "ATI"
But I belong to the AmigaOS classic generation 3.xx
"At the time I chose the PlayStation 1" over the PowerPC and Voodoo I was even younger
I would like it as described above. Which I already do with WinUAE+Voodoo3 But qemu is faster and that's enough for me
@joerg Yes uaegfx is better but I don't know how it works between developers. But it doesn't support minigl for example On the other hand, videos with YT.rexx can be opened at 720p for example.
joerg wrote:Is the uaegfx driver open source? Not much features either, but supports 32 bit modes and it's very well tested since years with UAE. Might be the easiest option if it can be ported to QEmu.
I believe uaegfx is open source, but it is very poorly documented so there is little to no information about it to make a port.
I personally don't care too much about 3D acceleration, but being able to use 32-bit windows does. It's part of the standard of any modern operating system.
Some 2D games don't need 3D acceleration under Qemu Pegasos 2 AmigaOs4.1 because the software renderer is very fast, at least on my computer (ScummVM). But 32 bit resolutions are nowadays the standard of every modern system and that's why I would like to see it in the future with the support of the Amiga community.
uaegfx is not fit for purpose it is very fast but not good for 4.1 might as well keep sm501 for the work that should probably be done by the developers.
Voodoo3 allows you to go further even if you have to make some compromises. But as we have seen there is no need for YT.rexx for example to watch videos on YouTube for example because qemu is faster.
Yes uaegfx is better but I don't know how it works between developers. But it doesn't support minigl for example On the other hand, videos with YT.rexx can be opened at 720p for example.
It is already possible to play 720P videos losslessly with the help of YT.rexx. However, this only refers to my machine. I have made a short video about this.
Notice: This video is still being edited for HD playback.
No one is willing to add voodoo3 emulation to qemu, and the only real benefit over sm501 would be using warp3d. sm501 emulation at least gets you 64mb of gfx memory.
I just wanted to update the thread to say that if anyone is contemplating purchasing a 5450 card to use with Qemu then I would only do so if it's really cheap. I did know this is a very low end card and the giveaway is that passive heasink for cooling.
It DOES give a very nice 1080p 32bit desktop. I can go to 2048x1152 if I drop to 50Hz but try as I might I cannot get my screens native 1440p out of it at whatever Hz.
If that's all you want then sure, it's a great, very cheap, very silent option. If you want to start doing anything game related, forget it. I don't know what MACE demo is doing right but that can run very nicely at on average 40fps at 1080p sometimes hitting vsync at 50fps (when I was using 50Hz 1080p). But run something like Super Tux and you're down to 7fps. Honestly, everything else I've tried is just not worth the effort. It is perfectly possible I don't have something set up correctly. I am new to this. But it's more likely its just a poor low-end card.
I will try to get a better card but I need to weigh up the options. The more money I throw at Qemu, the more I could be throwing at a Sam460 or better.
All the same, it's very interesting and fun so no complaints!
Wow, a lot has happened since I last checked in. Congratulations on getting RadeonHD cards working with the PCI passthrough.
@MartinW Quote:
I just wanted to update the thread to say that if anyone is contemplating purchasing a 5450 card to use with Qemu then I would only do so if it's really cheap. I did know this is a very low end card and the giveaway is that passive heasink for cooling.
It DOES give a very nice 1080p 32bit desktop. I can go to 2048x1152 if I drop to 50Hz but try as I might I cannot get my screens native 1440p out of it at whatever Hz.
Those older cards only support higher resolutions via dual-link DVI. IIRC, Southern Islands (e.g., Radeon HD 75xx cards) and newer support HDMI 1.3 and UHD resolutions.
@white Quote:
Personally I would prefer a paid "voodoo3" driver for qemu from "Hans" for example or "balaton"
I'm guessing you mean Voodoo3 emulation in qemu, because AmigaOS already has Voodoo3 drivers. As Joerg said, it's not really worth the effort, although nobody's going to complain if someone adds it just for fun.
Virtio-GPU drivers for AmigaOS really is the way forward. I am looking into this. Don't expect news any time soon, though.
Wow, a lot has happened since I last checked in. Congratulations on getting RadeonHD cards working with the PCI passthrough.
The most interesting thing is that theoretically (or even practically) this mean that real pegasos2 will be able to handle RadeonHD cards through PCI->PCIe adapters as well with correct changes for BARs at start. Probably OF will be no visibly on (so same story as with Sam460 and RX cards for now), but it will be able to boot into amigaos4.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga 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
