@balaton

A lot to take in and read through, but for the moment:

Quote:

I need to go back to my 5450 so i have a baseline of how things were and do some more tests. Weather is miserable here so I can probably do that today. I'll compare master with no patches, master with patches from osdn and master with mbox patch from previous.

@kas1e

Yes, I meant the platformer. Sorry couldn’t remember it’s name 😁

I’ll download your linked tool. Unless something has screwed with it then the system should be in the state that Enhancer 2.2 left it. Other than that I’ve installed SDL2 and before enhancer, Wazp3D but I would think enhancer should have overridden that. This is what I mean though when I say I’m somewhat confused by all the different elements and options!

@Hans

Just checking, but there is no v5 driver compatible with Pegasos2, correct?

The RX cards don’t work under qemu as the driver gets stuck in a loop so under qemu at least we’re limited to HD cards.

@balaton

So I tried your qemu patches. I cloned fresh from osdn and checked out the pegasos2 branch so I was in a detached head state. Assuming that was the correct thing for me to do...

It was very unstable. I was not able to do anything of any value. Just clicking the mouse would hang the system, UNLESS I disabled interrupts on the monitor device. In which case it was no worse or better than the hack I had been using. I haven't looked at the source yet to ensure I've done everything correct. I'll do that tomorrow.

I've found a number of interesting things this evening that i wasn't aware of as I had something that worked so had just stuck with it.

1. With the original patch that tracked the levels of the interrupt, if you disable interrupts on the R9 270 as derfs had already done (in the monitor device), performance is considerably faster than if you have them enabled. Like Super Tux runs at 28fps windowed (int disabled) vs 7fps with int enabled. Isn't this the opposite to what we would expect?

2. I have to disable resizable bars in my PC bios to be able to use this card at all. If I don't do this then the firmware tries to map 4GB of ram. I don't know why 4GB when the card has only 2GB of VRAM, but windows does it too so it's not just Pegasos. My original thoughts on this were way off having just looked up what it means. Sadly, I tried to fire up a modern game in Windows without this and it was having none of it. It seems that the AMD drivers no longer recognise my main card properly!

3. You definitely can't just make up an address range and add it to the properties, even if you put the card on bus 0 where you should have all the space. The video driver doesn't see a memory range unless the firmware mapped it. Changing bits to force 32bit is one thing, making stuff up is another entirely.

So, I think I'm further off than I thought I was and it looks like I am going to have to attempt to figure out the map-in word. Also, unless I were to dedicate a machine to this permanently, disabling bar resizing isn't a viable option as I'd lose my gaming PC. Disabling mapping devices above 4G in the BIOS also helps the cause but the two options are linked. You cannot disable mapping above 4G without disabling resizable bars.

This is such a valuable learning exercise. I've also learnt as well that if the video card fans go full throttle on a real OS4 machine, I don't think I want one!

@derfs

Yeah, i checked back through and the figures only map 256MB of video ram which is why it worked. I was able to get it work work by going into my system BIOS (not the emulated one) and disabling resizable bars. Then I also see only 256MB of video memory but the range is mapped and I can proceed like I did with the 5450.

