What the fastest possible x64 emulation way of OS4 today ?

@geennaam

First of all, thank you very much for the test and the tutorial.

The configuration of GPU passthrough will be feasible for the fewest, because it is very complex. But you have proven that it is generally possible. Good work.

What you have not mentioned is whether simple 3D acceleration is supported by Warp3D. Could you confirm that?

Image material or videos would also be interesting.

EUREKA!

All that was needed is a bit of voodoo magic.

@geennaam
Voodoo3 prices to go up?
This information is like a stock market leak ... time to buy

And seriously congratulations

Lol! Yep. Anything associated with Amiga costs a premium.

One question - isn't Voodoo3 AGP? - never mind, there are PCI versions.

[edit] So what features are available aside from 32bit 1080p? Any acceleration?

@MartinW



Edit: Cow3D-os4 runs on a 16bit screen (26 fps). So Warp3D works

@geennaam
Quote:

It should be faster of course, as sm501 emulated, while (if I understand right), Voodoo3 is like real one now for QEMU and not emulated ?

Anyway, what we have is:

1). PCI part code from kernel of OS4 emulated fine
2). PCI cards (so drivers and related stuff) works too.

We left then with AGP part of the pegasos2's kernel and/or Radeon driver itself. Even if AGP is PCI66 in pegasos2 (that for real?), the specific code in kernel still present to handle this.

For 3D, you may try something simple from os4depot (as for pegasos2 if i remember right, minigl and warp3d come by default). Like for example Cube game:

http://os4depot.net/share/game/fps/cube.lha

If it gives 30 and more FPS, then it means 3D is about to be native. If 2–3 FPS, then emulated.

@geennaam
>But at least I've managed to beat the CyberstormPPC with voodoo 3 3000 at the same screenmode. This is mainly because of a better memory bandwidth: http://hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS/Result/2653

I have a question a can you do a little experiment as you have time ?
If you have not compiled QEMU with "--enable-lto" can you check with that,
Run qemu with "-cpu apollo7" and do a test ?

You wrote that you are not familiar with Uubntu/Linux. Possibly compile under clang instead of gcc for the test ?
You are probably using focal/ubuntu 20.04 - here it should be -> https://launchpad.net/~lappydapper/+ar ... field.series_filter=focal


Thank you

OK I think I've found the reg bit for endianness. I see in the AmigaOS log:

and in ATI reg docs:

There's no further info on that but I guess this should flip register aperture endianness to big endian which is definitely not done in QEMU and I'll have to find out how this could be emulated. If we can't change memory region endienness on the fly then we need two of them and swap them on this bit. I'll ask on the QEMU list unless I can find it out. (Or we could just do the swap in the handler functions if the bit is set which may be the simple route for now for testing.)

That should at least get better results with ati-vga and AmigaOS but does not explain why @geennaam did not get it work with passed through card bceause I assume this bit should work there.

Update: I've tried to implement byte swapping now which makes most of the register values show up correctly but now some regs are wrong such as 0x50 CRTC_GEN_CNTL, 0xf8 CNFG_MEMSIZE, 0x108 CONFIG_APER_SIZE that are now byre swapped. Is this bit only supposed to swap some regs but not others or how does this work. Maybe there are different ways to access registers but in QEMU they end up in the same place. I'll need to check because I forgot how I implemented it back then. I think I put this aside for now and do something else.

@kas1e

Cube runs too at about 10 fps.

@smarkusg


QEMU fails to build with CLANG. Something to do with virtfs-proxy-helper


But at least its builds with --enable-lto

Used the following command line:



Cow3d still runs at 26 fps.

But Cube now runs at 30-50 FPS. Even >80fps when staring at a wall.

GFXBench2D performance improved as well: http://hdrlab.org.nz/benchmark/gfxbench2d/OS/AmigaOS/Result/2655

@geennaam
Thank you

>But at least its builds with --enable-lto
My mistake with the "lto" - sorry for the time involved.

>But Cube now runs at 30-50 FPS. Even >80fps when staring at a wall.

Also many thanks

Don't do the clang test if you don't want to - it would just be a gcc vs clang test.
I have an Apple M1 and somehow the tests looked weird to me.
My x86 laptop (x86 laptops are a failure !) is not suitable for testing like your desktop machine.

Thanks again and good luck !!!

SmartFirmware shows up on my display.

Without the addition VGA device, I have no way to switch to the emulator. CTRL+ALT+G doesn't work

@smarkusg

apparently --enable-lto is a gcc option. without it, I can build qemu with CLANG. But so far I do not notice a difference in speed.

@balaton

The PM4_MICROCODE_ADDR, PM4_MICROCODE_DATAH, PM4_MICROCODE_DATAL registers have a different with the RV100 chipset, but they're essentially the same thing: they're used to load in microcode for the command processor. Here are the register definitions:

#define RADEON_CP_ME_RAM_ADDR 0x07d4
#define RADEON_CP_ME_RAM_RADDR 0x07d8
#define RADEON_CP_ME_RAM_DATAH 0x07dc
#define RADEON_CP_ME_RAM_DATAL 0x07e0

