What the fastest possible x64 emulation way of OS4 today ?

@Balaton
That expected that your driver only offer 1024x768 and not 1920x1080 ? Not that it currently very important, but will be tasty to have too.

@kas1e
No it should have a lot of resolutions from qemu-edid even higher than 1920x1080. Maybe you have a Devs/Monitors/Radeon icon with tool types that disable DDC and do not define modes? You could either enable DDC in the monitor icon or delete or move it to Stroage so the defaults will be used.

@joerg
Quote:
No but neither does the sm502 driver and this benchmark specifically seems to excercise BlitRectNoMaskComplete only so only that should matter.

Quote:
I guess you can test that with setting NOBLITTER in the monitor icon which should disable the driver functions and use the AmigaOS defaults but I did not try that. But especially for larger blits doing it host side with native routines should be faster.
Quote:
I haven't seen anything using other than 0xFF mask and BlitRectNoMaskComplete cannot even use a mask, plus the docs say that's only used for planar mode which is not implemented in my driver so this should not matter.
Quote:
The defaults seem to allocate with enough alignment for ati-vga which I think is 16 bytes aligned.

Quote:
The results from smarkusg does not seem to prove this theory where only one screen is allocated for ati-vga but more than 4 for sm501. There may also be wrong rounding in the displayed value because it says 3 MB for what should be 3.9 MB.

@balaton
I tested the ATI (QEMU) driver for sam460 in QEMU. It doesn't work.
Most likely, the newer version of u-boot is trying to initialize the ATI card for its own purposes.
It works with a custom u-boot (where Radeon initialization is disabled).
It also works with an older version of u-boot for QEMU.
But there are still major issues. WB has compositing disabled.
Sm501 and Voodoo3 work correctly.
Here’s a video—it’s easier for me to post a video than to write and post screenshots.
video- > https://youtu.be/IQSzCMMo9Q8

@smarkusg
I've tested with amigaone and pegasos2 as that's probably what most people use, did not bother with sam460ex. As the sam460ex U-Boot has an ATI radeon driver it probably tries to init the card which fails without an appropriate ROM and we don't have a ROM that works with the x86emu in sam460ex U-Boot. So maybe you need to add -device ati-vga,romfile="",... and live with only serial output. The driver should still work once AmigaOS starts. I'll watch the video later.

EDIT: So QEMU vgabios does not work and romfile="" also crashes. There are some real card ROMs here with which I get no picture in U-Boot (ROM does not seem to run fully and interrupted by U-Boot) but at least it starts to boot but after the splash screen I got errors that I'm not sure is something wrong with my test image or some other problem.

@balaton
Quote:
I’ve been testing these options on a few ROMs I have for the RV100 and 7000. The newer u-boot doesn’t boot with `ati-vga` in QEMU-11.
I had a system image for the sam460ex to hand, so I gave it a go.
No one has reported any issues regarding this – perhaps no one ever will. I suspect few people use the QEMU sam460ex emulation.
You mentioned somewhere that the QEMU sam460ex emulation is to be removed. I won’t bother you with this matter.
It’s just worth noting that this issue occurs in QEMU-11 and ati-vga.

@balaton
Quote:Yes.
Quote:Depends on how the ati-vga emulation is implemented in QEmu.
If it's using an own thread running in parallel of the CPU and other guest hardware emulation it should be faster.
But if it's executed in the same thread, which seems to be the case for most hardware emulation in QEmu, i.e. stopping the emulated guest code, executing some host code, and restarting the guest CPU emulation, it's probably slower than guest code doing the same.

