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.
@MartinW Maybe AmigaOS programs the BARs as long as there are addresses assigned in the device tree so it may be enough to set that and not actually map-in the BAR but I don't know. I may try that with my boot loader though as that would simplify it too if it only has to patch the device tree and not touch the cards.
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:
Bus 0, device 2, function 0:
Ethernet controller: PCI device 10ec:8139
PCI subsystem 1af4:1100
IRQ 9, pin A
BAR0: I/O at 0xffffffffffffffff [0x00fe].
BAR1: 32 bit memory at 0xffffffffffffffff [0x000000fe].
BAR6: 32 bit memory at 0xffffffffffffffff [0x0003fffe].
id ""
info mtree
address-space: rtl8139
0000000000000000-ffffffffffffffff (prio 0, i/o): bus master container
info qtree
dev: rtl8139, id ""
mac = "52:54:00:12:34:56"
netdev = "net0"
addr = 02.0
romfile = "efi-rtl8139.rom"
romsize = 262144 (0x40000)
rombar = 1 (0x1)
multifunction = false
x-pcie-lnksta-dllla = true
x-pcie-extcap-init = true
failover_pair_id = ""
acpi-index = 0 (0x0)
x-pcie-err-unc-mask = true
class Ethernet controller, addr 00:02.0, pci id 10ec:8139 (sub 1af4:1100)
bar 0: i/o at 0xffffffffffffffff [0xfe]
bar 1: mem at 0xffffffffffffffff [0xfe]
bar 6: mem at 0xffffffffffffffff [0x3fffe]
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.
Anybody who has a real pegasos2 and a PCI network card (any PCI network card that has a driver may do) could please help to test if this problem reported here works on real hardware: https://osdn.net/projects/qmiga/ticket/48376 The real pegasos2 has two on board network ports which we don't emulate so maybe that has something to do with it but maybe also nobody tried with a PCI network card as there are already enough ports without that so could be this also happens on real machnine.
Not sure if i understand correctly, but did you mean just to test if any PCI network card works at all in pegasos2 PCI slot ?
I tried right now PCI network card from my x1000 in pegasos2, so proved to working drivers, working on os4, etc. The card marked as "RTL8139D".
I just go to prefs:internet, and replace for interface from my via-rhine.device on rtl8139.device. Reboot, reattach cable to PCI network : and everything works. I can run Odyssey, can visit sites, can ping google, etc.
Anything else to check in terms of this PCI network stuff ? Like maybe output from ranger on PCI bus tabs or something ? Or maybe some special steps to do ?
Anyway, what is definitely true, is that RTL8139D PCI based card over rtl8139.device driver works for sure in real Pegasos2 , without hangs.
PS. I may try to run Linux, to see if this network card will works there too, and then grab some info.. if you need, of course.
@kas1e That bug report was network not working _under MorphOS_ so now that you've confirmed it works with AmigaOS can you also try booting the MorphOS demo iso and see if doing something like ifconfig or ping in shell works with that card? On QEMU this will only pop up a requester about needing bsdsockets.library but this may be because something is missing on QEMU which MorphOS expects (such as the on-board network ports) but I'm interested if not using the on-board ports but PCI network card works with MorphOS on real PegasosII.
The hangs we see under AmigaOS is due to a problem with handling multiple devices using the same interrupt in QEMU but that's likely different from the issue reported with MorphOS.
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!
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.
When you have interrupt enable, it will wait for interrupt to sync up to monitor, so it will be slower.
60 FPS = 16,6 ms (vsync) 30 FPS = 33,2 ms (vsync) 28 fps = 36ms 20 FPS = 49,8 ms (vsync) 15 FPS = 66,4 ms (vsync) 12 FPS = 83 ms (vsync) 10 FPS = 99,6 ms (vsync) 9 FPS = 116,2 ms (vsync) 8 FPS = 132,8 ms (vsync) 7 FPS = 149,4 ms (vsync)
Under QEMU it takes 2,17 times longer to calculate, handle game logic, and transfer stuff to GFX, and play music and sounds, 66ms-36ms = 30ms is the time game has to wait for vsync at 15fps.
why game drops down to 7fps is odd, perhaps its not even able keep up with 15 fps at times. Its like other parts of the game / music/sound etc, is causing main part to miss lots of vsyncs.
Clearly the games does not take in count, if game does not keep up with the monitor, then it does not make sense for the game to wait for vsync.
Quote:
Isn't this the opposite to what we would expect?
Well on faster systems, where game runs faster then monitor, allowing the game to wait for vsync, means that CPU resources can be used on different tread, or task, this can improve overall performance, for example you can notice less sound/music problems, as thread that handling that gets more time to decode mp3 or ogg/verbs music streams, etc.
Now if game needs 100% of CPU to retch 60 FPS, then waiting for vsync does not matter. Now if game needs 60% of CPU to retch 60 FPS, then waiting for vsync does matter. If game runs at 100% at 200 fps, then other parts of game might be starved, and not balancing the CPU resource well, then restricting it to monitors max, make sense.
Edited by LiveForIt on 2023/7/15 9:55:26 Edited by LiveForIt on 2023/7/15 10:06:34 Edited by LiveForIt on 2023/7/15 10:10:49 Edited by LiveForIt on 2023/7/15 10:11:50 Edited by LiveForIt on 2023/7/15 10:21:33 Edited by LiveForIt on 2023/7/15 10:24:32 Edited by LiveForIt on 2023/7/15 10:40:26
(NutsAboutAmiga)
Basilisk II for AmigaOS4 AmigaInputAnywhere Excalibur and other tools and apps.
@MartinW By SuperTux you mean pure platform one, or my SuperTuxKart port ? If the first one, it's too old, and may behave badly, while SuperTuxKart (gl4es version at least) will behave more correctly.
Also for counting numbers, you may try my irrlicht port which come with examples, providing minimal stuff to count GFX grunt. Like 03.Quake3 example will be good test for both disabled and enabled interrupts ways:
the driver only support power mangement on RX card, not HD cards. but you can always water cool the sucker, if insist on using HD card
That depends on the driver version. RadeonHD.chip v5.x has dynamic power management. Older versions just set the card's voltages and clocks to their rated values.
When you have interrupt enable, it will wait for interrupt to sync up to monitor, so it will be slower.
That's if vsync is enabled/disabled in the game itself. If the driver's interrupts are disabled, then it'll still wait for the vsync when requested to do so. However, it'll busy-wait by monitoring the vblank status register. That should be both slower and less accurate.
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!
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...
After "git checkout pegasos2" "git status" should say On branch pegasos2 not detached head but if in "git log" you see the 3 patches (1 + 2 reverts) on top then that's probably OK just not sure what you did then.
Quote:
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.
Then did this patch do anything at all? Does disabling GPU interrupts help with qemu master without any patches or some patch is still needed and it looks like the previous is better? This suggests I'll have to check how vfio handles interrupts as that may somehow bypass the IRQ routing these patches change but I don't see how.
Quote:
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?
I'm just guessing but on real hardware IRQ may be better but on emulation an interrupt stops translated code, goes back to emulator and looks up a different translated block with the IRQ handler then after running that it goes back to QEMU again and does the same to go back to the code that was running whereas a jump or function call in translated code can jump to the next block directly so IRQs are kind of expensive on QEMU so a lot of them can be bad for performance.
Quote:
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.
I know nothing about resizable BARs so can't comment on that but as said before the PCI bus memory and io spaces are mapped to system memory in windows so the CPU will only see BARs that are mapped in these windows. You can map card resources anywhere in PCI address space but unless they are in the windows the CPU will not see them. You can check this in info mtree which shows the PCI address spaces for both PCI buses and you should see there BARs that are mapped too and in the system memory or address space you see the windows with addresses that show what part of the pci regions are visible there. The memory windows are 1 to 1 mapped so for window at 0xc0000000 you should also map the bar to 0xc0000000 in PCI address space. The io bars start from 0 so an io BAR mapped at 0x1000 will be visible at window + 0x1000. Hope this makes sense but should be understandable looking at info mtree output. The only difficulty may be the lot of address spaces. There's one system address space, there are memory and io spaces for each PCI bus and QEMU also has an unused system io space that's just listed as i/o which is used on PC where there's a system io space but PPC is all memory mapped has no separate io bus. Also QEMU list all of these twice for some reason once as address-space and once as memory but I'm not sure what's the difference.
Quote:
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.
I'm now not sure the BARs need to be mapped by the firmware because trying to find why my boot loader works with pegasos2.rom but not with VOF I first suspected that but now I've checked and while the pegasos2 firmware adds assigned-addresses property with addresses for sm501 it does not program the BARs and the AmigaOS driver still maps them. But this may be different for VGA cards that SmartFirmware wants to use for output so it will map them but not sure what happens if they aren't mapped. I think your script just patched assigned-addresses property and that was enough so I think the AmigaOS drivers would program the card and just need the assigned-addresses from the firmware but I'm still not sure. I've tried adding assigned-addresses to VOF but that did not help with my boot loader so maybe something else is missing from the device tree but that's unrelated to your gfx card BARs.
Quote:
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!
Indeed, this is a fun way to learn a lot of stuff, that's why I also like to do it.
A lot to take in and read through, but for the moment:
Quote:
Then did this patch do anything at all? Does disabling GPU interrupts help with qemu master without any patches or some patch is still needed and it looks like the previous is better? This suggests I'll have to check how vfio handles interrupts as that may somehow bypass the IRQ routing these patches change but I don't see how.
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.
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
Donate