As for geennaam's actual Radeon 9250, the reason why it won't work on AmigaOS 4 but does on MorphOS is most likely down to the OS4 driver needing the firmware to do the low-level initialization properly. If the MorphOS driver includes code to do that, then it'll work even if the firmware doesn't. IIRC, AmigaOS 4 does have code to run the VGABIOS, but it's only included in AmigaOS 4.x for classic Amiga hardware (where it's needed if you have a Radeon card plugged into a PCI bus like the Mediator).**

Hans


** AmigaOS 4.1 for classic Amigas comes with an x86emu.resource.kmod.

@geennaam
Quote:

That quite a lot for non-real hardware and just voodoo3. Sadly it's uknown why pegasos2 can't handle radeonRX/HD over bridges :( Even mA1 can (which is even older).

@balaton
@all

I have a question
With the Ryzen the commands for compiling qemu are standard
I am:
./configure --target-list=ppc-softmmu

or is it better:
./configure --target-list=ppc-softmmu --disable-dbus-display --enable-slirp --enable-lto

because I can't figure out if the command above is specific for "MAC" systems or is it also valid for Ryzen systems

Also I would like to know if anyone works AmiCygnix
also in the light of the functioning of the real Voodoo proven.

Because I am convinced that RTL8139 is currently unable to get an external IP for some reason.

And it actually always adopts 10.0.2.15 whatever configuration is chosen via "TunTap" too

because in theory I shouldn't be able to delete the configuration in use in DEVS/NETINTERFACES/RTL8139

while instead with the active connection I can delete the file
DEVS/NETINTERFACES/RTL8139

while it should reply that the file is in use and cannot be deleted.

Also I would kindly ask "geennaam"
if you can verify the correct functioning of Amicicygnix on your configuration.

A thousand thanks.

@white

@geennaam

Thank you for your answer.

@balaton

because even if i choose 172.18.1.1 as static ip
Then in "Ranger" for example I see 172.18.1.1
but I believe it's just masquerading as "TunTap"

but actually at the next restart of qemu I can also choose:

-device rtl8139,netdev=mynet0 -netdev user,id=mynet0

it gives me the same IP 172.18.1.1 without me choosing TunTap

while it should not accept the IP 172.18.1.1
why with:
-device rtl8139,netdev=mynet0 -netdev user,id=mynet0

should only work with 10.0.2.15
it is clearly not with an external IP

here is the reason for my question.

This is clearly not a criticism
Indeed it is a signal of something that perhaps should be fixed if possible in later versions of qemu (pegasos2) etc.

it's part of reporting small constructive bugs

@white
You can use --enable/--disable options with Linux as well they are not specific to macOS. The dbus and slirp options should be auto detected so if you have libslirp-dev (or what is's called on your distro) package installed then user network will be built. Adding --enable-slirp menas it will give error and fail when no slirp is detected instead of building without -netdev user so you can make sure that way tho config will be what you want. The --enable-lto option enables Link Time Optimisation which is a compiler optimisation that will take more time to compile and may be faster or break depending on compiler version. One may try to enable even more compiler optimisations with --extra-cflags=-O3 but not sure if that helps. Compiling from QEMU master has latest patches that may improve FPU a little but may need the disable dbus option if you get an error related to that.

For the network it may depend on your QEMU command line. When using -detdev user then the guest can only use the 10.0.2.x network that slirp presents to the guest and will NAT traffic from it to the host network. If you enable DHCP in the guest the it will get an IP address starting from 10.0.2.15 from slirp's built in DHVP server and it will configure other parameters to use slirp services. You can manually set another IP address such as the 172.18.x.x one you did but that won't work with -netdev user. It's like connecting a machine to a router that's set up to use 10.0.2.x but manually configuring that machine to use a different network.

With -netdev tap no NAT, DHCP or DNS services will be provided by QEMU, all it does then is to connect the emualted card to the tap device on the host and then you can configure it and route it how you like it. That means you'll either need to do NAT on your host with iptables to allow the guest to access the internet or bridge the tap device to your physical network card inthe host to allow the guest to access your LAN and get an IP address from your router or just use the tap device to communicate with the guest from the host like it was a virtual network cable on end plugged in the host and the other end in the guest.

I think the problem is that you don't yet fully understand these options and therefore not configuring these correctly. Either search for some docs and learn about this or just forget all that and use -netdev user with the hostfwd option I've told before to redirect guest port 6000 to host port 6010 and in AmigaOS do not set any network parameters manually just set it to use DHCP which should set everthing correctly.

@geennaam
If this is DNS problem then it may be worked around by not using the slirp DNS but set some other DNS server manually in the guest (only overriding DNS setting not the IP). I think some people on MorphOS who had problems booting also said using manual settings works better and this may be why tap can work better.

If this is an old bug it's probably not fixed because it's not reported to those who could fix it. libslirp is now a separate project not part of QEMU any more so this should probably be checked in their bug tracker and reported there to get somebody look at it.