Who's Online |
24 user(s) are online ( 21 user(s) are browsing Forums)
Members: 0
Guests: 24
more...
|
|
Headlines |
-
arabic_console_devicepro2.lha - driver/input
Apr 28, 2025
-
openmedalofhonor.lha - game/fps
Apr 27, 2025
-
reportplus.lha - utility/misc
Apr 27, 2025
-
astone.lha - graphics/viewer
Apr 26, 2025
-
amigagpt.lha - network/chat
Apr 25, 2025
-
privoxy.lha - network/misc
Apr 25, 2025
-
wormhole.lha - network/misc
Apr 25, 2025
-
vasmm68k_mot.lha - development/cross
Apr 24, 2025
-
vasmm68k_std.lha - development/cross
Apr 24, 2025
-
vasmppc_std.lha - development/cross
Apr 24, 2025
|
|
|
|
|
Re: QEMU GPU-PCIe AmigaONE
|
Posted on: 4/25 23:31
#21
|
Quite a regular 
|
@white
You can try same command with '-device vfio-pci,host=05:00.0,bus=pci.0,x-vga=on,multifunction=on -device vfio-pci,host=05:00.1,bus=pci.0 -device bochs-display,romfile=""' part replaced with '-device sm501' then try with and without sudo and see if sound works or not. If it does not work with sudo then that's the problem and has nothing to do with vfio.
|
|
|
|
|
|
Re: ATI X550 support
|
Posted on: 4/25 23:26
#22
|
Quite a regular
|
I tried with Linux but I could not get a picture. It sees the card but selects a mode that my monitor says is out of range. The log I get is:
radeonfb 0000:00:08.0: enabling device (0000 -> 0003)
radeonfb (0000:00:08.0): Cannot match card to OF node !
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=398.00 Mhz, System=250.00 MHz
radeonfb: PLL min 20000 max 40000
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type CRT found
radeonfb: EDID probed
Console: switching to colour frame buffer device 320x90
radeonfb (0000:00:08.0): ATI Radeon 5b60 "[`"
The Cannot match card to OF node seems normal, amigaone has no OF and I get the same with ati-vga which does produce picture. The clock values seem to match what wikipedia says but the memory and core values are swapped? Maybe it can't handle the EDID from the monitor or I can try what if I only connect one output. I've connected both VGA and DVI and with U-Boot I get ouptut on both, with guests I only get garbled output on VGA with AmigaOS and MorphOS but they freeze and out of range output for the monitor on Linux. Assuming 8x8 font then 320x90 would be 2560x720 where the native mode would be 2560x1440 but that's likely too large for this old card and I think the monitor also only accepts that on HDMI so maybe it's just selecting the wrong mode. I thought I have a radeonfb option to set mode in kernel command line but checking again looks like I didn't so maybe that's why. EDIT: Tried adding video=radeonfb:1280x720 to kernel command line but then got some error which may be because reset issue with older AMD cards which only work once per host reboot and there is no fix for that for these older cards only for RX ones so this does not seem to be a very usable setup so far.
Edited by balaton on 2025/4/26 0:05:04
|
|
|
|
|
|
Re: QEMU GPU-PCIe AmigaONE
|
Posted on: 4/25 23:15
#23
|
Quite a regular
|
@white Quote: Initially during the installation with the USB stick for the installation in SETTINGS / SCREENS
I have the possibility to choose how to set the two monitors
but at the end of the installation the option disappears and I can no longer choose the monitor with Radeon. This is expected as you assign the Radeon to vfio-pci driver so it won't be visible to the host any more. You can't use a card on the host and pass it to the virtual machine at the same time so it's removed from the host and given full control to the guest. So after vfio-pci is set up you can pass through the card to the guest and the guest can drive it but the host won't see it as a GPU only in lspci as a device using vfio-pci driver. Quote: At the moment for Nvidia I solved it this way:
GRUB_CMDLINE_LINUX_DEFAULT="loglevel=3 quiet nvidia-drm.modeset=1 rd.driver.pre=vfio-pci amd_iommu=on iommu=pt vfio-pci.ids=1002:6798,1002:aaa0" This should also work. You likely don't need amd_iommu=on as that's the default and amd_iommu does not take "on" as a valid value so it is just ignored. What makes this work is rd.driver.pre=vfio-pci which may do what softdep pre lines do in modprobe.d/vfio.conf and gets vfio-pci loaded before the GPU drivers so it can bind to the card. It does not matter what way you reach that point, what's important is to have the card and all other devices in that IOMMU group assigned to vfio-pci. Quote: THIS allows me to have on the main screen with the Nvidia GPU all controls from the BIOS to the main Arch screen this is the command:
/etc/default/grub
nvidia-drm.modeset=1
It would basically need the same command for the Radeon GPU to make it work in (modeset=2) I'm not sure that makes sense but I don't know what this option does. You don't need a graphics driver for the Radeon but have to assign it to vfio-pci if you want to use it in the guest. Then it's normal that you won't see it on the host. Quote: But I can't find the command or a program to split the two GPUs that's why the sound is NOT heard on the Monitor where AmigaOS opens because there is no active option for the second Monitor. I said this before but maybe wasn't clear enough. You can either use via-ac97 and then sound should play on the host like any other apps. If it doesn't it may be an issue with running QEMU as root. You can test this without pass-through: just run AmigaOS Install CD with -vga none -device sm501 like before any pass through then if that works try to run the same command as root still without pass through. If sound is gone when you run as root it may be an issue with security settings of the host Linux that does not allow QEMU to connect to the sound server if not run as your user. Another possible way that should work is to pass through the sound function .1 of the sound card as well such as -device vfio-pci host=x:y.0,multifunction=on.x-vga=on -device vfio-pci,host=x:y.1 then you should see an HDMI output in the AmigaOS guest and then can set AHI to use that then you should hear sound on the monitor where the Radeon is connected.
|
|
|
|
|
|
Re: Project - hardware to run AOS4 for 35 euro on QEMU 10 + GPU passthrough
|
Posted on: 4/25 20:12
#24
|
Quite a regular
|
@smarkusg Quote: Power consumption mainly depends on the use of the card anyway. How it works at idle - it will be a small difference. Assuming the driver knows about power management and does not run the card at full power all the time. With Windows or Linux drivers that probably works. I'm not too sure about AmigaOS or MorphOS drivers. Maybe there's a way to monitor this somehow to make sure. I think Nikitas used radeontop or something like that to see activity of the card, I don't know if that can also show settings. The opposite can also be true that if the driver can't put the card to higher power setting then it could run slower than it could. As you say lots of unknowns.
|
|
|
|
|
|
Re: ATI X550 support
|
Posted on: 4/25 20:05
#25
|
Quite a regular
|
I have tried this after having to patch i915 module with VGA arbitration patch to allow x-vga=on to work with Intel iGPU. On unpatched i915 without x-vga=on it freezes the machine or breaks host display and does not work as the ATI card ROM wants to access VGA ports. With patched i915 driver it now can access the card and I can see amigaone U-Boot output on it but neither MorphOS nor AmigaOS seem to like this card. The pegasos2 firmware does not recognise it neither MorphOS. AmigaOS on amigaone does not print the missing graphics card message so maybe it finds the card but then stops without printing any logs (even with loglevel=17) and I get no picture. So not sure how to find where it stops. Is there a way to force a crash log in AmigaOS kernel somehow when it's stuck? I can only get a register dump from QEMU or could try gdb backtrace but I don't know what the addresses belong to so that's not too useful.
|
|
|
|
|
|
Re: WormHole: great tool to easily transfer files via LAN
|
Posted on: 4/25 19:57
#26
|
Quite a regular
|
@Reth
I don't know what ports WormHole needs but for QEMU network configuration docs see the FAQ on my qmiga.codeberg.page The QEMU doc linked from these shows how the user/slirp network works. It's behind it's own NAT so if you want to allow connection to the guest you need hostfwd option to open the port similar how you have to allow incoming connections on your router. Think of the user/slirp network as a LAN behind a router doing NAT.
|
|
|
|
|
|
Re: QEMU GPU-PCIe AmigaONE
|
Posted on: 4/25 19:51
#27
|
Quite a regular
|
@joerg Quote: Benchmark tools like RageMem and GfxBench2D, with own implementations of such functions, are very rare exceptions, 99.99% of the AmigaOS software simply uses the C library bcopy()/memmove(), memcpy(), ... or kernel IUtility->MoveMem(), IExec->CopyMem[Quick](), ... or IGraphics->ReadPixelArray(), IGraphics->WritePixelArray(), ... functions instead of trying to implement more than 5 different versions of each of those functions for the various different PowerPC/POWER CPUs themselves. I guess benchmarks were written to test something that's used by AmigaOS. If not then they aren't quire measuring what they should. According to the above there might at least be 3 or 4 different routines in AmigaOS and depending on which one is used we might get different results. I don't know what AmigaOS uses but we were investigating GfxBench2D results and Hans posted the benchmark for that so it should be similar and GfxBench2D was written to test what AmigaOS does so it should be similar to at least one of those routines in AmigaOS too. Quote: At least one particular version. I haven't tested it but I had the reference in the message where I read about that. I did test that having dcbz in the benchmark from Hans is slowing down QEMU and so probably GfxBench2D too. Quote: (Main difference: My functions were 99% C code, with only some asm inline("dcba"), asm inline("dcbt"), etc., instructions, while Apple's slightly slower code is 100% assembler instead.) Maybe you used a newer C compiler with better optimiser and Apple had older compiler. I guess they did an assembly version for a reason and it was faster for their use case. Quote: Just make sure you use a suitable CPU for MacOS PPC emulation as well, and not some junk like the 7400 as you initially did for the Pegasos2 emulation  I'm not sure that would make a difference. The comments in the above quoted bcopy source say that these would be patched to nop for 7400 and dcba is nop in QEMU anyway so it should not matter.
|
|
|
|
|
|
Re: Project - hardware to run AOS4 for 35 euro on QEMU 10 + GPU passthrough
|
Posted on: 4/25 19:36
#28
|
Quite a regular
|
@smarkusg Quote: *) the results on a newer processor than mine from 2012 should be much better This may be a myth. People tried on different machines already and all got the same results that seem to be limited by something else than CPU speed so I'm not sure it would help until proven. Your results show that the faster card is actually slower in VRAM access and only slightly faster with larger rectangles and in compositing. IMHO does not worth the almost 4 times power draw when you get the same result with a simpler card. It may be different if we find out what limits performance but until then unless there's something this faster card can do that the slower one doesn't it does not seem to be a good choice.
|
|
|
|
|
|
Re: Pegasos2 with RadeonHD/RX via bridge
|
Posted on: 4/24 22:06
#29
|
Quite a regular
|
@Estrayk
It boots faster with BBoot because it reads all modules in one zip instead of loading them one by one so less disk activity. Besides fixing 64bit BARs that's only relevant for newer cards with a PCIe bridge, BBoot also fixes an interrupt issue possibly avoiding lost interrupts with multiple PCI devices so could avoid some hangs caused by that. The drawback is that you need to keep Kickstart.zip up to date but that's not much work since Kickstart dir is not changed often, you just have to remember to zip it when it was changed.
The upcoming kernel will fix more than what BBoot fixes and allows using PCIe bridges that BBoot alone does not do on real machine (for QEMU it's enough as the bridges are handled by the host in that case). After updated kernel (or if don't need the fixes) you can still use only the boot part without the PCI fixes part by setting bboot configuration variable in firmware as described in the readme. Disabling some messages with bboot variable may also make boot a bit faster on real machine.
|
|
|
|
|
|
Re: WormHole: great tool to easily transfer files via LAN
|
Posted on: 4/24 17:33
#30
|
Quite a regular
|
@Maijestro True but creating a zip on macOS can be done from right click menu, if AmigaOS has similar function then it's just a few clicks more which is bearable until the next WormHole version 
|
|
|
|
|
|
Re: QEMU GPU-PCIe AmigaONE
|
Posted on: 4/24 17:28
#31
|
Quite a regular
|
@joerg According to QEMU dcba is available on embedded CPUs (440, e500, e5500) and G4 so only G3 and classic Amiga accelerators might need dcbz. But that also means that all old software will likely use dcbz so even if it's fixed in AmigaOS now (which then we will also need to get as an update eventually) it won't fix all problems with existing software, and the same problem also exists with MacOS running on QEMU. So the dcbz needs to be optimised in QEMU anyway for those. I'm not sure about the exception you mention. I did the test on Linux guest, no AmigaOS so unless that would do the same this isn't the problem. Also target/ppc/mmu_common.c#L322 says it will do nothing so I'm not sure the guest would get an exception on QEMU. It's just the current implementation of the dcbz helper goes through probe_write or an even slower loop which is very inefficient. It might be faster just to translate dcbz to a loop writing cache line size zeros which my patch attempted and without being too much optimised it was a bit faster. Some of that inspired some optimisations that at least helped the user emulation case but also means my patch does not apply any more and I don't want to redo it. Somebody interested in this could do that, QEMU is open source and anybody could contribute, it's not something that only I could fix. The benchmark is in the message I've sent to QEMU list linked above so anybody could also modify it to test VRAM on any guest OS they like and see if that's worse or same as accessing RAM (to verify how much of it is dcbz and how much is the overhead of smaller transfers). That's also not something that only I could do. That's why I'm sending these to here and to the QEMU list so if somebody wants to help this is open for experimenting and sharing ideas and even code with open source. I may do it eventually if have nothing better to do but it would be faster if more people helped.
|
|
|
|
|
|
Re: WormHole: great tool to easily transfer files via LAN
|
Posted on: 4/24 17:12
#32
|
Quite a regular
|
@Maijestro
You can always make an lha or zip archive of the dir you want to send through but of course it would be more convenient if WormHole did that for you without extra effort.
|
|
|
|
|
|
Re: QEMU GPU-PCIe AmigaONE
|
|
Quite a regular
|
I dug up the benchmark we got before that does what the Gfx2D benchmark does and did a quick test on current QEMU. This is just copying between two malloc regions, not to actual VRAM but it can test the emulation overhead. Running with just CPU emulation with qemu-ppc (user emulation that runs a Linux executable complied for different arch) I've got:
src 0x40802008 dst 0x40903008
byte loop: 2.22 sec
memcpy: 2.21 sec
copyToVRAMNoAltivec: 1.69 sec
copyToVRAMAltivec: 2.12 sec
copyFromVRAMNoAltivec: 2.24 sec
copyFromVRAMAltivec: 2.82 sec
Running same executable under qemu-system-ppc -m pegasos2 booted with Linux I've got:
src 0xb7a2f008 dst 0xb792e008
byte loop: 5.28 sec
memcpy: 5.06 sec
copyToVRAMNoAltivec: 2.52 sec
copyToVRAMAltivec: 2.66 sec
copyFromVRAMNoAltivec: 6.37 sec
copyFromVRAMAltivec: 6.84 sec
So whatever tricks FromVRAM does can slow it down and I think that was dcbz. Looking at the benchmark it looks like ToVRAM uses dcbt which does nothing on QEMU so no problem but FromVRAM does dcbz which is still a problem. Maybe it does not really need to zero the destination before overwriting it but could be that dcbz was supported on more CPUs so that's why that's used and not something else that may not be available everywhere. In any case I think dcbz is also the same issue why the Tricky test in RageMem is bad and it also affects MacOS so this should be solved for all. If somebody wants to help fixing this start here: https://lists.nongnu.org/archive/html/ ... ppc/2025-04/msg00297.htmlI may come back to this one more year later as I have lot of other things I can do so don't wait for me to fix it, start contributing.
Edited by balaton on 2025/4/24 13:04:37
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/23 23:05
#34
|
Quite a regular
|
@Reth Quote: Update: Seems GTK has issues when using different screen resolutions while in full screen. E.g. running WB in 1920x1080 and opening an 1024x768 screen => after closing that screen WB stays in the lower resolution until switching to Window mode. Does the zoom-to-fit option has an effect on that? You probably won't notice a performance difference with gtk. SDL is nice but if it does not work then not many other options left. I've heard some people had problem with mouse on Windows with gtk. Adding -device usb-mouse may fix that, if not a better option is -device usb-tablet but that needs a driver in AmigaOS which I think was posted somewhere here a while back but I don't remember when and where. If all else fails QEMU also has a built in VNC server so you can view it with a VNC client. No need to run VNC server in the guest but that may not be very convenient so try when exhausted all other options. You can check with -display help which display backends are available in your build. You could also try setting lower resolution in guest and use it in a window to avoid scaling.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/23 18:48
#35
|
Quite a regular
|
@Reth
If it works with gtk why don't you use that? Does it unscramble when switching back to full-screen? So only shows problem in window or stays like that even after going back to full screen? What if you resize the window? The problem is probably that SDL does not handle scaling to 0.99% or just a few pixels less too well. I don't know SDL, maybe there are people here who know it and know about something that can be set for it to use better scaling algorithm.
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/23 16:32
#36
|
Quite a regular
|
@Reth
Why do you have -cpu 7447 and -boot order=c in that command? It's not related to the issue but -boot does nothing and -cpu likely not needed either.
We have already discussed that default scaling of SDL may not be too accurate. Does it work better with -display sdl,gl=on,full-screen=on ?
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/23 13:54
#37
|
Quite a regular
|
@smarkusg With the firmware included in QEMU this could be a problem: u-boot-sam460ex/board/ACube/Sam460ex/init_radeon.c line 216In newer versions this is moved to board/ACube/common/init_radeon.c and changed a bit but still has onbus < 2 and seems to expect a bridge in that case and looks at BAR1 instead of BAR4 which can be a problem if the card does not have the expected BARs. So I think it won't work with the default old firmware in QEMU with newer RadeonHD that has 64bit BARs. Updated U-Boot may be better but I did not check it and not sure it's prepared to handle a RadeonHD on PCI, only if it appears behind a bridge which was probably added for Sam440. I intend to update the sam460ex firmware in QEMU at one point mainly to fix the USB issue and could also improve PCIe emulation to make that work but it's some work I had no time to finish yet. (I've only left the old firmware in QEMU because that's what I started with and it worked and I did not update later because aCube sold the binary and I did not want people to try to get it from QEMU instead which may not work on real machine as it had additional patches and would spoil aCube's business. While I think software should be free I also respect those who respect the rules and contribute back.)
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/23 13:39
#38
|
Quite a regular
|
@kas1e
There are still a lot to be understood about this so it's not guaranteed that getting the fastest machine and GPU will result in fastest emulation. But you and Hans could better find out more about it if you test it and hopefully we'll also see the results of that at one point. Fixes can be sent to QEMU too, contribution is open. Currently it seems RadeonHD 7000 (and similar era) cards may be the best option and if older cards work those may also be interesting but that's untested yet. With RadeonRX there might be more problems but let us know if you try if that works too.
|
|
|
|
|
|
Re: Which FTP Client can best be used within AOS4? (AmiFTP always crashing)
|
Posted on: 4/23 10:27
#39
|
Quite a regular
|
@Reth
May only be needed for normal ftp, not if it uses passive mode. FTP normally wants to connect back to data port which has to be allowed with -netdev user that puts guest behind its NAT so normally only outgoing connections work.
How to configure your host firewall is not a question for QEMU or WormHole. Consult docs of your host OS/firewall on how to reset it.
Edited by balaton on 2025/4/23 13:34:01
|
|
|
|
|
|
Re: What the fastest possible x64 emulation way of OS4 today ?
|
Posted on: 4/23 10:21
#40
|
Quite a regular
|
@Reth
What QEMU version are you using and where did you get it from? What qemu options do you use?
|
|
|
|
|
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