@joerg
This might depend on more things like host CPU and OS as well but at least the option is there to test different ways and use what's best for a given situation. Maybe somebody interested finding out more could test these. Here are the options:
- NOBLITTER in monitor icon should use guest side JIT compiled functions and only use the driver as plain frame buffer
- -device ati-vga,x-pixman=0 disables pixman and always uses fallback on host side
- no special options uses pixman on host side if available or fallback if QEMU is compiled without pixman or call to pixman fails
Testing on one system does not mean all systems would get the same result so I guess everybody needs to try and find what works best for them but reporting test results might still be interesting.
The ati-vga currently does not run async (that's for future enhancement) but the sm501 also doesn't and it has similar usage of pixman and fallbacks so I don't understand why they behave differently. Either there's something the sm502 driver does differently or it's because of some difference between the sm501 and ati-vga that might be fixed if we found out what it is.

@smarkusg
Quote:
Not the sam460ex machine is to be removed (as long as I maintain it) but maybe the U-Boot for it which needs old compiler so it's a problem for distro maintainers. I updated sam460ex U-Boot hoping it might help with GPU passthrough but it still has issues so it did not help much. Either I can update to latest U-Boot and see if that fixes problems or just revert to the old version if that works better. The old U-Boot version is still available in older QEMU versions (10.1.0 and older) so one could also get it from there and replace it until I can fix it upstream if that version works better. The new sam460ex U-Boot also seems to have an issue with USB on AROS so it seems it needs some fixes anyway.

@balaton
Quote:You should investigate the reason for the way too low VRAM usage with ati-vga.
graphics.library and the p96 .card/.chip drivers do support an unlimited amount of bitmaps swapped out to DRAM, but for using any of the HW accelerated functions of gfx drivers the bitmaps have to be moved to VRAM first, and constantly swapping bitmaps between VRAM and DRAM can explain huge slowdowns, especially for operations using large bitmaps.

@balaton
Quote:
Yes. There is a problem with that. Some minor issues have already been fixed.
The driver isn't fast, but since it's probably the only one under the GPL license, it could be added (created) as a binary patch to the PEG2 and A1 installation discs. After purchasing the license,
you can download the ISO file, add the binary patch (Add monitor preferences), and boot the system.
Any System updates do not interfere with the operation of the system or the Voodoo3 driver.
Even if the Voodoo3 is slow, you could upgrade the system to U3 via updates and then install whatever you want.


One issue is the patch for QEMU. For now, the author is creating binary versions of QEMU (unofficial)
Time will tell how this plays out

@smarkusg
What binary patch and what GPL driver? Doesn't it use the 3dfxVoodoo.chip driver that comes with AmigaOS? Then you should not need any patch for that but it may need an actual 3dfx ROM for the card which may not be distributable again. If it comes with a separate driver then does 3D work? If not what is better about it than other 2D cards? Maybe it's slow because you have NOBLITTER=Yes so it's just used as a frame buffer? I think Voodoo is quite limited by the capabilities of that old card so it's probably a dead end anyway.

@joerg
Quote:
How could I do that if I don't know what the graphics/rtg library does and there's no source to check? But the GfxBench2D test just copies blocks on the screen around and there's a difference in that with ati-vga and sm501 so I'd try to understand that first.

@balaton
Quote:
I corrected the post; it was translated incorrectly—my apologies. It’s not better; it’s actually worse—it’s slow and doesn’t have 3D yet, but it would make installation easier.

@smarkusg
Quote:Why wasn't the Voodoo emulation from WinUAE used as base for the QEmu implementation?
The AmigaOS Voodoo drivers, both 2D and 3D, are working with it.

But even if everything works like in WinUAE it's still a bad choice, even compared to 2D only hardware emulation like UAEGFX, SM501/502 and ati-vga:
- Voodoo has too few VRAM for AmigaOS 4.x.
- It's HW 3D is only supported in 16 bit modes, and probably isn't much faster, if at all, compared to a software only Warp3D reimplementation like Wazp3D on UAEGFX, SM501/502 and ati-vga.

@joerg
Quote:
Most likely, the WinUAE driver would only work with AmigaOS PPC.
From what I can see, the author also wants it to work on both x86 and PPC, covering all systems.
You’ll surely point out that WinUAE uses QEMU to emulate the PPC CPU when running AmigaOS4 PPC on classic hardware (yes, WinUAE uses QEMU, in case anyone didn’t know). But that’s a very old version… very old. I think it comes from QEMU 3 if I remember correctly, and it was definitely stripped down to work properly with WinUAE under the CPU. I have no idea if it also emulates Voodoo.

This emulation QEMU voodoo has come in handy for me twice recently—even though it doesn’t work perfectly.

Example 1:
As you’re reading this thread, @balaton has released a new driver for QEMU (ATI).
I tested it under Sam460ex emulation. It didn’t work. Under QEMU (with PCI passthrough enabled), only the SM501/502 is available.
If I didn’t have the Voodoo driver for QEMU, the scope of troubleshooting potential issues would be very broad.
After verifying that the Voodoo driver for QEMU works on Sam460ex, a possible issue was u-boot. It checks if the connected card is ATI and configures various settings. It’s possible that QEMU (ati) doesn’t work correctly yet on Sam460ex after disabling this, but I think @balaton is already looking into that.

Example 2:
As you know, I have QEMU PCI passthrough with a Radeon card. I also connected an NVMe drive to use as my main system drive.
The system using PCI passthrough is Pegasos2. Here, to start the PCI passthrough itself, you need to use bboot.
“pegasos2.rom” boots on its own, then bboot.fth is launched. It runs Kickstart.zip and boots the system.
This doesn’t happen automatically, so you have to bypass the restriction on booting the Pegasus2 emulation from ROM. Give it the commands… I’ll skip the rest of the details.
By accident, I added a “REM” for the RadeonHD driver in Kicklayout. The system wouldn’t boot. I didn’t have a modified version of Kicklayout where the SM501 driver would also be loaded.
I was in for a real ordeal. Connecting the monitor (My new monitor doesn't support resolutions lower than 800x600) to an X86_64 machine with PCI passthrough. Enabling the Intel card. Launching some X11/Wajland session and running QEMU without PCI passthrough from some system image to rebuild Kickstart.zip.
I hadn’t removed “MODULE Kickstart/3dfxVoodoo.chip” in Kicklayout, so the test was simple.
Booting the system with Voodoo via a remote “VNC" (Available as a QEMU video output option) session, correcting the entries in the running system in Kicklayout for RadeonHD, and rebuilding
Kickstart.zip.

Example 2 is very extreme, but it shows that the Voodoo driver can save your butt

I disagree that the author’s work on the Voodoo driver is unnecessary.
It’s not perfect, but it’s not a waste of time...
It comes in handy in everyday life (for me).

Maybe it wasn't based on WinUAE because the WinUAE sources are a mess and it's hard to port anything from there. I've looked at the cirrus-vga that they have some fixes for but the commit history is just random changes without description and the device emulation was changed to glue it into WinUAE so not compatible with QEMU even though it originally comes from there. I think the Voodoo in WinUAE also comes from the same source as this port but ultimately all of these go back to MAME but that had a licence change at one point so it could not be used any more. So maybe Bochs or whoever was first adding Voodoo had a fork from before the licence change and implemented the missing parts and then the rest took that GPL version.
I think it's a waste of time because the result is limited and cannot be upstreamed in QEMU so it's of limited use but it's a waste of AI not the author's time so could be done. As I see it he did a lot of experiments and this one turned out to be somewhat working so he's pushing it now but if it won't be better than Wazp3D then there's not much point in doing it.
I don't understand what your problem was but if you just needed a way to boot your broken install I guess you could have solved that easier by creating a small boot disk image with the proper Kickstart.zip and boot from that instead of your SYS: volume and that should have worked with whatever driver you put in the new Kickstart.zip. Or if nvme pass through does not need the pegasos2.rom (I think only GPU needs it for the BIOS emulator) then you could just boot with -kernel bboot -initrd Kickstart.zip without the GPU and only the nvme passed through and fix your Kickstart.zip on the nvme. That way you didn't need a patched QEMU build for this.