I'm kind of at the point that I need a dummies guide to all the graphics options in OS4. I was mostly able to ignore it all before because my card simply didn't support 3D. End of story. Now I'm kind of overwhelmed by Warp3D, Nova, SDL, OpenGL, OpenGLES. I'm used to "plug it in, click start, off you go!" (OK, so I know what SDL and SDL2 are since I've written stuff that uses them in the past).

What confuses me is that I can run the game Prototype and it runs reasonably OK - FPS around 30. From the console log I think that is using OpenGLES. Seems kind of poor, but I'll take it. If I try to run something that uses SDL, even with OpenGLES2 set as the driver in the SDL2 prefs panel, it's the same 7FPS slideshow that it was on the 5450. So something doesn't seem right at all.

Incidentally, all the time, the fans on this GPU are more or less full blast. I don't know if it's the issue I've seen reported where the card cannot control the fans because they don't go full blast striaght away. But it doesn't take long just at workbench before off they go. This stuff is probably off-topic for this thread.

Anyway, I'll investigate the posted patches if I can get them.

@balaton

These are the details for the ethernet which we are obviously not messing about with and they are all 0xfffffff etc. if that tells us anything?

PCI Info for ethernet:


info mtree


info qtree

LOL! I'm dumb. For some reason I thought it counted down from 0xF000000. I should know better than that !

info pci shows the ranges as unmapped. i would have to swap GPUs to be sure (I will later) but I swear that is how it was on the 5450. I do need to verify that statement though.

@balaton

I will give that a try later this evening.

Right now, I'm trying to get an R 270X card to work and I'm not sure how to handle one of the values:



That first xp3 value in "reg" enters above the first 32bit number. Consequently the firmware has not allocated a bar for it. I can make something up and map, say 0xF0000000 for len 0x80000000 but the video driver doesn't see it, it reports



Although with the 5450 I did not need to, this makes me think that I need to "commit" this information in some way as "show-pci-full" does not reflect the updated values.

@derfs - how did you get your R290 working? Did it have 2GB of video Ram? I would be interested in the values you ended up entering.

@balaton

RE: The IRQ level patch, for me, I have had no further issues with devices on bus pci.1. It doesn't help to allow me to move the GPU to bus pci.0 - if I do that then I get an instant freeze as soon as AOS starts. Performance for me is pretty bad. If it wasn't for the higher resolution and colour depth, I would be better off using my MacBook Air but I think this is just down to the terribly low-end GPU I have at the moment.

I have two, supposedly better cards arriving tomorrow hopefully that I scored very cheap on eBay. We will see what happens (one is an R9 270X which should work).

As far as I know derfs is still having to disable interrupts for his card in order to avoid freezes but he is using bus pci.0 which doesn't work at all for me. I don't know if he has tried pci.1 but I can test the R9 270 on bus 1 when it arrives.

I did have a look at the code as I figured maybe the levels needed to be tracked independently by bus number but as far as I could see, internally it was all the same bus so tracking levels per bus didn't change anything (I did try). Bear in mind I also don't know what I'm doing

[EDIT] I should add that since I'm building from source and already on my own branch I can easily test anything you need.

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!

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.

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

@white

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.

At the moment, there are only 3 GPU's that have been proven to work:

1. Voodoo of some description, probably page 20 or so of this thread if you want to check, but unless you have one, they are collectors items so you will not want to buy one. They are also expensive.

2. Radeon 5450. This is the one I personally use. It works fully but has no accelerated 3D. That is just the way this card is and will not change.

3. Radeon R9 270. This has been tested by Derfs. It supports 3D but has only been proven to work on pci.0 bus by disabling the interrupts for the card so the performance is not as good as it could be. I have not been able to get my card to work on the emulated AGP bus (pci.0) so I would like to see this card tested on pci.1 with interrupts enabled to see if that works.

For now, that's it. I also have an RX580 but there are a number of problems with that card. Firstly it's memory does not fit into 32bit address space so you have to fudge it in open firmware which may or may not be leading to the fact the driver will not initialise, it gets in an infinite loop. Unclear at this point if that could be sovled or not. I can get an RX550 to test but I expect it to be the same as the RX580.

Also worth noting that if you don't already own it, you will need to buy the Enhancer 2.2 pack for the video drivers.

As for the motherboard, the detail is all in the BIOS. Your CPU will probably support VT-d (although you don't say which CPU you have), but it all depends on the BIOS and the IOMMU groupings. You have to pass through the entire group that your GPU is in and if that means that other stuff is in that group, then you may well run into trouble as to date we have only tried to pass through a GPU (i believe this is correct).

You will also manually need to calculate the correct addresses for your setup and generate a script to execute at every startup. It is possible to ensure these addresses do not change, but at the moment it is not possible to automate the startup process.

Hopefully thats a reasonable summary? Right now, none of this is at all "user-friendly", it's all very much at the "does it work at all" stage. Where we go from here is TBD. Balaton is working on some improvements to Qemu that will massively help but there are no indications how long that might take, nor should we (IMO) put any expectations on him! (I assume Balaton is a he - apologies if not, I don't know)

[EDIT] Personally, I'd still like to see some VIRTIO drivers for OS4 but certainly for GPU that's a very big ask and I'd imagine if it happened at all, it would be a long way off. I have said that I'd be happy to look at a network driver but I'm still in the information gathering stage. And I've never coded anything like that before so it's probably not realistic. You don't know until you try though.

So I spent a few hours this evening looking at my RX580. I didn't realise until afterwards that it was already reported way, way back in the thread that RX cards won't initialise because the driver is stuck in a loop with this message in the debug log:



Since the memory bars are defined as 64bit prefetchable I did try to remove the prefetch bit but it didn't help. If I'm honest, I don't really know what that message means. I also don't know if defining a region in the firmware that hasn't actually been probed by the firmware would even work? Rather than try to map my entire 8GB of video memory which clearly isn't going to work, I tried to just map 2GB at an address that would have fallen within the original 8GB but obviously sticking to the first 4GB of memory. It looked like AOS assigned the memory, but the driver wasn't happy about something anyway and stayed in that loop.

I probably won't bother again with the RX580 unless there's something specific anyone can tell me to try.

Would of course be nice to have a 3D card to try but half the cheap R270 cards on eBay seem to be faulty!

@derfs

Interesting that you still need to add interrupts = No in your monitor settings, however, probably worth noting what I said about bus pci.0 it may be that moving back to bus 1 would resolve that?

I moved my Data partition to SFS/02 last night and did not get any further random crashes, but it was getting late so I didn't do much.

@Maijestro
Thanks - it would appear I'm already a subscriber!

@Hypex
Err, oops! Well spotted. That might mean all the times I've been saying "no useful debug output" was my fault and there could have been some. Damn. Well, I intend to carry on using this setup for now so if I find anything more of use then I can report back. Of particular note at the moment is that with this patched version of Qemu I tried to move the passthrough GPU to the bus pci.0 and I still could not get through workbench startup. I don't really know what's going on there but I didn't look in any detail at the patch.

First of all you need to be running Qemu built from source. If you're not already then there are some instructions here:
https://wiki.qemu.org/Hosts/Linux

Once it's built from source, tested and running as-is then all you really need to do is download the "mbox" file from the link posted in #787, check out a new git branch (if you like, I guess it only matters if you intend to contribute a pull request later) and then run the command:


This will patch the qemu sources and you then just rebuild again - a simple "make -j 8" was sufficient for me, I did not need to rebuild the whole tree.

When you build qemu from source, don't build it all unless you really want to, it's kind of huge, just build PPC with "configure --target-list=ppc-softmmu"

I did have a feeling I probably wasn't posting enough information there, sorry!

From what I can gather errors like those are not uncommon at all across every kind of machine from emulated to X5000 so I will not take too much notice for now.

And of course I understand that this is very "bleeding edge" so I totally accept there will be issues. No problems there. Honestly, if the net result of all of this is that it can't be made to fully work then, hey, we tried. But it's not looking like that will be the case.

I'll probably go quiet on the topic a bit now unless anyone wants anything specific from me. I need to do some more general stuff like get my setup tidied up. On that note, I may see if I can get my RX580 working but I have a feeling that will be problematic since it has 8GB of video ram but I'm going to see if I can somehow force the OS to see it as a smaller region. Not today though.

Well, I'm sort of pleased to say that i don't think the DSI errors that I'm getting are anything to do with the rest of the hangs that we have previously been getting because I just got one while not running a passthrough GPU at all.

That makes this next question somewhat OT, but can anyone point me in the right direction on this error? There's probably not enough information here but you never know!




I'm at the point really of creating a completely new OS4 install and I need a bit of a dummies guide because I don't really know what file system I should be using or anything. On classic I just use PFS3AIO for everything and have never had a problem.